Launching a new language used to mean weeks of work: building a translation team or bringing in vendors, with costs that scaled linearly with the number of languages. Today, that process runs through the same pull requests and CI/CD pipelines developers already use every day.
We spoke with Pavel Zavialov, a backend engineer who has built distributed systems and automation infrastructure at VK and Wheely, about the i18n service he designed, which runs machine translation through the same workflow – cutting time-to-ship for a new language from weeks to hours. He explains how the pipeline works end to end, how the model handles context and plural forms across dozens of languages, how RTL support fits in, which LLM advances made this production-ready, and why the localization engineer’s role has shifted rather than disappeared.
1. Let’s start with the economics. How does the operating cost of an automated pipeline compare to the legacy translation model?
Pavel Zavialov:
In the classic approach, every new language means growing a translation team or bringing in vendors. Cost scales linearly with the number of languages and the content volume, and it’s slow: shipping a new language can take weeks.
What changed is that operating cost moved out of the human-labor column and into computing. LLM API calls are predictable, controllable, and scale far better than headcount. The practical result: we removed manual translation as the bottleneck and cut time-to-ship from weeks to hours.
2. Walk us through the pipeline. A developer adds a string: what happens between that commit and the translation landing across your repositories?
Pavel Zavialov:
The whole system is built around the .po (Portable Object) format, the de facto standard for localization. It stores source strings and translation pairs, supports plural forms, context, and comments, and serves as a single abstraction layer across backend, frontend, and mobile.
The flow: a developer adds a new key in code. CI/CD automatically extracts new strings, updates the relevant .po files, and opens a pull request. The developer validates only the base language they actually understand. Once that’s approved, a single translation command starts the AI pipeline, which translates into all supported languages at once and applies context and domain rules. Automated checks run next, then the changes are committed back: the i18n service and the corresponding frontend and mobile repositories update together. From a developer’s perspective, it feels like a native part of building the product. They work with code, not with translations.
3. Context is one of the hardest problems in UI translation. How did you get the model to consistently translate strings with the right meaning?
Pavel Zavialov:
Context was the hardest part early on.
First, when introducing a new language, we translate entire .po files rather than individual strings. That gives the LLM enough context to understand the UI’s meaning.
Second, we use translator comments supported by the .po format. Developers can add instructions for ambiguous or domain-specific strings, and those comments are included in the prompt. This allows us to guide the model when a literal translation isn’t appropriate.
Third, translating an entire file isn’t practical for everyday changes. For new keys, we first translate and validate them in a single language the team understands. That validated translation is then used as additional context when generating translations for all remaining languages. This gives us good quality while keeping token usage under control.
4. Handling plural forms and punctuation across dozens of languages is another challenge entirely. How does the system manage those without constant human intervention?
Pavel Zavialov:
This is exactly where “just translate the strings” stops working. Plural forms vary enormously: English has two (one and other); Russian has three forms, Arabic has six, with rules that depend on the number in non-trivial ways. Early on, we tried encoding per-language rules directly in prompts, but that scaled poorly.
As models matured, we moved to a more general approach: pass the model the entire block of plural forms and require a strictly defined output structure, with all forms returned at once. On top of that, we added algorithmic validation to check that all required forms are present, the plural block structure is intact, and variables and placeholders (%1$s, %d, %s) are preserved correctly.
Punctuation is a separate class of problems. Logographic languages like Chinese and Japanese use their own punctuation marks; Greek uses the semicolon as a question mark. The LLM can sometimes mix or duplicate them. Here, we added automated checks and normalization that catch anomalies before they reach the product. The end result is a hybrid: the LLM handles language understanding and generation, while deterministic validation ensures structural correctness.
5. System also outputs ready-to-use resource files for the frontend and mobile, including RTL languages. How do you ensure the output actually fits UI constraints on each platform?
Pavel Zavialov:
This is not only a translation problem; it’s a rendering problem that requires joint work with the frontend and mobile teams.
Two issues matter most. First, string length: German often produces the longest strings among European languages, so interfaces are designed with width to spare, and platform teams run the UI in different languages to surface overflow problems. Second, text direction: for RTL languages like Arabic and Hebrew, it’s not enough to translate the text; the entire interface direction changes, including element order, alignment, and scroll direction. That’s supported at the level of UI frameworks and the design system, not in the strings themselves. The localization side guarantees clean data, no broken strings, and no mixed text directions. The platform teams handle RTL rendering and run automated layout checks on top of it.
6. Which AI capabilities were the tipping point that made this viable at a production level?
Pavel Zavialov:
It wasn’t one specific feature but a combination of improvements that together made the task solvable. First, a sharp increase in context understanding: newer models like GPT-4 began to reliably grasp the meaning of whole blocks of text rather than just isolated phrases, which is critical for UI and business logic. Second, reliable placeholder handling: earlier models would frequently break or reorder variables like %s and %d; newer models learned to preserve and place them correctly according to each language’s grammar, which made automated translation possible without a layer of manual fixes. Third, the larger context window enabled bulk translation and better cross-string coherence.
In sum, context understanding, correct formatting, and stable quality – that combination turned automated localization from an experiment into a working engineering solution.
7. Given how much of this you’ve automated, is the traditional localization engineer role becoming obsolete?
Pavel Zavialov:
Part of the function has gone away or sped up considerably. What used to require manual work, basic translation, file generation, and first-pass review is now largely automated. But the role didn’t disappear; it shifted toward deeper expertise.
Even a linguistically perfect translation can be wrong from a product standpoint. This is especially visible in critical flows, payments, accepting terms, and actions that affect penalties or money. A short, formally correct phrase that ignores interface context can confuse the user or lead to the wrong decision. That requires someone who understands both the language and the product.
AI takes over the routine work, but the key role of engineers remains: understanding product context and configuring the system itself.
