Web browser should send the system language to websites (Accept-Language field)

Status changed to 'Confirmed' because the bug affects multiple users.

The code is already there in oxide to support a localized Accept-Language header, but it appears that the translation files needed for this are not being installed.

At package build time translations are generated under /usr/share/locale/$LANG/LC_MESSAGES/oxide-qt.mo.
They are then being stripped off the deb by pkgstriptranslations, and they end up in the langpack under /usr/share/locale-langpack/$LANG/LC_MESSAGES/oxide.mo (notice how oxide-qt.mo became oxide.mo).
There is something weird going on in the langpack machinery.

Mistery solved:

<dpm> oSoMoN, so what I've done is to change the translation domain in the source package in LP from "oxide" to "oxide-qt". If I remember correctly, this will make the translations to be exported as "oxide-qt" in the next language pack export. I'd suggest to check with pitti next time the langpacks are built
<oSoMoN> dpm, thanks! How come this domain is hardcoded, instead of extracting the domain name from the filenames installed by the package?
<dpm> oSoMoN, the first time a source package that contains translations is uploaded, LP asks for the template name (how it will be shown in the translations URL) and for the domain (filename to export as in the langpacks). IIRC, LP does a guess and sets domain = source package name, which admins can manually override. Perhaps the first upload the source package was named "oxide"?
<oSoMoN> dpm, in fact the mo files used to be named oxide.mo, but were renamed oxide-qt.mo at some point, so the initial setup made sense
<dpm> so that was probably it. The setup made sense initially, but then the domain in LP wasn't updated according to the change

So this should be fixed with the next langpack update.

This still won't work because there's another bug

http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/1129 should do it

Errr, forget that - that shouldn't affect this bug because it doesn't depend on Chromium localizations

I'm localizing GPS Navigation app and I found this problem:

I'd like to use the user language by default, but inside the webview the value of navigation.language is 'en' all the times. That variable should be the same as system, not always English.

Will this bug fix that too? Or should I open another bug? :)

Thanks in advance!

Inside the webview, you probably use something like navigator.language. This one got fixed a while ago, but may also be affected by the system language setting not being transmitted because of the same .mo filename problem.

navigator.language is unaffected by this bug.

@Chris: I tried the phone in Spanish & English. In both cases,
navigator.language = 'en'.
BQ Ubuntu 14.10 r22

Then, should I open another bug?

What version of Oxide is on there?

@Chris: I tried the phone in Spanish & English. In both cases,
navigator.language = 'en'.
BQ Ubuntu 14.10 r22

Then, should I open another bug?

phablet@ubuntu-phablet:~/.cache/upstart$ apt --installed list | grep oxide

WARNING: apt does not have a stable CLI interface yet. Use with caution in
scripts.

liboxideqt-qmlplugin/14.09,now 1.6.3-0ubuntu0.14.10.1~ppa1 armhf
[installed,automatic]
liboxideqtcore0/14.09,now 1.6.3-0ubuntu0.14.10.1~ppa1 armhf
[installed,automatic]
liboxideqtquick0/14.09,now 1.6.3-0ubuntu0.14.10.1~ppa1 armhf
[installed,automatic]
oxideqt-codecs-extra/14.09,now 1.6.3-0ubuntu0.14.10.1~ppa1 armhf
[installed]
phablet@ubuntu-phablet:~/.cache/upstart$

--
Sent using Dekko from my Ubuntu device

That's why it doesn't work - it was fixed in 1.7

Perfect then :) Thanks Chris!

This is now working in OTA-4 for my purposes (Tutanota shows its interface in the system language both as a webapp and in the standalone browser). So I am pleased!