When we started building Azma Finance — an online accounting platform for small businesses in Uzbekistan — we knew localization would be important. We didn't know it would become one of our biggest engineering and product challenges.

Here's what we learned after shipping in four languages: Uzbek, Russian, English, and Chinese.

Why four languages?

Uzbekistan is genuinely multilingual. Most people over 35 are comfortable in Russian. The younger generation prefers Uzbek. Foreign investors and expats need English. And with a growing wave of Chinese businesses entering the Central Asian market, Mandarin became a real business need — not a nice-to-have.

Skip any of these, and you're leaving a meaningful chunk of users behind.

Lesson 1: Language is not just translation

The hardest part wasn't translating strings — it was context. In Uzbek, formal and informal address completely change the tone of UI copy. In Russian, nouns have grammatical gender that affects button labels. In Chinese, the same concept can require a completely different explanation because the business culture around accounting is different.

We learned quickly: don't hand a spreadsheet of strings to a translator and call it done. You need someone who understands your product and the language.

Lesson 2: RTL isn't your only layout problem

We didn't have RTL to deal with, but we did have text expansion. Russian strings are typically 30–40% longer than their English equivalents. Uzbek in Latin script is closer to English in length, but Uzbek in Cyrillic (still used by many) is longer again.

Buttons that look clean in English break in Russian. Modals overflow. Tables wrap awkwardly.

Fix: Design with Russian as your "stress test" language. If a UI element holds in Russian, it'll hold in everything else.

Lesson 3: Locale goes deeper than language

Date formats, number formats, currency display — these all differ. In Uzbekistan, the currency is UZS (Uzbek soum), and large numbers are written differently than in Western contexts. Tax reporting has its own terminology that doesn't map cleanly to international accounting language.

We had to build a locale layer that handled not just i18n strings, but business logic formatting too.

Lesson 4: Let users switch language instantly — no page reload

This sounds obvious but it's easy to get wrong early on. We initially built language switching as a full page reload with a URL prefix (/ru, /uz, /en). It worked, but it felt sluggish and lost form state.

Moving to in-memory locale switching (with the URL update happening silently) made the experience feel much more native.

Lesson 5: English opens unexpected doors

We added English primarily for foreign-owned businesses in Uzbekistan. But English content also helped us reach the diaspora — Uzbek entrepreneurs living abroad who want to register and manage a business back home remotely.

It also made our product legible to international investors. Sometimes EN is less about language and more about signal.

• Start with a proper i18n library from day one (we refactored mid-build)
• Build a translation management system early — spreadsheets don't scale past two languages
• Involve native speakers in UX review, not just translation

Building for a multilingual market in Central Asia is genuinely interesting engineering. The region is growing fast, the problems are real, and the solutions can't just be copy-pasted from Western SaaS playbooks.

If you're building something similar — or thinking about expanding into this market — happy to talk -> https://azmafinance.com/talk-to-expert