Both Google and React are guilty here if i read the article right.
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.
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 real fix to Google Translate would be very complicated. I fear the only solution might be to elevate Google Translate to be part of the browser's rendering engine instead of acting like an extension. This would allow it to work in the rendering pipeline without modifying the DOM, but even that will probably run into site-bugs because of things like text being longer or shorter.
I don’t see why Google Translate wrapping all text in <font> elements is reasonable. Why is an extra element required, and why is it <font> of all things? Translate is swapping text for text, so this shouldn’t be necessary. It also breaks a lot more than just JavaScript frameworks. Things like the child combinator in CSS selectors will break too.
Why is an extra element required, and why is it <font> of all things?
I don't know, but perhaps due to the fact that due to the CJK unification in unicode, rendering Chinese or Japanese without explicitly setting a font designed for that particular language can output incorrect characters (of the other language, which are considered "the same character" despite being different). Thus, a translation tool would have to explicitly set a font in order to display these languages correctly in a reliable manner, because the surrounding context certainly cannot be assumed to have the appropriate font. And I could easily imagine that someone would choose to keep the same code path for all languages instead of branching for this particular case, resulting in a <font> even for languages other than those two.
I doubt that's the only case. We have multiple languages that have applied their own solutions to digital representation and the attempt to maintain backwards compatibility inevitably sets up trouble.
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?
That doesn't track with me. The React application is the website. It should be able to run while expecting some other third party thing isn't going to dig into the internals of its view and modify those internals.
It would be fine if Translate was just modifying text, but changing the actual structure of the HTML goes too far.
I mean they have to keep the old elements alive because that is the data they use to render to the DOM.
What React could do is to catch that there have been changes made to the structure of the DOM by someone other than them and then re-render the full page. Which would probably not be the most performant solution for anyone.
But anyway then people would complain that React was breaking Google Translate.
Essentially you have two applications fighting to control rendering of the application state of one of them.
Yeah, Google translate shouldn't have to "research"/reverse engineer, what kind of framework is being used on any random website it translates. It assuming, that it simply interacts with static information would still be a reasonable assumption. While Google translate is also at fault, if it changes the DOM structure. Why not leave things the same and just exchange textnodes? Seems silly.
I am just supposing, but have not checked, that if they change the text they must also change the DOM by at least changing the lang attribute on nodes affected, meaning probably the lang attribute on the html element, but could also be a lang attribute on each element wrapping a textNode.
on edit: I figured the article must have said something about this and I missed it, and yes, it shows that the DOM is changed to be lang="nl" on the html element, which means obviously if React rerenders but does not rerender the HTML element (which many React applications do not control) then the language would be out of sync, of course.
Comments
Both Google and React are guilty here if i read the article right.
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.
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 real fix to Google Translate would be very complicated. I fear the only solution might be to elevate Google Translate to be part of the browser's rendering engine instead of acting like an extension. This would allow it to work in the rendering pipeline without modifying the DOM, but even that will probably run into site-bugs because of things like text being longer or shorter.
[1]: https://martijnhols.nl/blog/everything-about-google-translat...
I don’t see why Google Translate wrapping all text in <font> elements is reasonable. Why is an extra element required, and why is it <font> of all things? Translate is swapping text for text, so this shouldn’t be necessary. It also breaks a lot more than just JavaScript frameworks. Things like the child combinator in CSS selectors will break too.
I don't know, but perhaps due to the fact that due to the CJK unification in unicode, rendering Chinese or Japanese without explicitly setting a font designed for that particular language can output incorrect characters (of the other language, which are considered "the same character" despite being different). Thus, a translation tool would have to explicitly set a font in order to display these languages correctly in a reliable manner, because the surrounding context certainly cannot be assumed to have the appropriate font. And I could easily imagine that someone would choose to keep the same code path for all languages instead of branching for this particular case, resulting in a <font> even for languages other than those two.
I doubt that's the only case. We have multiple languages that have applied their own solutions to digital representation and the attempt to maintain backwards compatibility inevitably sets up trouble.
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
That doesn't track with me. The React application is the website. It should be able to run while expecting some other third party thing isn't going to dig into the internals of its view and modify those internals.
It would be fine if Translate was just modifying text, but changing the actual structure of the HTML goes too far.
I mean they have to keep the old elements alive because that is the data they use to render to the DOM.
What React could do is to catch that there have been changes made to the structure of the DOM by someone other than them and then re-render the full page. Which would probably not be the most performant solution for anyone.
But anyway then people would complain that React was breaking Google Translate.
Essentially you have two applications fighting to control rendering of the application state of one of them.
Yeah, Google translate shouldn't have to "research"/reverse engineer, what kind of framework is being used on any random website it translates. It assuming, that it simply interacts with static information would still be a reasonable assumption. While Google translate is also at fault, if it changes the DOM structure. Why not leave things the same and just exchange textnodes? Seems silly.
I am just supposing, but have not checked, that if they change the text they must also change the DOM by at least changing the lang attribute on nodes affected, meaning probably the lang attribute on the html element, but could also be a lang attribute on each element wrapping a textNode.
on edit: I figured the article must have said something about this and I missed it, and yes, it shows that the DOM is changed to be lang="nl" on the html element, which means obviously if React rerenders but does not rerender the HTML element (which many React applications do not control) then the language would be out of sync, of course.