Please, please, please, do not use auto translators to localize your pages. There's nothing worse than an half-assed translation that was obviously made by a machine.
Auto-translated sentences are awkward and I feel extremely insulted every time someone chooses to impose this garbage watered-down version of their products on me.
Hire a translator or don't localize your site.
This needs to integrate with translation management formats/services instead of an LLM—it might work for some cases but will absolutely butcher jargon translations! In its current state it is worse than useless for sites managing content geared for technical/professional audiences.
Cool project! I built a similar tool [0] last year, but:
1. Targeting fbt (Meta's internal i18n tool)
2. Used CST (<3 ast-grep) instead of AST - really useful here IMO esp. for any heuristic-based checks.
3. Fun fact: this was made entirely on my phone (~2.5h) while I was walking around Tokyo. Voice prompting + o1-pro. Why? My friend was working on porting fbt to TS and said he was planning to build this. I wanted to one-up him + convince him to start using LLMs =)
One thing you should be aware of is that for at least Japanese, localization is far from just translating the text. There are lots and lots of Japan-specific cultural nuances you have to take into account for web users and even down to actually just having an entirely different design for your landing page often because those you'll find those just convert better when you know certain things are done that are typically not done for you know non-Japan websites.
Notta (multi-lingual meeting transcriptions + reports) is a great example if you compare their Japanese [1] and English [2] landing pages.
Note how drastically different the landing pages are. Furthermore, even linguistically, Japanese remains a challenge for proper context-dependent interpretation. Gemini 2.5 actually likely performs best for this thanks to Shane Gu [3], who's put in tons of work into having it perform well for Japanese (as well as other "tough" languages)
[0] https://github.com/f8n-ai/fbtee-migrate
[1] https://www.notta.ai (Japanese version)
[2] https://www.notta.ai/en (English version)
I thought this was awesome until you included an LLM into the mix.
I hate the current react i18n solutions, and the fact that they only work in runtime, as opposed to Angular’s build time i18n solution.
If your compiler could plugin to existing localization workflows in large organizations to at would be great (ie: extraction, load from configuration).
How do you deal with specific wording that needs to be used in certain languages (often required for legal topics) or specific brand-related messages that need to be in place without any modifications? Does a developer still have the ability to manually translate certain strings?
Hi, early user here :) Liking the product so far. We just started using the CLI parts for our RN app, with your cloud translations.
Few things to put on your roadmap if they aren't on it yet:
- Would like it if we could set the model per language. I'm sure you do your best trying to find the best one for each language, but in our experience some of them aren't optimal yet.
- Multiple source languages would be cool. Example: It can make sense to have JA as source for KO but EN as source for FR. Or probably better, sending both (e.g. EN + JA when doing KO).
- MCP doesn't seem to be working (we posted a log on the discord)
- We seem to have spotted cases where key names were taken into account a little too much when translating, but understand this is super hard to tune and can be fixed by improving our keys.
> essentially rewriting your entire codebase before you can even start translating
I’d say it just takes a few prompts in Cursor or a similar tool.
Then, you simply ask it to translate into other languages. Here’s how I did it for one of my projects - a quantum optics simulator: https://p.migdal.pl/blog/2025/04/vibe-translating-quantum-fl...
Doing it at runtime might make sense for a typical translation. But for scientific (or engineering) content, we often want to verify the output. Translating in production can be wonderful, hilarious, or just inconsistent.
This is an ultra cool product - stoked someone is building this. We've internationalized our product using ChatGPT O-1 in the JSON files and it's been a real pain to try to decode the strings and otherwise for the text that is in the code.
Definitely going to ask my cofounder to look into implementing this.
- Are there other use cases for this tech besides language translation? Wondering if there are other eng problems that something like this could solve.
- Where are you guys thinking of taking this next? Seems like you're able to handle a lot of languages, so are you just continuing to refine the product or what's the plan for the next couple months and years?
Thanks for tackling this!
I just remembered I built a tool to list all hardcoded strings from a React project in a similar way by parsing the AST.
Many moons ago, a small project called GNU Gettext did this. It worked by annotating the translatable string literals like this _("SomeLine"), then a separate compiler extracted all the strings into a `.po` file.
And then you just translated them. The English text, essentially, becomes your string ID.
It worked super well, with very low friction for programmers. You didn't have to invent an identifier when writing code, and then switch to a horrible JSON with indefinitely long lists of strings.
But somehow, the world chose the horribly bad "string IDs" method of translation. Sigh.
This is great. I have worked at many companies and dealt with i18n many times. It was often half baked and frustrating. Not to mention the annoyance of needing to introduce localization to a project that had none before. I often pondered creating a util to improve this space, but looks like you've done the work already. And using LLMs, injecting into the builds, I think this is a great choice for a problem that can be made more efficient by LLMs in their current state.
I'm trying to understand if it works with an Electron (or Tauri) app on desktop? Cannot find any mention on the website. And how it works with apps that are not bases on React Router or anything similar, so it cannot learn all the possible screens.
This is exactly what I was looking for to translate cartes.app, an open-source alternative to Google maps. Thank you, I'll try.
> 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.
Very cool
Does the compiler work with react native (expo)?
does it work with Next.js page router apps?
“Translate” has a lot of meanings in CS, I thought this was going to be able porting to a different framework or something. “Localize” would be clearer
[dead]
> ``` function WelcomeMessage() { return ( <div> Welcome to <i>our platform</i>! <a href="/start">Get started</a> today. </div> ); } ```
Not the point here, but is there any move yet in React to separating the presentation from the logic[1]?
1 - https://martinfowler.com/eaaDev/SeparatedPresentation.html
I worked on a project at Patreon to do something similar many years ago. We used a babel plugin to do the translation with as few changes to the code base as possible.
This application does not handle many important considerations for translation. Such as pluralization. In many languages there are multiple more ways to pluralize words. Russian has many different ways to pluralize. More problems will occur when you have words within words.
There is no way to do this without working on changing your codebase. I think what would work better is if you can create ICU compliant JSON.
How are you supposed to have this work in Japanese when it's RTL instead of LTR? That will require UI and localization challenges.
I think using AI to do translation will be fine for startups, but I'm not sure how well this will work on real production apps. I think significant work will be required to actually get this working:
https://stelejs.com