Localization in Mobile Games: Beyond Just Translating Strings

Shipping in one language means leaving 80% of your potential players on the table. But "just translate the strings" is the part where most teams stop — and it's also where most teams ship broken UIs to half the world.

Here's what localization actually looks like once you take it seriously.

1. The Pre-Translation Tax

Before you translate a single word, your codebase has to be ready. The list is shorter than people think but more invasive than they expect:

• Every visible string lives in a table, not in code. No more "Tap to Play" inline in a prefab. If a designer can hardcode a string, they will, and you'll find it three months later in a screenshot from a Brazilian player.
• No string concatenation. "You earned " + coins + " coins" is a sentence in English and a war crime in Turkish, where word order, suffixes, and grammatical case break the moment you split the sentence into pieces.
• Every layout assumes 2x the width. German averages ~30% longer than English. Russian and Finnish push 40-50%. If your PLAY button fits PLAY exactly, it doesn't fit anywhere else.

This is the boring foundational work. Skipping it makes every later step harder.

2. Right-to-Left Is Not a Translation Problem

Arabic, Hebrew, Persian. RTL languages aren't "translate, then flip the text." The entire UI flow mirrors. The back button moves to the right edge. Progress bars fill right-to-left. Icons that imply direction (arrows, next/prev) need a separate set or a flip flag.

Unity's TextMeshPro handles RTL text rendering reasonably well now, but it does not handle UI layout mirroring. That's on you, and the cleanest way is to set the canvas root pivot/anchor based on locale at startup. Don't try to handle it per-element — you will miss one and ship with a Save button stuck on the wrong side.

If your game has tutorial arrows or finger pointers, you need the mirrored variants in your asset list, not your TODO list.

3. The Font Problem Nobody Plans For

Your slick custom font supports Latin. Maybe Cyrillic. It does not support Chinese, Japanese, Korean, Arabic, Thai, or Devanagari. CJK alone is ~20,000 glyphs.

You have two real options:

• One mega-font with everything baked in. Easy, but the atlas balloons to 40-80MB and your initial load gets ugly.
• Per-language font swaps with fallback. Use TMP fallback chains: Latin font tries to render → unknown glyph → falls back to Noto Sans CJK → falls back to Noto Sans Arabic. Smaller bundles, more setup.

The fallback chain is the right answer for mobile. The setup pain is one-time; the install size win is permanent.

4. Plurals, Gender, and the Sentence That Refuses to Translate

You have 1 coin / You have 5 coins is two cases in English. Russian has three. Arabic has six. Slovenian has four — and one of them is for exactly two of something.

Same with gender. "Welcome!" in French is genderless. "You are awesome!" is Tu es génial for a man, Tu es géniale for a woman. If your game knows the player's gender (or lets them pick), the localization system has to know it too.

The fix isn't writing complex code — it's using a localization library that handles ICU MessageFormat or equivalent. Unity's Localization Package supports plural rules out of the box. Use them. Do not invent your own.

5. Runtime Switching Is a Test, Not a Feature

If your game can only switch language at startup, your QA cannot test the other 39 languages without restarting the game 39 times. Build runtime switching from day one — even if your shipping app hides the option behind a debug menu, your dev build needs it.

The implementation is straightforward: a global locale state, a string lookup that re-runs when locale changes, and a refresh event that all visible text components subscribe to. Unity's Localization Package gives you this for free. It is not optional.

6. Pricing and Copy Aren't the Same in Every Market

$1.99 is a normal IAP tier in the US. In Turkey, that's somewhere between "trivial" and "way too expensive" depending on the month's exchange rate. The store handles the currency conversion, but the perceived value does not translate.

Same with copy tone. "Limited time offer — grab it now!" works in the US. In Japan, the same phrasing reads as pushy and lowers trust. Casino-style FOMO copy that performs in MENA underperforms in Northern Europe. If you have time and budget for one market-specific tweak, do it for the IAP store page — that's where it shows up in revenue.

7. Testing Without Speaking 40 Languages

You will never personally read Korean well enough to spot a bad translation. But you can catch the bugs that break regardless of language:

• Pseudo-localization. Wrap every English string in markers (⟦Tap to Play⟧) and inflate length 30%. If text overflows, your layout is the problem, not the translator's.
• Screenshot every screen in every language. Automate it. A 200-screen game in 30 languages is 6,000 screenshots; a script does it in 20 minutes. Eyeball the grid for clipping, missing glyphs, or empty placeholders.
• Native speaker pass for top 5 markets. You don't need 40. You need to nail your top revenue markets. Hire a player from each, give them an APK and a list of screens to review.

8. The Actual ROI

Localization isn't free. A 40-language pass with native QA, font work, and RTL support easily runs 2-4 months of dev time and a five-figure translation budget for a mid-sized game.

The payoff: a fully localized mobile game typically sees 3-5x revenue compared to English-only on the same product. Most of that gain comes from the top 6-8 non-English markets: Japan, Korea, Germany, France, Spanish-speaking LatAm, Russia, Turkey, MENA. Cover those well and you've captured 80% of the upside.

The mistake is doing 40 mediocre translations instead of 8 good ones. Pick your markets, do them properly, and grow from there.

Localization is one of those areas where the bar between "we shipped it" and "we shipped it well" is enormous, and the players you locked out never tell you. Build the foundation first, ship to the markets you can serve properly, and treat the rest as a roadmap, not a checkbox.