I just remembered I built a tool to list all hardcoded strings from a React project in a similar way by parsing the AST. https://github.com/benmerckx/find-jsx-strings
[deleted]
Show HN: Localize React apps without rewriting code
31–40 of 75 posts
Re: Show HN: Localize React apps without rewriting code
#32I just remembered I built a tool to list all hardcoded strings from a React project in a similar way by parsing the AST. https://github.com/benmerckx/find-jsx-strings
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!
Re: Show HN: Localize React apps without rewriting code
#33Earlier quoted context omitted.
One simple idea* would be an option to exclude certain React elements from auto translation. That would allow users to handle these specific cases “manually” while still reaping the benefits of the automated system the other 99% of the time. * worth exactly what you paid for it ;)
...or having an "override" file that allows manual specification regardless about what the LLM spits out.
we've added support for both these cases actually! :)
1. `data-lingo-skip` - excludes a jsx node from i18n 2. `data-lingo-override-` - overrides version in language with a custom value 3. also `data-lingo-context`
(docs, perhaps, aren't yet the best, but here they are: https://lingo.dev/compiler/configuration/advanced)
Re: Show HN: Localize React apps without rewriting code
#34Cool project! I built a similar tool [0] last year, but:
1. Targeting fbt (Meta's internal i18n tool)
2. Used CST (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)
Re: Show HN: Localize React apps without rewriting code
#35This 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.
Re: Show HN: Localize React apps without rewriting code
#36Please, 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.
> half-assed translation that was obviously made by a machine That's exactly what we want to solve. Here's the thing: It turned out, AI translates better than humans when provided with enough correct context. Both macro context, like what the product does, and micro context, like what the component represents on screen and how it relates to other components. As a result, algorithms extract the needed contextual hints…
> AI translates better than humans when provided with enough correct context
This is definitionally untrue. Humans define human language; a "correct" translation is one that an experienced translator would write.
Re: Show HN: Localize React apps without rewriting code
#37Please, 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.
Would you literally rather have nothing than a poor translation?
In some cases, yes. A non-native but passable speaker/reader of English might prefer to struggle through the English UI themselves than deal with your bad AI-generated translation. If they do it themselves, at least they can skip the parts they know, see multiple possible translations, and take advantage of their partial knowledge of the UI language. If you dump everything into an LLM with no knowledge of your target languages at all, you’re setting yourself up for disaster when a critical string is mistranslated.
Re: Show HN: Localize React apps without rewriting code
#38Please, 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.
> half-assed translation that was obviously made by a machine That's exactly what we want to solve. Here's the thing: It turned out, AI translates better than humans when provided with enough correct context. Both macro context, like what the product does, and micro context, like what the component represents on screen and how it relates to other components. As a result, algorithms extract the needed contextual hints…
What I always wondered: why is your automatic translation better than the browser's or the user's own auto translation ?
In particular, having it user side makes it fully opt-in, and the user has full control and will accept the quality as it is, whereas your service-side auto translate is your responsibility when shit hits the fan.
Re: Show HN: Localize React apps without rewriting code
#39Please, 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.
And just say "sorry" to all the people asking you for translation of your great product ?
They're asking for a reliable translation, otherwise they'd just let their browser auto-translate the page.
Re: Show HN: Localize React apps without rewriting code
#40> 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.