Certain websites are not translated despite language tag
Categories
(Firefox :: Translations, defect)
Tracking
()
People
(Reporter: adam, Unassigned)
Details
Attachments
(1 file)
|
146.39 KB,
image/png
|
Details |
Screenshot 2024-07-14 161216.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0
Steps to reproduce:
- Enable automatic translation for Finnish
- Visit https://www.wauva.com or https://www.lastenturva.fi
Actual results:
The website is not auto-translated. The translation window shows that this language is not supported yet. See attached screenshot.
Expected results:
The websites should be translated from Finnish. The websites have lang="fi" attribute in the body, but for some reason this is not detected correctly.
|
||
Comment 1•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Translations' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•2 months ago
•
|
||
This is an interesting case where both https://www.wauva.com or https://www.lastenturva.fi seem to present a loading spinner before being dynamically populated with content.
I haven't looked into this deeply yet, but since neither of the websites present lang="fi" in the markup, I suspect that we are running the language detector on a blank page before the dynamic content populates. I occasionally get the translations icon when the page happens to load quickly on my machine.
We are currently waiting for DOMContentLoaded before reporting the markup language tag, and then running the detector if no language was specified.
I wonder if when we come up with a null from the language detector, if we could wait for an even later event to try to check dynamically populated content as a final fallback. At the point where this would execute, we are already not offering translations, so there would be no functional change if the detection fails a subsequent time (only the performance impact of trying to detect again).
The primary difference would be if something is detected from dynamically populated content, then the translations button would appear in the URL bar, or auto-translate would trigger, depending on the settings.
Greg, do you have any thoughts here?
|
||
Comment 3•2 months ago
|
||
The text here is Loading..., which is in English.
There are other events in performance metrics that might be worth looking into. I'm not sure they are fired in the DOM, but they are definitely available in the profiler.
https://share.firefox.dev/46eEUoj
There is FirstContentfulPaint and LargestContentfulPaint. We'd probably want to talk with some folks about if those are always fired, or how those heuristics are calculated.
The issue with this site is that it sends out network requests that it blocks on displaying the page so long, that it's hard to tell when they fire.
|
|
||
Comment 4•2 months ago
|
||
Actually, the solve here is much easier! We should add a mutation observer here and react to the language tag being added to the page.
|
|
||
Comment 5•2 months ago
|
||
What if there is a site that behaves similarly with regard to waiting to populate dynamic content but does not add a language tag to the markup? Wouldn't we still fail to offer/translate in that situation?
A mutation observer would be perfect, especially if a website can change its language on the fly.
Greg wrote in this ticket:
We're currently not running the language detector on every page due to performance reasons, but in the future we may explore other language detectors.
So I believe the current system relies entirely on language tags.
|
|
||
Comment 7•2 months ago
|
||
Wouldn't we still fail to offer/translate in that situation?
Yes, we would fail to, but in this particular case the site is doing the correct thing by adding a language tag, and we aren't respecting it.
I could see us also not offering when we have very low text content, like a single word here. Maybe some heuristic like if (text.length < 100) or something arbitrary like that.
Description
•