KIMI BRAIN JOURNAL · ANALYSIS & PRACTICAL GUIDE
20 September 2026 · Mohammed Al Marzooqi
A language count is a starting point. A usable multilingual workflow must also preserve meaning, support the task and survive export.
The news—and the boundary of the claim
In a 15 September update, Google said its technologies and products support interactions in more than 300 languages. Its article discusses speech, community datasets and access constraints. That portfolio-wide statement should not be read as a promise that every Google feature supports every language. Source: Google's announcement.
For a writer or a small business, the useful question is narrower: can this specific feature complete this specific job in the language my reader needs? The framework below is our suggested evaluation method, not a benchmark or a claim that we tested Google's products.
Six gates for multilingual work
Pass each gate separately. Keep the evidence.
1. Define the deliverable before choosing the tool
Write down the task, audience, source language, required output language and final format. “Arabic support” is too broad. “A one-page Arabic customer guide, based on an approved English brief, delivered as a readable PDF” gives you something to check. Note whether the audience expects Modern Standard Arabic or a specific dialect. Do not infer that preference from a country name.
Prepare a short, non-sensitive sample and a reference version that a competent speaker can review. Include ordinary text plus a date, a quantity, a product name and a sentence with a condition. Keep private customer data out of this preliminary evaluation. Check the service's current language documentation and your account's available features before submitting the sample.
2. Separate interface, input and output
A translated menu tells you how to operate the application. It does not demonstrate that its summarizer, rewriter or export feature produces that language. Test each operation separately. Record the actual feature name and setting, rather than writing that the entire product “supports Arabic.”
For example, ask for an Arabic summary of your approved English sample. Then try an Arabic source with an Arabic output instruction. If the result appears in English, record a failure for that operation. Changing the interface language again is not evidence that the generation setting changed. Look for a dedicated output-language field or a documented instruction method.
3. Test meaning with a protected-facts list
List facts that must remain unchanged: names, amounts, units, dates, exclusions and conditions. An illustrative brief might say: “The workshop has 12 places. Registration closes before 8 October. Materials are included; travel is not.” The review must preserve all four claims. Elegant wording cannot compensate for changing “before” to “on,” or quietly removing the travel exclusion.
Use a bilingual reviewer for the comparison. A back-translation may flag problems, but it is another generated output rather than independent proof. Record omissions and additions explicitly. If the reviewer cannot resolve a specialist term, retain the source term with a clarification request instead of inventing a confident equivalent.
4. Review local conventions and mixed text
Check date order, decimal notation, units and the requested spelling style. In Arabic documents, inspect English product names, email addresses and numbers inside right-to-left paragraphs. A sentence can be linguistically correct while a reordered identifier makes the document unusable.
For speech workflows, add a separate sample containing realistic language switching only when that reflects the task. Keep speech results separate from written-text results. Success with a clean paragraph does not establish performance on overlapping voices, dialects or background noise. We have not run those tests here.
5. Inspect the exported file, not just the preview
Open the downloaded document in a second viewer. Look for missing glyphs, broken letter joining, reversed punctuation, clipped tables and hyperlinks that no longer work. Copy a short passage out of the file to see whether its text remains usable. Compare it with the approved on-screen version. A screenshot of a correct preview cannot establish that the exported file is correct.
Keep a small results table: sample ID, feature, language instruction, protected facts, review outcome and export outcome. Mark untested cells as untested. If a workflow fails at export, a reviewed alternative format may be acceptable, but tell the recipient what you actually checked.
What a useful result looks like
The outcome is a bounded statement: “This feature produced an acceptable Arabic summary for these samples, reviewed by this person, in this format.” It is not a universal language-quality score. Repeat the relevant checks when a feature, model or document template changes. For high-consequence material, involve an appropriately qualified reviewer.
Affiliation: I founded Kimi Brain. This method applies to our tools too. Humanizor supports English rewriting only; an Arabic tutorial explaining it does not imply Arabic rewriting support. Our Network.