navigator.languages is empty

[Olivier Tilloy]

According to the doc at https://w3c.github.io/html/webappapis.html#language-preferences, navigator.languages should always contain at least one value (navigator.language).

On my system in a simple WebView I’m seeing navigator.language == "fr-FR" (expected) and navigator.languages == [] (empty array, not expected).

[Olivier Tilloy (osomon)]

Marking unav also affected because it embeds jquery-localize which trips on the empty navigator.languages (https://github.com/coderifous/jquery-localize/pull/74).

[Olivier Tilloy (osomon)]

It appears content::RendererPreferences::accept_languages needs to be explicitly set.

[Olivier Tilloy (osomon)]

Note: according to https://developer.mozilla.org/en-US/docs/Web/API/NavigatorLanguage/languages,

  « 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.language = "fr"
  navigator.languages = ["en-US", "en", "fr-FR", "fr", "ca", "es"]

So if that should be considered a bug, it’s a different one than this one.

[costales (costales)]

The current mode for getting translations is not good for explore all languages. I'll keep the bug in mind anywhere :) Thanks Olivier!

[Olivier Tilloy (osomon)]

@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://github.com/coderifous/jquery-localize/commit/0e493bd.

[costales (costales)]

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)]

Right. Hopefully the preferred language (navigator.languages[0]) is there.

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?