Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Localize React apps without rewriting code

github.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: Show HN: Localize React apps without rewriting code

#51

Post by maxpr »

exhaze wrote: post #34

Cool 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 tha…

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.

Re: Show HN: Localize React apps without rewriting code

#52

Post by maxpr »

makeitdouble wrote: post #38
maxpr wrote: post #11

Earlier quoted context omitted.

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

Historically, there are a couple of reasons why developers prefer to i18n their app instead of letting users do that.

1. PostHog has a great tool that lets developers "watch the video" of how users interact with their app's UI. Turns out, automated chrome plugins/built-in features often mess up the HTML so much that apps simply crash. I've seen devs adding translate="no" [0] in bulk to their apps because of this. Therefore, Chrome's built-in auto translation isn't the best solution (yet). 2. Product/marketing folks want users to see content in their language immediately after landing on the website 3. App developers often want to control what users see, update it, rephrase it

If I had to guess, I'd say the approach Lingo.dev Compiler package is using today should end up being a natural part of frameworks like Remix, Next.js and Vue.

[0] https://www.w3schools.com/tags/att_translate.asp

Re: Show HN: Localize React apps without rewriting code

#53

Post by koito17 »

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…

> I think modern Japanese is LTR

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.

Re: Show HN: Localize React apps without rewriting code

#54

Post by amake »

maelito wrote: post #14
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.

And just say "sorry" to all the people asking you for translation of your great product ?

If it's worth doing, then it's worth doing correctly.

If not, then don't.

Re: Show HN: Localize React apps without rewriting code

#55

Post by amake »

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?

Yes.

Re: Show HN: Localize React apps without rewriting code

#56

Post by thomasfromcdnjs »

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?

There are some passionate naysayers in here.

I love "Translate this page" in Chrome, better than nothing.

Re: Show HN: Localize React apps without rewriting code

#57

Post by cyberax »

maxpr wrote: post #47
cyberax wrote: post #44

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

Good point. There are JavaScript tools that do that for js devs, but since oftentimes you end up having links and nested elements 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 b…

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.

Re: Show HN: Localize React apps without rewriting code

#59

Post by maxpr »

thrance wrote: post #50
maxpr wrote: post #11

Earlier quoted context omitted.

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

Do you speak more than one language? Because claiming "AI translates better than human" is ludicrous. Anyone with a modicum of experience on browsing the internet can immediately tell when a page was auto-translated, based on how awkward or outright nonsensical some of the text can be. Also, I doubt other translators work by localizing elements one by one, without context. The entire HTML is localized, semantic and a…

1. I do speak more than one language. I agree with your point that perfect localization requires seeing a

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.

Post reply on HN