When translations break your app store character limits
You wrote a clean 28-character app name, a punchy 29-character subtitle, and a keyword field that uses all 100 characters. Then you localized the listing and App Store Connect started rejecting fields — the German subtitle is 41 characters, the French one is 36. The English version was never the problem. Each language gets its own copy of every field, and each copy has to fit the same limit on its own.
This is the reference for what those limits are, why translation blows past them, and how to keep a listing readable in every language instead of chopping words in half.
The character limits, both stores
Every number below is per locale. When you localize into French, German, Japanese, and so on, each language holds its own copy of every field, and each one is checked against the same cap at submission.
| Field | Apple App Store | Google Play |
|---|---|---|
| App name / title | 30 characters | 30 characters |
| Subtitle | 30 characters | No equivalent field |
| Short description | No equivalent field | 80 characters |
| Keyword field (hidden) | 100 characters | No such field |
| Promotional text | 170 characters | No equivalent field |
| Description / full description | 4,000 characters | 4,000 characters |
Two things are worth pinning down. The App Store keyword field is a hidden, comma-separated 100-character slot — not visible on the product page, but it's where a lot of your indexing lives, so every character counts. And the tightest fields — the 30-character name and subtitle — are exactly the ones translation hits hardest.
Why the translated version overruns
The same meaning takes a different amount of room in different languages. Translating out of English, the rough direction is consistent enough to plan around:
- German: often +30-40%. Compound nouns fuse several English words into one long word, and there's no shorter synonym to fall back on. This is the language that breaks a 30-character field most often.
- French, Spanish, Italian, Portuguese: roughly +15-25%. Consistent, moderate expansion. A name that sits comfortably at 24 characters in English lands near or past 30.
- Chinese, Japanese, Korean: often around 50% shorter in character count. CJK scripts pack more meaning per character, so the field limit is rarely the binding constraint — legibility and word choice are.
- Arabic, Hebrew and other RTL scripts: expect expansion in the +15-30% range plus a direction flip. These need a human review pass, never raw machine translation — bidirectional text, and non-Latin keyword fields, are where automated output quietly goes wrong.
Treat these as planning ranges, not guarantees. The point is the direction: if a field is near its cap in English, assume the European translations will push over it and the CJK ones will come in short. Budget a few characters of headroom in the English source and the expansion has somewhere to go.
What breaking the limit actually looks like
Apple and Google both enforce the caps at the submission step. In practice you hit one of two failure modes. The store form refuses the extra characters outright — you physically can't type past the limit, so a pasted translation gets silently cut at the boundary, mid-word. Or the field accepts the text and the listing gets rejected on review. Either way the translated name or subtitle ends up truncated, misspelled by the cut, or missing entirely in that market.
None of that is visible from the English listing. It surfaces per language, one locale at a time, usually after you thought the listing was done.
The fix: transcreate, don't truncate
Chopping a German subtitle at character 30 produces a broken half-word that reads as machine-mangled to a native speaker. The right move is to rewrite the name and subtitle per locale so they carry the same intent inside the limit.
- Shorten the source first. A 22-character English subtitle survives a 35% expansion; a 29-character one doesn't. Headroom in English is the cheapest fix.
- Transcreate the tight fields. For name and subtitle, pick a shorter synonym or drop a filler word in the target language rather than translating word-for-word. The goal is a phrase that fits and reads naturally, not a literal match.
- Give RTL and non-Latin fields a human pass. Arabic, Hebrew, and non-Latin keyword lists are the ones machine translation gets wrong in ways you can't spot if you don't read the script.
- Check the count in the target script, not the English one. Character count is what the store measures, and it differs by language — so it has to be measured after translation, per field.
Where Mokbi helps
Mokbi translates your whole listing — name, subtitle, keywords, description — into 50 languages, and it shows the per-language character count for every field as it goes. The overruns surface right there in the editor, before you paste anything into App Store Connect or Play Console, so you catch the 41-character German subtitle while you can still shorten it instead of after a rejection.
That's a first pass, not a final one. It gets every field inside the limits and flags the ones that expanded, which is most of the work. But your highest-value markets still deserve a human read — a native speaker to confirm the transcreated name sounds right and the RTL fields are correct. The tool removes the guesswork about which fields broke; a person confirms the ones that matter most read well.