navigator.languages is empty

Bug #1620528 reported by Olivier Tilloy on 2016-09-06
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Olivier Tilloy

Bug Description

According to the doc at, 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).

Related branches

Olivier Tilloy (osomon) wrote :

Marking unav also affected because it embeds jquery-localize which trips on the empty navigator.languages (

Olivier Tilloy (osomon) wrote :

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

Changed in oxide:
status: New → Triaged
importance: Undecided → Medium
Olivier Tilloy (osomon) on 2016-09-23
Changed in oxide:
status: Triaged → In Progress
assignee: nobody → Olivier Tilloy (osomon)
Olivier Tilloy (osomon) wrote :

Note: according to,

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

Olivier Tilloy (osomon) on 2016-10-04
Changed in oxide:
milestone: none → branch-1.19
Olivier Tilloy (osomon) on 2016-10-05
Changed in oxide:
status: In Progress → Fix Released
costales (costales) wrote :

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 :

@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:

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 :

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?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers