maxpr

1. I do speak more than one language. I agree with your point that perfect localization requires seeing a <p> element in the broader context of the parent component, parent page, the product, the industry, the audience and their expected level of tech savviness, the culture, and eventually preferences regarding tone of voice.

Typically, a human would need to be educated about these aspects to translate perfectly. In the future, in my opinion, humans will be educating—or configuring—the AI to do that.

The "localization compiler", which we've built to solve our own problem in the first place, is just a handy bunch of scripts aimed to help extract needed contextual hints that would then be passed on to the [preconfigured] LLM for translation, and it should go beyond just the names of the tags.

FWIW, by saying AI translations I don't mean Google Translate or machine translation tech that browsers come with. I mean actual foundational AI models that OpenAI, Anthropic, Google, Meta, Mistral and others are developing.

The difference is significant, and there's no worse thing than half-assed robotic translation produced by an MT.

2. Regarding "AI translates better than humans." I think some commenters have already mentioned this, but the point is that outsourced translations can be worse than what LLMs can produce today, because when translations are outsourced, nobody seems to care about educating the native speaker about the product and the UI. And localizing the UI, which consists of thousands of chunks of text, is nontrivial for a human. On the flip side, a correctly configured LLM, when provided with enough relevant contextual tips, shows outstanding results.

Thanks! =)

> localization is far from just translating the text

For sure, that's spot on.

What I'm excited about the most is that linguistic/cultural aspects are close to being solved by LLMs, including Gemini 2.5 that's got a huge performance boost vs the previous iteration. So, the automated approaches make more sense now, and have a chance of becoming the default, reducing i18n maintenance down to zero - and as a dev I can't be not excited about that.

P.S. fbt is great by the way, as is the team behind it. It's a shame it's archived on GitHub and isn't actively maintained anymore.

Good point. There are JavaScript tools that do that for js devs, but since oftentimes you end up having <a>links</a> and <b>nested <i>elements</i></b> in the code, wrapping becomes problematic and hard to maintain at scale.

I think there's a chance compile-time, AST/CST solutions might be the ultimate, O(1) i18n approach that doesn't distract. Ideally it should come out of the box with the framework, but perhaps this future is a little bit too far away just yet.

Exactly, this is a great direction!

We believe automatic discovery + i18n processing is the most natural next step for i18n on the web, since LLMs now exist.

And we feel that not only will industry standard i18n libraries like i18next or react-intl adopt it soon, but frameworks like next.js or remix.js themselves will make it one of their core features.

We originally built Lingo.dev Compiler scratching our own itch, but we're really excited to see how the industry will evolve from here!

I believe tRPC could be a great solution to separate logic, generally speaking. However it also depends on what type of logic - some logic, like state/behaviour of the sidebar/modals will always remain client side.

With the community support we hope to support more platforms soon vs now, but I can confidently say that adding support for techs stacks using one of the following:

Vite Rollup webpack esbuild Rspack Rolldown Farm

should be reasonably straightforward, and we expect pull requests adding other setups soon.

That's a great question!

Genuinely excited to read comments like yours. We started the project scratching our own itch, and are touched it resonated!

It will remain 100% free and open-source. We're already dogfooding it on our website and app, so if you'd like to join and contribute at some point, we'd be very happy!

Thanks for the perspective!

We support larger org workflows with the Lingo.dev Engine product, but that's not the point: Lingo.dev Compiler is unrelated to that, 100% free and open source.

We started with a thought - what if i18n is actually meant to be build-time, LLM-powered, and that's enough for it to be precise? Not today, but in the future, it feels like this type of solution could elegantly solve i18n at scale, in software, as opposed to the existing sophisticated workflows.

WDYT?