navigator.languages is empty
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Oxide |
Medium
|
Olivier Tilloy | ||
| uNav |
Wishlist
|
costales |
Bug Description
According to the doc at https:/
On my system in a simple WebView I’m seeing navigator.language == "fr-FR" (expected) and navigator.languages == [] (empty array, not expected).
Related branches
- Chris Coulson: Needs Fixing on 2016-10-05
-
Diff: 143 lines (+73/-3)6 files modifiedqt/quick/api/oxideqquickwebcontext.cc (+2/-1)
qt/tests/qmltests/web_platform/tst_navigator_languages.qml (+50/-0)
shared/browser/oxide_user_agent_settings.cc (+4/-0)
shared/browser/oxide_user_agent_settings_observer.h (+2/-0)
shared/browser/web_contents_helper.cc (+14/-2)
shared/browser/web_contents_helper.h (+1/-0)
Olivier Tilloy (osomon) wrote : | #1 |
Olivier Tilloy (osomon) wrote : | #2 |
It appears content:
Changed in oxide: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in oxide: | |
status: | Triaged → In Progress |
assignee: | nobody → Olivier Tilloy (osomon) |
Olivier Tilloy (osomon) wrote : | #3 |
Note: according to https:/
« The value of navigator.language is the first element of the returned array. »
This is not the case in oxide, nor is it the case in chromium on desktop, where I have:
navigator.
navigator.
So if that should be considered a bug, it’s a different one than this one.
Changed in oxide: | |
milestone: | none → branch-1.19 |
Changed in oxide: | |
status: | In Progress → Fix Released |
costales (costales) wrote : | #4 |
The current mode for getting translations is not good for explore all languages. I'll keep the bug in mind anywhere :) Thanks Olivier!
Changed in unav: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
assignee: | nobody → costales (costales) |
Olivier Tilloy (osomon) wrote : | #5 |
@Marcos: what do you mean by "the current mode for getting translations is not good for explore all languages"? Note that this issue is fixed in oxide 1.19, and it has been worked around in jquery-localize here: https:/
Hi Olivier,
I understand with this fix that if uNav doesn't find the 1st language,
it would search in the 2nd.
But the current code is not good for that recursive search loop. Then
uNav will look only the 1st language.
Best regards and thanks mate! :))
Olivier Tilloy (osomon) wrote : | #7 |
Right. Hopefully the preferred language (navigator.
Correct me if I’m wrong, but I don’t think that other GUI toolkits/desktop environments will fall back on a second preferred language if the first one is not found. I.e. on your desktop an app would either be in Asturian or in English if the Asturian translation doesn’t exist, not in Spanish as a fallback. Right?
Marking unav also affected because it embeds jquery-localize which trips on the empty navigator.languages (https:/ /github. com/coderifous/ jquery- localize/ pull/74).