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