Skip to content
August 8, 2026 · 3 MIN READ · Journal

Localization done right (or close to it)

Localization is one of those things that looks like a config switch in your IDE and turns out to be a six-month conversation with strangers about the gender of nouns.

For a small studio, it’s also one of the best investments we can make. A typing trainer, a garden planner or a migraine tracker is just as useful in Lisbon as in London, and people are far more likely to trust an app that speaks to them in their own language. The catch is that doing it properly is much more work than it first appears.

Our setup

We ship in English first, then add more languages over the lifetime of an app. Every translation is checked in context against screenshots of the actual interface, and we fix whatever reads wrong before it ships.

The in-context step is the one most teams skip, and it’s where most of the problems show up. A translation can be perfectly correct in a spreadsheet and still wrong on screen: a button label that’s accurate but twice as long as the space it sits in, a word that means the right thing in general but the wrong thing next to a particular icon. So we generate screenshots of every screen in every language and look at them, one by one.

We also write the English with translation in mind. Short sentences, no idioms, no jokes that depend on a pun. Strings that need context — is “Clear” a verb or an adjective here? — get a note for the translator. It makes the English a little plainer, and we think it’s better for it.

The non-obvious parts

Date and number formats matter more than translated copy. Plural forms are language-specific in ways English-speakers chronically underestimate (some languages have six). Right-to-left layouts aren’t a CSS trick — they affect how every chevron, every back-button, every progress indicator is drawn.

A few more we’ve learned to watch for:

  • Text expansion. German and Finnish labels can run much longer than English ones, so layouts need room to grow or wrap gracefully.
  • Units. A fishing forecast that shows wind speed in an unfamiliar unit isn’t just odd, it’s useless.
  • Store listings. The app is only half of it — descriptions, screenshots and captions have to be localized too, separately for every store.
  • Keyboards. For a typing trainer, localization isn’t only words; it’s layouts, characters and the way people actually type in that language.

What we got wrong

We’ve made every one of these mistakes at least once. The most expensive was treating localization as a final step — building the whole interface in English, then discovering that half the screens broke in longer languages. Fixing layouts after the fact meant redesigning screens we’d already called finished.

The trade-off we now accept is slower first releases: a new feature isn’t done until it works in every language the app supports. Our checklist now starts with the fixes for these mistakes, so we make them less often. Close to right, most of the time, is the honest version of the title.