Please do not do this! In almost every instance I've encountered severe Translate-related broken-ness, it's still worked well enough to get me a snapshot of the current page translated. Fighting through this is still less cumbersome than the alternatives.
> The only alternative solution that I can think of, is to implement your own localization within your app (i.e. internationalization)
I will add, please make sure that language is an independent setting, and not derived from locale! I sometimes have to use translate on sites that have my preferred language available, but won't show it to me because it's tied to locale and that changes other things that I don't want, like currency.
On one such site I used a browser extension to rewrite the request for the language strings file.
Websites already have exactly what they need to provide you with the language you want via the Accept-Language header your browser sends. In your browser's settings you can configure a list of languages (country-specific if desired) which get send with every request.
E.g.,:
en-GB
en
nl
This is already entirely separate from your OS locale! Although it will default to filling it in with that locale's language if you don't configure it yourself of course.
This should be the primary way to decide upon a language, but in addition to that offering a way to switch languages for a specific site on that site itself is a user-friendly gesture appreciated by many.
Moreover, probably most people speak or can read more than a single language. There may be reasons for accessing a site in a particular language other than the standard locale.
Please empower users to make their own choice! Do not assume to know better.
I am a Hongkonger, natively speaks Cantonese, fluent in English and learning Japanese.
If I go to Google I want English UI and prioritise traditional Chinese result then English then simplified Chinese.
On the other hand if I go to a Japanese website, I don’t want them to translate for me, just display the original Japanese will be fine. Unless I toggle.
These kind of complex setup can never be achieved if we don’t have a per site locale policy. And seriously. A toggle per site is easier than navigate three level deep into browser setting page.
If a website is made by an English speaking team, as I understand English I'd like it to be English first and not a possibly broken French version. If a website is developed with French language first I'd like to have it in French and not a second-rate English translation.
Customising this list at all makes your browser fingerprint thousands of times less common than it was before you did this, and many websites you visit could then probably uniquely identify you as the same user across all of your sessions.
Google developers are very intelligent, but not intelligent enough to understand this.
Oh god Google is so bad at this. They don't even let me change the currency in many cases when looking at hotels (yes on the website; not in the Google Maps app)
But I've received reports from Edge-users that didn't even know translation was enabled.
E.g. I'm from portugal. I'm visiting an american site, which does not have professional portuguese translations, but does have auto-generated ones.
I don't like the auto-generated ones and can read english just fine, so I want to have the language set to english (en-US in this case).
However, I still want it to apply some locale-specific things from Portugal, e.g.:
- Units (Metric vs. Imperial vs. Whatever mess countries like the UK do)
- Date formatting (DD/MM/YYYY vs MM/DD/YYYY)
- Time formatting (AM/PM vs. 24hr clock)
- Currency formatting (10€ vs. 10 € vs. 10 EUR vs. €10)
- Number formatting (10,000.00 vs 10.000,00)
- When the week starts (Monday vs. Sunday)
If you take a look at the windows locale options, it mostly lets you mix-and-match whatever you want (which is great! Now if only the MS apps let me stop using the localized keyboard shortcuts...): https://learn.microsoft.com/en-us/globalization/locale/langu...
For an example of a site that almost gets it right, see https://www.finnair.com/ . You are first prompted to set location, and then language. I say "almost" because although they will allow you to select English in any market, they won't allow you to select any offered language in any market.
In comparison, https://www.flysas.com/ you get one dropdown which sets market, currency, and language in one go.
I'm pretty sure most applications in the history of computing would not fare any better if you constructed that situation.
Google replaces an element with a different element (Text with Font containing Text?), and React's virtual DOM keeps the old, deleted elements alive because the virtual DOM still references them.
React "applications" would crash when Google Translate changes their stuff from under them if they didn't accidentally keep the old elements alive. Which would be much better behaviour.
The problem here is that react "application" builds its own state of the web page, fails to reconcile it with changes to actual state, ends up in a detached state with stale information and then proceeds to alter actual state based on the corrupted information it has.
Translators for specific chunks of the screen, yes. Selectable translators, sure. Translators you can configure to work with one application at a time.
But rewriting all text in the entire windowing environment? While preserving selection, copying, and editing? Without hooks to the underlying apps? Functionally preposterous as a proposition.
It's the responsibility of the swooper to ensure everything's put back sane.
Even in this we’re just HTML displaying information, there’s effectively this second application (Google Translate) changing the structure of the original application’s XML, which would still break display (or XPATHs) in a “normal HTML presenting information” scenario.
React and many other SPA frameworks use an additional virtual DOM which gets mapped onto the real DOM. This used to be faster 10 years ago and allowed for a unified interface.
Any addon manipulating the DOM forces the virtual DOM to go out of sync thus crashing the app.
As shown be the likes of Svelte, the virtual DOM is just legacy modern browsers are fast enough to get by without.
Actually it seems they got hit also, https://github.com/sveltejs/svelte/issues/15090
When seeing issues like this one pop up with React in the title, one should really have a good think whether this is solved principally different in other fws OR, and this should be the null hypothesis, is React in the title because it is more widely used than all the others combined
Go, get down off your high horse and try it yourself, finish the counter in their tutorial, put a console log in the handler, and translate the page to French...
C'est tres borked.
"Fortunately" it also auto-translated the "I happily accept the terms of use" checkbox in one case into (back-translated) "I happily dying die perish", which also couldn't be clicked. That lead to a very high priority ticket and made us realize that all DOM manipulators might break the site.
Got a bug report from one of our own team members that some of her greeting cards didn't show up in the list. The link appeared, but no image. We figured out that the difference was she was running an ad-blocker. We couldn't figure out precisely what rule the blocker was applying, but it seemed to be:
- image
- within some particular size bounds
- with the consecutive letters 'ad' in the URL.
... and we were using hexadecimal encodings to track individual entities in the UI.
We solved the problem by replacing 'a' with 'g' in our hex encoding. And then I had to take a long walk and accept that if I was going to do web development on the public Internet, I'd be sharing the space with intentionally-modified user agents forever, and would have to account for every such modification as we discovered it.
I still won't run my own ad-blocker for this reason.
I maintained an extension for a public website for a couple years. (It did things like, for example, adding information that was available in the API to the page, for power users.) I eventually gave up with the conclusion that the concept of a browser extension was fundamentally unsound. So I also don’t use an-blocker.
The problem with this is that it will only help sites that already put in effort to internationalization. Whereas the main target of Google translate are the sites that do not bother with i18n.
Still, it'd be quite valuable to the sites early in their internationalization journeys to get support for tons of languages right upon introducing internationalization.
This notion that you can only have DOM/CSS/Javacript on the web did not age well. There's a whole generation of programmers that built their careers on targeting that and are confusing that status quo with something that is set in stone for good reasons. Those reasons never really existed. Javascript was a bit shit but it was there so people used it. Fast forward 30 years and you still have people proving that point on a daily basis by creating very mediocre and underwhelming things with it.
WASM opens up the web to 30 years of progress in UI development elsewhere (mobile phones, game consoles, VR/AR, desktop, etc.).
What people will do with that is of course an open question. There are a few frameworks emerging but they are still kind of niche. And there are lots of attempts to bring retro UIs to the web unmodified. Links to e.g. Winamp in a browser, VB 6 running in a browser, etc. are easy to find. Some people even boot entire operating systems in a browser. I think I came across windows 95 at some point. A few versions of Linux, and some other stuff. Cool, but I'm more interested in new stuff.
The web has bit of an imagination deficit. Creativity on the web mostly died along with Flash. HTML + Javascript never managed to fill that void. Just the wrong tech for that job.
Imagine you're building a framework, and a consumer renders a clock. The only thing that changes every tick, is the text value; `00:00` becomes `00:01`. In an attempt to be as efficient as possible, it's only natural for the framework builder to decide to keep a reference to the `TextNode` and only update its `textContent` every frame. This scales the best for even the most complicated app, but it leads to interference from Google Translate as the article shows.
e.g. Input values on the HTMLInputElement are the real input, not some clone to a private object in JavaScript.
As a result of React's blatantly wrong treatment of the document.body, you have ensure that when it reuses element siblings within an arbitrary tree, that it's values are squashed to whatever private fields you're using in your component.
It screams wrong, and side effects like the one in this article make it obvious why.
No one is going to go out of their way to touch your special internal state, we're all going to use the web API to touch nodes and events from standard interfaces. You can't take the ball into a private court and expect the rest of the game to function.
By default there would be a 1:1 mapping, but things like browser extensions could write code to define how a particular bit of page dom would display to the user.