Show HN: Localize React apps without rewriting code

Post by cluckindan » Wed, Jun 04, 2025, 4:50 AM UTC

maxpr wrote: post #43

cluckindan wrote: post #35

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.

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- as well. Regarding using LLMs for production content localization, I recommend checking out how Reddit translates…

Post by devmor » Wed, Jun 04, 2025, 5:52 AM UTC

maxpr wrote: post #13

devmor wrote: post #9

Earlier quoted context omitted.

I would rethink this decision. Localization requires understanding intent and adjusting terminology to apply non-literal interpretations to convey meaning; this project uses an auto-translator.

Interesting perspective. Unsure if I communicated it well, but unlike auto-translators such as Google Translate, this project leverages a context-aware LLM to recreate the meaning and intent of the original text in another language.

Post by benbayard » Wed, Jun 04, 2025, 6:54 AM UTC

maxpr wrote: post #45

benbayard wrote: post #41

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 ha…

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…

Post by autumnstwilight » Wed, Jun 04, 2025, 8:00 AM UTC

thierrydamiba wrote: post #15

thrance wrote: post #8

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.

Would you literally rather have nothing than a poor translation?

Post by halflife » Wed, Jun 04, 2025, 10:58 AM UTC

maxpr wrote: post #23

halflife wrote: post #21

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).

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…