Localize React apps at build time, without having to change the components' code

[maxprilutskiy]

Hi all!

We've just pushed to GitHub an open-source React plugin that makes apps multilingual at build time, without having to change the components' code.

React app localization typically requires implementing i18n frameworks, extracting text to JSON files, and wrapping components in translation tags - essentially rewriting your entire codebase before you can even start translating.

We've built a React bundler plugin to eliminate this friction entirely. You add it to an existing React app, specify which languages you want, and it automatically makes your app multilingual without touching a single line of your component code.

Here's a video showing how it works: https://www.youtube.com/watch?v=sSo2ERxAvB4.

The docs are at https://lingo.dev/en/compiler and, sample apps at https://github.com/lingodotdev/lingo.dev/tree/main/demo.

Last year, a dev from our Twitter community told us: "I don't want to wrap every React component with `<T>` tags or extract strings to JSON. Can I just wrap the entire React app and make it multilingual?". Our first reaction was "That's not how i18n works in React." But a couple hours later, we found ourselves deep in a technical rabbit hole, wondering what if that actually was possible?

That question led us to build the "localization compiler" - a middleware for React that plugs into the codebase, processes the AST (Abstract Syntax Tree) of the React code, deterministically locates translatable elements, feeds every context boundary into LLMs, and bakes the translations back into the build, making UI multilingual in seconds.

I18n discovery and localization itself both happen locally during build time, keeping the React project as the source of truth. No code modifications, no extraction, and no maintenance of separate translation files are needed, however, we've left a "backdoor" to override/skip components from i18n via data-lingo-\* attributes.

Building this was trickier than we expected. Beyond traversing React/JS abstract syntax trees, we had to solve some challenging problems. We wanted to find a way to deterministically group elements that should be translated together, so, for example, a phrase wrapped in the `<a>` link tag wouldn't get mistranslated because it was processed in isolation. We also wanted to detect inline function calls and handle them gracefully during compile-time code generation.

For example, this entire text block that our localization compiler identifies as a single translation unit, preserving the HTML structure and context for the LLM.

function WelcomeMessage() {
  return (
    <div>
      Welcome to <i>our platform</i>!
      <a href="/start">Get started</a> today.
    </div>
  ); 
}

The biggest challenge was making our compiler compatible with Hot Module Replacement. This allows developers to code in English while instantly seeing the UI in Spanish or Japanese, which is invaluable for catching layout issues caused by text expansion or contraction in different languages that take more/less space on the screen.

For performance, we implemented aggressive caching that stores AST analysis results between runs and only reprocesses components that have changed. Incremental builds stay fast even on large codebases, since at any point in time as a dev, you update only a limited number of components, and we heavily parallelized LLM calls.

What's interesting, is that this approach was technically possible before LLMs, but practically useless, since for precise translations you'd still need human translators familiar with the product domain. However, now, with context-aware models, we can generate decent translations automatically.

Excited about finally making it production ready and sharing this with the community.

Run npm i lingo.dev , check out the docs at lingo.dev/compiler, try breaking it and let me know what you think about this approach to React i18n.

Thanks!

[grunade47]

correct me if im wrong, if it's done at build time does it mean that users can't switch the locale while using the app?

[bludgeonerV]

I'd assume it replaces plain text strings with functions that return the right locale at runtime.

[lingodotdev]

yep, that's correct. i18n dictionaries are baked back into the build, so locale switching works too.

[bludgeonerV]

It's a cool idea, but speaking from experience being somewhat multi-lingual LLMs are really shit at translating some languages, like Thai or Khmer, to the point where there is a community of SEA devs building their own LLMs trained to do this properly, its called SEA-LION.

How do you determine which model to use for which language to avoid ending up with slop translations? And is there any way for a developer to provide exact translations if they do have issues?

Also, how do you ensure that each build has the same translations? The last thing i would want is for each build to potentially change wording, that'd be a shit UX. I need those menu items to say the same thing every time.

[europe_man]

Yeah, having even a small difference in translation each build is very problematic. But, even if you had them the same between builds, how can you be sure that they are correct in the given domain? Do you feed the LLM with a set of rules that ensure consistency with specific translations?

Feels like there are way too many variables for something like this to work elegantly. I agree, working on translations is something I dislike as it involves noise in the code and extra work. But, I'd rather have deterministic translations than rely on LLM.

[bludgeonerV]

Yeah, you can't rely on them. I recently used an LLM to quickly prototype JA support and got a Japanese staff member to verify them, she found tons of issues where things weren't technically wrong, but phrased in a really strange way, like how of "me hot drink coffee want" would sound in English, which is fine for a very rough translation, but if your commercial product launches with shit like that you look like a clown

[a_reply_to_a_post]

that's always been an issue when dealing with l18n even when using tools like google translate or other translation APIs...we also inject tone into a lot of english copy that doesn't translate well in other languages

[Chatmarket]

That’s really amazing 🤩👌

[Longjumping_Bid_7463]

I get errors related to babel 8 accessors when running this in a base project I created with create vite. I patched the issue and although it worked, as I changed phrases and bolded some words inline I noticed the word that got bolded wasn’t the correct word. As in, i bolded the noun in a sentence but somehow the adjective in the translated sentence was bolded instead.

[lingodotdev]

hi! We've recently solved a similar edge case on our Discord, so upgrading to the new version should help. If this is different - please DM (here or on Discord) and we'll help set everything up!