Text Expansion by Language for Screenshot Copy

Languages package meaning differently, so the same message needs a different number of characters and a different amount of space. W3C's article on text size in translation (opens in a new tab) notes that these differences "can be systematic", which means you can plan for them instead of discovering them at export time.

Screenshot captions are the worst case. They are short, they sit in fixed boxes over a device frame, and they must stay readable at thumbnail size in a store listing. A headline that fits on two lines in English can need three or four lines in another language, or a smaller font that becomes hard to read.

Google Play's own guidance adds a hard edge to the problem: on screenshots, taglines "should not take up more than 20% of the image" (opens in a new tab), and it warns against overloading screenshots with text in small font sizes. Expansion eats into that budget first.

The most widely quoted reference is the IBM guideline table reproduced by W3C (opens in a new tab). It gives the average length of translated text as a percentage of the English source, grouped by source length.

Two practical readings follow. First, the shorter the source, the larger the relative growth: W3C puts it as "the smaller the source message, the higher the likely translation length." Second, the 51–70 row is higher than the 31–50 row as published, which looks like a typo in the source, so treat the overall trend as the reliable part rather than that single row.

These are averages across languages, not per-language ratios. The table does not give a figure for German, Japanese, Arabic or any other specific language, so avoid quoting it as "German is 30% longer" or similar.

Short English phrases lean on compact words, implied subjects and verbs that double as nouns. A three-word caption such as "Sync everything" or "Track habits" often needs articles, prepositions or inflected forms in the target language to say the same thing naturally.

W3C illustrates this with a single UI word, "views", translated into several languages. Its ratios count each Chinese and Korean character as two English characters of width, because of the width of the glyphs.

Most screenshot headlines sit in the up-to-30-character range, which is exactly where the table predicts the largest growth. That is why caption boxes sized to the English copy are the most common source of overflow in localized sets.

Chinese, Japanese and Korean often use fewer characters than English, but each character is wider. W3C's example is the English word "desktop" written in Japanese katakana: the Japanese has one less character, "but will typically take up much more horizontal space." (W3C (opens in a new tab))

Height matters too. W3C notes that it is "very common for non-Latin text to have much taller characters than Latin text" and that these scripts "often require more vertical space between lines." A line height tuned for a Latin display font can make CJK or accented captions look cramped.

• Budget CJK captions by rendered width, not by character count.
• Check line breaks by eye: W3C's Japanese layout requirements (opens in a new tab) list punctuation that may not start or end a line, and automatic wrapping can strand 。 or 」 at the start of a line. Chinese has similar rules.
• Confirm the font has glyphs for the script. A Latin-only display font falls back to a system font mid-caption, which looks inconsistent.
• Test at thumbnail size. Dense characters lose legibility sooner than simple Latin letters at the same point size.

W3C (opens in a new tab) points out that "a number of languages, such as Finnish, German and Dutch, create single large 'words' to replace what is a sequence of smaller words in other languages." Its example: "Input processing features" may become a single 30-character compound word in German.

Total length is only half the problem. A single long word cannot wrap between words, so it sets the minimum width of the caption box. If one compound is wider than the box, the renderer either overflows, breaks the word at an arbitrary letter, or forces you to shrink the whole headline.

• Scan German, Finnish and Dutch captions for the longest single word and check that it fits on one line at your chosen font size.
• Ask the translator for a phrasing that splits the idea into shorter words when a compound is too wide. This is usually better than an arbitrary break.
• Watch all-caps styling. In German, uppercasing turns ß into SS, which lengthens the word.

There is no official per-language ratio for store captions, so treat the following as planning guidance built on the W3C figures above, not as measured numbers. The safest single rule is to design the English layout so it still works when the text roughly doubles.

For right-to-left layouts, length is rarely the only issue. The RTL screenshot guide covers alignment, mirroring and number handling.

1. Write shorter source copy. Every English character you remove saves more than one character in most translations. Aim for one idea per headline, such as "Plan meals in minutes" rather than a two-clause sentence.
2. Avoid abbreviations and wordplay. W3C warns that other languages "may not be able to replicate such an abbreviation", and puns rarely survive translation at the same length.
3. Use flexible text boxes. Give captions a wide box that wraps onto extra lines instead of a tight single-line box. W3C recommends allowing text to reflow and avoiding "small fixed-width containers or tight squeezes where possible."
4. Reserve vertical room. Place the headline so that one or two extra lines push into planned empty space, not into the device frame.
5. Set a minimum font size. If your tool allows per-locale sizes, drop a step for long languages; either way, below that floor you rewrite the copy instead of shrinking it further.
6. Set line breaks by hand. Automatic wrapping can leave a single short word on the last line or split CJK text in the wrong place. A manual line break often fixes a headline without shrinking it.
7. Review at store size. Look at the finished screenshot the way a shopper sees it: small, in a row, next to other listings.

On the App Store, when you add a language, "screenshots and the properties for the new language default to those of the primary language" (opens in a new tab), apart from the description and keywords. Shoppers in that locale then see your English captions unless you upload localized screenshots.

Google Play asks you to localize "any additional taglines or text overlays" (opens in a new tab) on screenshots, while in-game UI does not need to be localized per market. Captions are therefore the part of the image where expansion planning matters most.

In StoreLocale, each headline text layer stores a separate string for every locale in the project. You can translate the source copy with AI, then edit the wording for a single locale, for example shortening a German headline or adding a manual line break in Japanese, without touching the other languages.

• Switch the editor locale to see each translation in the real caption box on the canvas before you export.
• Text detection and translation cost 0 credits, so you can iterate on wording freely.
• Text inside the app screenshot itself can be repainted by an AI image model that is told to fit or shorten text rather than cut it. The result is generative, so review every repainted screenshot.
• Strict export skips or blocks slides that still have untranslated text, so a missing locale does not slip into the final ZIP of PNGs.

Note that font size, font family and box width are shared by all locales on a text layer. If one language needs a different size, shorten the copy for that locale or give the box enough width for your longest language up front. Start from the screenshot localization workflow or the translation checklist.