> 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.
For HTML, it probably needs to be extended to the HTML fragments themselves. And with React, it's pretty easy to actually extract the text fragments in {} segments.
> Then, you simply ask it to translate into other languages.
Yep! With Lingo.dev Compiler though, we were scratching our own itch, and particularly it was maintenance of the localized code. Turned out, extracting is fine, but then further down the road we found ourselves digging through the code and jumping back and forth between the code and i18n files.
I think it won't be a problem anymore after "Just In Time software" becomes a thing, and vibe coding tools seem to be getting us closer to that point.
I think modern Japanese is LTR, but besides that - I believe the project you worked in the past solves an important problem.
Besides pluralization (and e.g. Arabic having 6 forms zero/one/two/few/many/other), turned out number internationalization and currency conversion are big next challenges the community wants to address next.
> create ICU compliant JSON.
I think this is an excellent idea. I have a feeling in the future we will need ICU v2.0, sort of, but unfortunately it's an extremely hard problem and the probability to fail is pretty high (looks like project fluent is not actively maintained anymore: https://github.com/projectfluent/fluent)
Depends on the medium. EPUB 2.0 (and later revisions) specifically supports vertical RTL text for use-cases like Japanese novels. Additionally, many novel reading websites support toggling between vertical and horizontal text. Vertical text implicitly switches to RTL text direction.
Of course, this is not a general use case. But saying "modern Japanese is LTR" is not quite accurate. Computer / digital media is commonly LTR and horizontal, but a single step outside exposes one to vertical text, and RTL text in physical newspapers, literature, comics, a subset of textbooks, and handwritten signs that try to look "traditional" in style.
Perhaps I could've communicated this better, but we've built Lingo.dev Compiler for web apps and user interfaces, not for technical/professional content.
And since we had to exclude certain terms like "Lingo.dev Compiler" itself from i18n, we've shipped support for data-lingo-skip and data-lingo-override-<locale-code> as well.
Regarding using LLMs for production content localization, I recommend checking out how Reddit translates their entire user-generated content base in 35 languages using AI:
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.
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!
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.
That’s fine for small projects or startups.
Once you go into large organizations, where you have an ever changing glossary, and product wants to be in control of the texts in the application, doing it all in prompts and dev changes completely breaks translation workflows.
> 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.