Multilingual Type: CJK, Arabic, and Diacritics in Generated Graphics

Text-in-image has gotten good enough in English that it's easy to assume the skill generalizes. Then a Chinese product label or an Arabic quote card comes back looking like text — confident kerning, plausible letterforms, a layout that reads as designed — except none of it is actually the words you asked for. That's a more dangerous failure than obvious garbage, because it can pass a glance from anyone who doesn't read the script, and ship anyway.

What actually breaks, and why it's not one problem

"Multilingual text rendering" sounds like a single capability a model either has or doesn't. In practice it's at least three separate problems, each with a different cause:

Logographic scripts — Chinese, Japanese, Korean. Chinese alone has thousands of distinct, visually dense characters, against roughly 26 letterforms for English. A model needs meaningful training exposure to specific characters, not just more general "text" training, because there's no small alphabet to generalize from the way Latin script allows. A model under-trained on CJK doesn't render blurry Chinese — it renders confident, plausible-looking characters that are simply the wrong ones, or characters that don't exist at all, stitched together from strokes that individually look correct.

Right-to-left scripts — Arabic, Hebrew. These fail differently: directionality. A model trained predominantly on left-to-right corpora can reverse word order, break Arabic's letter-joining rules (where a letter's shape changes depending on whether it's at the start, middle, or end of a word), or misplace embedded numerals that should stay left-to-right inside an otherwise right-to-left line. The individual glyphs can be rendered correctly and the line can still be wrong, because the failure is structural rather than character-level.

Diacritics — Vietnamese tone marks, Central European accents, Arabic vowel marks. These fail on a third axis entirely: size. A diacritic occupies a small fraction of a character's pixel footprint but can carry the entire meaning distinction between two different words. Models drop, blur, or misplace small marks more readily than they get a whole glyph wrong, which makes diacritic loss the easiest of the three failures to miss on a casual look and the easiest to get catastrophically wrong for a fluent reader.

Three different causes means three different things to check for — a model that handles CJK well isn't automatically safe on Arabic directionality, and vice versa.

Models actually trained for this, not models that happen to render some text

Most image models render some legible text as a side effect of general capability. A smaller set were specifically built and benchmarked against multilingual and non-Latin text rendering as a target capability, which is a meaningfully different bar.

Qwen-Image is a 20B-parameter MMDiT model built explicitly for complex text rendering across both logographic and alphabetic languages, and evaluated on text-specific benchmarks — LongText-Bench, ChineseWord, and CVTG-2K among them — rather than general image-quality benchmarks that happen to include some text examples. That's a different design target than a general-purpose model retrofitted with text capability, and it shows in practice: the model was built to treat character-level fidelity as a primary objective, not a byproduct.

Seedream 5.0 Pro takes a similar approach from ByteDance, natively supporting text rendering across a dozen widely used languages for prompting and image generation — built for international workflows rather than English-first with multilingual bolted on.

Both are real, available options, not aspirational names. Versely carries Qwen Image at 2 credits, Seedream 5.0 Pro at 7 credits with a multilingual_text capability tag in its catalog listing, and Wan 2.7 Text to Image at 3 credits, which carries a bilingual_prompts tag specifically for prompt understanding across two languages at once rather than single-language generation with translated captions. None of these are the only text-capable models in the full catalog, but they're the ones actually built and evaluated against multilingual and non-Latin rendering as a stated target, which is the distinction that matters when the text isn't decorative.

The proof step that actually catches the failure

None of the above replaces checking the output. A thumbnail-sized preview is not a legibility test for a script you don't personally read — "looks like confident, plausible typography" is exactly the failure mode described above, and it's specifically designed to survive a quick glance from someone who can't verify the characters themselves.

The proof step that actually works: a native or fluent reader of the target script checks the actual output at full resolution before it ships, reading the characters rather than judging the composition. This matters more than it sounds like it should, because a non-reader's instinct — "does this look like real Chinese/Arabic type" — is precisely the question a broken generation can pass while still saying something wrong or nonsensical. Confidence of rendering and correctness of rendering are different properties, and only one of them is visible to someone who can't read the script.

For teams without an in-house fluent reader on a given target language, this is worth treating as a hard gate rather than a nice-to-have — a generated asset in a script nobody on the team can actually verify is a generated asset nobody on the team can actually ship with confidence, regardless of which model made it.

A real walkthrough: a bilingual product graphic

Say the brief is a single slide with an English headline and a Simplified Chinese subline underneath it, meant to run as-is rather than as two separate localized versions.

1. Name the model explicitly rather than letting a default choice pick for you — for this specific job, request Qwen Image or Seedream 5.0 Pro by name in chat, since both are built and benchmarked for exactly this kind of mixed-script rendering rather than general image quality.
2. Write the prompt with both text strings given verbatim and explicitly labeled by language and position ("English headline reading exactly: ___", "Simplified Chinese subline reading exactly: ___"), rather than describing the content and hoping the model translates or invents appropriate wording — precision in, precision out.
3. Generate, then route the result to a fluent reader of the Chinese text specifically — not a proofread of the layout, a read of the actual characters against the string you asked for.
4. If characters are wrong, that's a re-prompt with the same explicit-string approach, not a different model necessarily; if directionality or spacing is the issue on an RTL job instead, that's more likely a model-capability ceiling worth switching models over.

When the text isn't baked in at all

Everything above assumes the multilingual text is being rendered inside a generation. When it's added afterward instead — a stamped caption or overlay rather than in-image typography — the failure mode changes shape entirely: it's no longer about a model guessing at glyphs, it's about whether the chosen font actually has the glyphs at all. Plenty of fonts that look complete in a Latin-script preview simply don't ship coverage for CJK characters, Arabic letterforms, or the full diacritic set a given language needs — and the failure there isn't a wrong character, it's a missing one, silently substituted or dropped. Checking a font's actual script coverage against the font library before committing to it for a multilingual caption pass is a five-second check that avoids a much less obvious failure than a generation model getting a glyph wrong.

The visual half of a bigger problem

Multilingual typography is the visual half of what "going multilingual" actually requires — getting the words on screen right. The audio half is a parallel problem with its own model-capability distinctions, covered by whatever's driving voice generation and dubbing for the same content. Neither half is solved by the other; a brand that's solved multilingual voiceover still needs a separate, deliberate check on multilingual on-screen text, and the reverse. Treating "multilingual" as one checkbox instead of two is how a team ships a perfect voiceover next to garbled on-screen type, or the other way around.

For anything where exact wording in a non-Latin or diacritic-heavy script matters — and for commerce or brand assets, it usually does — comparing image models directly against the specific script in question, rather than against general output quality, is worth the extra step before committing to one for a whole campaign.