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.
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, and a correctly configured LLM model finishes the rest.
This is definitionally untrue. Humans define human language; a "correct" translation is one that an experienced translator would write.
But that doesn't mean that LLMs have become as good as human translators, but rather that corporations have set up a system that treats translators as if they were machines and then we act surprised when machines are better at acting machine-like than humans.
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.
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.
I am quite surprise the apps crashes on translation, but then there is a whole user action analytics engine running in parrallel, so it sounds like a problem of having too many things running at the same time ?
Companies that want high control on their translations have already the choice to straight translate their i18n strings, AI or not. That sound to me like a better choice and not much more onerous than the half-baked post filtering we're seeing in this article.
I'd argue if we're going the AI route, having it extract the user text and push it into i18n resources could be a better approach ?
the problem is if you have the user running browser extensions which modify the client code from the users' POV. they are also now mangled and not in the standard expected format by those session recording utils.
tbh sounds like it would be a small enough number of users on a big pool it wouldn't matter much in real case scenarios to me
Also, I doubt other translators work by localizing <p> elements one by one, without context. The entire HTML is localized, semantic and all. I fail to see how translating JSX instead of HTML can improve the situation much.
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.
It's like if someone requested a feature and you gave them the first thing an LLM spewed out when asked to code it, without review.
You should at least have someone on your team be able to understand the program's output and correct it when things inevitably sound off.
If not, then don't.
Yeah, I'd prefer no translation over bad translation.
If you're bilingual you must know this feeling of reading an awful translation; of knowing someone wanted to offer their product to people speaking your language but couldn't be bothered to do it well, and so used google translate and called it a day, thinking those dumb users won't notice the slop they're feeding them. Fuck that.
I love "Translate this page" in Chrome, better than nothing.
Also, if a website offers a language I take that as an indication that the organization is prepared to deal with speakers of that language/people from the country in question (customer support, shipping, regional/legal concerns). Whether the site offers a certain language is a useful signal to figure this out quickly, and if poking around reveals machine translation into dozens of languages, it's a signal that they're probably not prepared to provide reliable services/support.