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

Bug #1464159 reported by Nathan Haines on 2015-06-11
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Oxide
High
Chris Coulson
oxide-qt (Ubuntu)
High
Unassigned

Bug Description

When the user has selected a specific system language for the phone,
the Accept-Language HTTP header field should be set to that language.

Currently, Accept-Language is hardcoded to "en-us;en;q=0.8".

To test:

1. [In the phone] Go to System → Language and Text → System Language
Select something other than "English (United States)".

2. To check the Accept-Language value, visit a website like http://myhttp.info

WHAT HAPPENS NOW:
Currently, Accept-Language is hardcoded to "en-us;en;q=0.8".

WHAT SHOULD HAPPEN:
The Accept-Language HTTP field should reference the system language (for example, for Greek, it should say something like "el;en-us;en;q=0.8".

---
I created a webapp for the secure email service Tutanota. One nice feature is that it is localized in several different lanaguages and it automatically presents its interface in the user's preferred language.

Unfortunately, the Ubuntu browser does not present the Accept-Language header and Tutanota does not offer language as a settings option.

I think it would be optimal if the browser uses the system language as the Accept-Language header (and would be awesome if it used the active keyboard layout options to create a list of additional languages), and of course even better if the browser settings page also allowed customization as well.

More information on this header is available here:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4

summary: - Ubuntu Browser doesn't present system language to websites.
+ Ubuntu Browser should send the system language to websites
summary: - Ubuntu Browser should send the system language to websites
+ Web browser should send the system language to websites (Accept-Language
+ field)
tags: added: i18n
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
Olivier Tilloy (osomon) wrote :

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.

affects: webbrowser-app (Ubuntu) → oxide-qt (Ubuntu)
Changed in oxide-qt (Ubuntu):
importance: Undecided → High
Olivier Tilloy (osomon) wrote :

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.

Olivier Tilloy (osomon) wrote :

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.

Changed in oxide-qt (Ubuntu):
status: Confirmed → In Progress
status: In Progress → Fix Committed
Chris Coulson (chrisccoulson) wrote :

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

Changed in oxide:
assignee: nobody → Chris Coulson (chrisccoulson)
importance: Undecided → High
milestone: none → branch-1.9
status: New → In Progress
status: In Progress → Fix Released
Chris Coulson (chrisccoulson) wrote :

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

costales (costales) wrote :

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!

David Barth (dbarth) wrote :

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.

Chris Coulson (chrisccoulson) wrote :

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?

Chris Coulson (chrisccoulson) wrote :

What version of Oxide is on there?

costales (costales) wrote :

@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

Chris Coulson (chrisccoulson) wrote :

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

Nathan Haines (nhaines) wrote :

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!

Olivier Tilloy (osomon) on 2015-06-16
Changed in oxide-qt (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers