DEV Community: Akmal Urunboev

What breaks when you ship to ten locales at once

Akmal Urunboev — Sat, 03 Oct 2026 00:16:32 +0000

I localized a mobile app into ten languages. Most of what I'd read beforehand was about how to
translate. Almost none of it was about what goes wrong after, which turned out to be the harder half.

These are the mistakes I actually made.

1. I translated the content and left the chrome in English

This is the one I'd undo first.

The quiz content — the part users came for — got translated properly. The surrounding interface did
not, or did only partly. Settings, error states, the subscription screens, legal copy, empty states.

The result is worse than an English-only app, because it sets an expectation and then breaks it. A
user who has been reading comfortably in their own language hits a wall precisely when something has
gone wrong or something is being asked of them. The experience doesn't degrade gradually; it
fractures at the exact moments that matter most.

The lesson: a locale is either done or it isn't. Partial coverage is not partial credit. If you
can't finish a language, ship it later.

2. I shipped locales before I knew anyone wanted them

Adding a language feels like growth. It is cheap to start and expensive forever: every string you
ever write afterwards is now ten strings, every feature ships at the speed of your slowest translator,
every bug report might be a translation bug.

I added languages because I could reach those speakers, not because I had evidence they were
waiting. Some were right. Some were an ongoing tax I'm still paying.

The lesson: treat each locale as a permanent operational commitment, not a one-time content cost.
Ask what evidence would justify it, then go find that evidence first.

3. I couldn't review what I couldn't read

Obvious in hindsight. I shipped languages I don't speak, with no process for knowing whether they
were any good beyond "the translator seemed competent."

You cannot eyeball your way out of this. You need either a native reviewer who is separate from the
translator, or a sampling process, or both — and you need it before launch, because the alternative is
finding out from a one-star review written in a language you'll have to machine-translate to read.

The lesson: budget for review as a separate line from translation. They are different jobs and
the same person should not do both.

4. I let terminology drift

Several translators, one corpus, no glossary. The same domain term ended up rendered three different
ways across the app.

Each individual choice was defensible. Collectively it made the product feel like it had been
assembled from parts, and worse, it made the material harder to learn from — the whole point of
consistent terminology in educational content is that the learner builds one mental model, not three.

The lesson: the glossary comes before the first word is translated. Retrofitting consistency
across a large corpus is enormously more expensive than establishing it.

5. I assumed text length was roughly constant

German and Russian run substantially longer than English. Some languages run shorter. Either way,
layouts built around English string lengths break — truncation, wrapping into two lines, buttons
growing past their container, labels colliding.

This is not caught by review, because reviewers read text, they don't measure it. It is caught by
pseudo-localization — rendering your UI with artificially lengthened strings before you have any real
translations — which costs almost nothing and would have saved me a round of layout fixes.

6. I treated RTL as "a language"

Arabic isn't another locale in the list; it's a different layout direction. Mirrored navigation,
flipped icons that indicate direction, number and punctuation handling inside mixed text.

Most frameworks handle the basics. The basics are not the problem — the problem is every place
someone hardcoded a left margin, every directional icon that shouldn't flip (a play button) sitting
next to one that should (a back arrow), and every string that mixes scripts.

The lesson: if RTL is in your plan, put it in early. Adding it after a year of LTR-only
development means auditing every layout you've written.

What I'd do differently

Pick two languages. Do them completely — content, interface, store listing, support. Build the
glossary, the review process and the pseudo-localization step while the surface area is small enough
to hold in your head.

Then add the third.

The instinct is to go wide early because the marginal translation cost looks low. The translation is
not the cost. Everything downstream of it is.

I build and operate multilingual mobile applications, shipped across ten languages. More at akmalu.com.

Designing for people reading in their second language

Akmal Urunboev — Sat, 03 Oct 2026 00:15:45 +0000

Most people using the products I work on are preparing for a US licensing exam in a language that isn't
their first. Many are studying after a full shift. Some have not sat a formal written test in twenty
years.

The thing I keep relearning: they are not bad at the test. The test is being delivered through a
layer they have to fight. Every bit of that layer you remove goes straight into their score.

Here is what I've learned about removing it.

Negation is the single most expensive construction

"Which of the following is not required when…"

A fluent reader handles this without noticing. A second-language reader has to hold the entire option
list in working memory and invert it, in a language they are translating as they go, while a timer
runs. The question stops testing the subject and starts testing processing load.

Official exam material is full of negation and you often can't change that — but everything around it
is yours. Explanations, hints, onboarding, settings labels. I write those in the positive wherever
there's a choice, and when I can't, the negation gets visual weight so it is impossible to skim past.

Double negation — "which is not permitted unless…" — I treat as a defect.

Short sentences are not dumbing down

There's a reflex, especially when the subject is regulatory, to write in the register of the source
material. Long clauses, stacked conditions, formal connectives.

That register exists for legal precision, not comprehension. You can keep the precision and lose the
sentence length: one idea per sentence, conditions as a list rather than a chain, the subject near the
verb.

What this is not is simplification of content. These are adults preparing for a professional
qualification. Patronizing them is its own failure, and they notice it faster than you'd think. The
goal is to make the language transparent so the difficulty lives entirely in the subject, which is
where it belongs.

Translation is not the same as localization

Translating a question correctly and making it answerable are different jobs.

A term of art may have no equivalent in the target language. The honest handling is often to give the
translation and keep the English term alongside it — because the test and the
examiner will both be in English. A learner who only ever sees the translated term will meet the
English one for the first time under exam conditions.

That means some things deliberately stay untranslated. Working out which is domain judgment, not a
language decision, and it's the part that can't be outsourced to a translator who doesn't know the
exam.

Icons help less than you want them to

Icons feel like the obvious fix for a language barrier. In practice they are their own vocabulary,
and one that is strongly culturally conditioned. A floppy disk means save to people who have never
seen a floppy disk, and means nothing to people who have never seen the convention.

Where icons genuinely help: reinforcing a label you have already written in words. Where they fail:
replacing it. I use them as redundancy, not as compression — the exception being domain symbols the
learner must recognize anyway, where showing them is the content.

Time pressure multiplies everything

Every problem above gets worse under a clock, and the exam has one. A sentence that costs a fluent
reader two seconds and a second-language reader eight is a rounding error in practice and a
catastrophe across a full test.

So I treat reading time as a real budget. If a screen can be understood in one pass without
re-reading, it's done. If my eye goes back, it isn't — and my eye is the easy case.

Don't make them read anything they don't have to

The highest-leverage work isn't rewriting sentences. It's removing screens.

Every piece of interface copy is a tax paid in a second language. Onboarding that explains a feature
the user could discover in two taps, a confirmation dialog for a reversible action, a tooltip
restating the label it's attached to — in English these are mild clutter. Here they are a cost with
no return.

Why this matters beyond this audience

Everything above is just good interface writing with the volume turned up. Short sentences, positive
constructions, words doing real work, fewer screens — none of it is special pleading for non-native
speakers. It's what helps a tired native speaker on a phone at eleven at night too.

Designing for the harder case makes the easy case better. It just makes the failures impossible to
ignore, which is the useful part.

I build and operate multilingual mobile applications, shipped across ten languages.
More at akmalu.com.

Most languages don't have two plural forms. Your i18n setup assumes they do.

Akmal Urunboev — Sat, 03 Oct 2026 00:08:54 +0000

If you localize an app into Russian and your string files only have one and other, your Russian
is wrong. Not awkward — wrong, in a way native speakers notice immediately and most English-speaking
teams never see.

I build multilingual mobile apps that run in ten languages, and this was the first thing that genuinely
embarrassed me.

The thing English teaches you to assume

English has two plural forms. One question, two questions. The rule is "is it 1?" and after that you
stop thinking about it. Every i18n tutorial reflects that, so the ARB or JSON you write looks like:

{
  "questionCount": "{count, plural, one{{count} question} other{{count} questions}}"
}

That is a complete specification of English. It is not a complete specification of anything else, and
the structure you write in your source language is the structure translators are handed.

What Russian actually needs

Russian uses four CLDR plural categories: one, few, many, other.

Category	Applies to	Example
`one`	1, 21, 31, 41, 101 …	1 вопрос
`few`	2–4, 22–24, 32–34 …	2 вопроса
`many`	0, 5–20, 25–30 …	5 вопросов
`other`	fractions	1.5 вопроса

Read the one row again, because it is the part that breaks code rather than translations.

21 is one in Russian. So is 31, 41, 101, 1021. If anywhere in your codebase you have written
if (count == 1) to decide singular versus plural, that branch is wrong in Russian for roughly one
number in ten. It will look fine in every test you write, because your tests use 1, 2 and 5.

Arabic goes further with six categories, including distinct zero and two. Polish, Czech,
Ukrainian and Lithuanian each have their own arrangement. The point is not to memorize them. The
point is that the number of forms is a property of the language, not of your code, and CLDR already
knows all of them.

Where it actually goes wrong

Three failure modes, in the order I hit them.

1. The source string constrains the translation. You ship an ARB with only one and other.
The translator opens it and has nowhere to put few and many. A good translator flags it. A
translator working through a spreadsheet at volume picks the closest slot and moves on, and you have
now shipped "5 вопроса" — which reads roughly like "5 questions-of" — to every user who answers
five of anything.

2. Manual pluralization in code. Somewhere there is a helper like
count == 1 ? singular : plural. It predates the i18n work, it is three lines long, and nobody
remembers it exists. It is correct in English forever and wrong in Russian from the moment you
launch.

3. Interpolated counts inside longer sentences. The plural form often has to agree with a verb
or adjective elsewhere in the sentence, which means the whole sentence is the translation unit, not
the noun. Splitting a sentence into fragments and concatenating them produces text no amount of
good translation can save.

What I do now

Write the source string with every category you might ever need, even though English collapses
most of them. Intl.plural in Dart accepts zero, one, two, few, many, other. Fill in
what English needs and leave the rest for the languages that use them, rather than handing
translators a shape that cannot hold their grammar.

Delete every manual plural branch. Grep for == 1 near anything user-facing. This is a
twenty-minute job and it finds things.

Never build a sentence by concatenation. One string, one complete sentence, placeholders inside
it. If that produces an awkward English string, the awkwardness is a signal about word order you'd
otherwise discover in production.

Test with 1, 2, 5, 21 and 0. Those five numbers hit every Russian category including the one
that catches == 1. Add 11 if you want to be thorough, since 11 is many despite ending in 1.

The part worth internalizing

This is not really a Russian problem. It is what happens when a structure designed around one
language's grammar becomes the container every other language has to fit into. Plurals are just the
most legible instance — the same thing happens with date formats, name order, honorifics and text
expansion.

The fix is cheap if you do it before translation and expensive afterwards, because by then the wrong
shape is baked into thousands of strings and a translation memory that will faithfully reproduce it.

If you are about to localize something, spend an afternoon on CLDR plural rules first. It is the
highest-return afternoon in the whole project.

I build and operate multilingual mobile applications, shipped across ten languages.
More at akmalu.com.