Live data from Hacker News

Everything about Google Translate crashing React (and other web apps)

martijnhols.nl

41–50 of 88 posts

Re: Everything about Google Translate crashing React (and other web apps)

#42
post #8

> When I first ran into this issue back in 2017, I posted in the React issue tracker that I had ”fixed” my app by blocking translation entirely. 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 alternat…

> that changes other things that I don't want, like currency.

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)

Re: Everything about Google Translate crashing React (and other web apps)

#43
post #33

Earlier quoted context omitted.

> I will add, please make sure that language is an independent setting, and not derived from locale! 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 (Prefer British English, fall ba…

> In your browser's settings you can configure a list of languages (country-specific if desired) which get send with every request. 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.

That and a thousand other things. A highly privacy focussed browser could offer to enable this setting only on whitelisted websites (and send 'en' plus a bunch of random language codes on others).

Re: Everything about Google Translate crashing React (and other web apps)

#44
post #2

Last part of the post hints at a possible future for SPAs: wasm. No DOM modified by browser extensions so no surprise.

Or switching back to desktop apps? Also no DOM manipulation there. :-)

WASM enables us to bring what we were doing there to the web. The distinction always was a bit artificial.

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.

Re: Everything about Google Translate crashing React (and other web apps)

#45

Earlier quoted context omitted.

They both do reasonable things, so I wouldn't really blame either. Google Translate was there first and is a big accessibility advantage for the web. At the same time, Google Translate is the user-specific browser extension that is executed last, on top of existing apps. It affects not just React[1], so even if React were to implement a fix, Google Translate would continue to interfere with other webapps. I think any…

Obviously you could code your site for handling these kinds of linguistic difficulties (text longer or shorter) but its been my experience even sites that are supposed to be internationalized do not do a good enough job of taking cross-language display difficulties into consideration, so I don't think people will think, sure my site is in English, but what if Google Translate turns it into Greenlandic?

Chinese/Japanese -> everything else.

They're so terse, two Unicode characters can be like 10+ letters lol

Sometimes I translate to understand the page then refresh to use it unborked in the original language

Re: Everything about Google Translate crashing React (and other web apps)

#46

Earlier quoted context omitted.

Or switching back to desktop apps? Also no DOM manipulation there. :-)

WASM enables us to bring what we were doing there to the web. The distinction always was a bit artificial. 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 s…

> Creativity on the web mostly died along with Flash.

Even being anti flash sites at the time, I can't deny it allowed many fun experiences with browser games which look absent today.

Re: Everything about Google Translate crashing React (and other web apps)

#47
post #3

So the fundamental problem is the DOM is too inefficient to do applications on it. No surprise there, considering the original design of HTML was for presenting information, not for interactive applications.

That is not the case anymore. 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.

Virtual DOM or not doesn't matter, even Svelte has the potential to be disrupted by these Google translate shenanigans since it manipulates the DOM.

Actually it seems they got hit also, https://github.com/sveltejs/svelte/issues/15090

Re: Everything about Google Translate crashing React (and other web apps)

#48
post #42
post #8

> When I first ran into this issue back in 2017, I posted in the React issue tracker that I had ”fixed” my app by blocking translation entirely. 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 alternat…

> that changes other things that I don't want, like currency. 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)

Google is so ridiculously bad at this, when an account that only ever uses English is explicitly asking for English search results, but happens to be located in Thailand, it will give you English results, but use the Thai calendar to display years, which is 543 years ahead of the Gregorian calendar. Are there any people at all who expect to read English text but expect to see the year 2568 instead of the year 2025, when no part of their system or account is configured for Thai?

Re: Everything about Google Translate crashing React (and other web apps)

#49
I had to learn this the hard way when a React app I built showed random crashes I couldn't explain.

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

Post reply on HN