Use a localized Accept-Language header

I don't understand the purpose of this. That's precisely what the $LANGUAGE environment variable is for, can't Oxide just use that? (and fall back to $LANG if not set, as usual)

In other words, it seems rather pointless to use gettext (which looks at $LANGUAGE and $LANG etc.) to get the very same list of languages. That just sounds like redundant (and potentially inconsistent) work to be done by translators.

Chris, Alex: can you comment on the choice of .mo files versus using the
language variable?

In all cases, Martin recommended to add a comment in special format to let
translators know about the role of the string.
/* TRANSLATORS: <explanation> */

On Mon, Sep 29, 2014 at 9:35 AM, Martin Pitt <email address hidden> wrote:

> In other words, it seems rather pointless to use gettext (which looks at
> $LANGUAGE and $LANG etc.) to get the very same list of languages. That
> just sounds like redundant (and potentially inconsistent) work to be
> done by translators.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1311229).
> https://bugs.launchpad.net/bugs/1224707
>
> Title:
> Use a localized Accept-Language header
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/oxide/+bug/1224707/+subscriptions
>

I wasn't aware of $LANGUAGE until now - it does seem to provide similar functionality.

Note that both Firefox and Chromium use translations for setting this, and we've copied the values set by their own translators. There seems to be quite some differences between these and the values set in $LANGUAGE. For example, the Accept-Language header for Lithuanian has Russian and Polish as fallbacks (in both Firefox and Chromium), but not in the $LANGUAGE environment variable. Also, whilst they all have some form of English as a fallback, some of them express a preferences for British English or American English where $LANGUAGE doesn't.

I'm not sure how much this matters...

I personally think it's fine to use translations, also because of the fact
that the format of language tags that Accept-Language uses can be different
from the format of $LANG and $LANGUAGE. E.g. ' zh-hant' can be specified
from the browser for Traditional Chinese, but from $LANG or $LANGUAGE only
'zh_TW' is allowed.

I agree that there should be a translator comment explaining the format, as
it's an important string, and if a translator gets it wrong, it will affect
the content that is delivered to users.

From my point of view, is whether we want to make this a default +
configuration option, so that the user can change their language
preferences. It's the traditional way in the desktop, but I'm not sure if
it applies to a phone browser.

Cheers,
David.

On Mon, Sep 29, 2014 at 11:04 AM, Chris Coulson <<email address hidden>
> wrote:

> I wasn't aware of $LANGUAGE until now - it does seem to provide similar
> functionality.
>
> Note that both Firefox and Chromium use translations for setting this,
> and we've copied the values set by their own translators. There seems to
> be quite some differences between these and the values set in $LANGUAGE.
> For example, the Accept-Language header for Lithuanian has Russian and
> Polish as fallbacks (in both Firefox and Chromium), but not in the
> $LANGUAGE environment variable. Also, whilst they all have some form of
> English as a fallback, some of them express a preferences for British
> English or American English where $LANGUAGE doesn't.
>
> I'm not sure how much this matters...
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1224707
>
> Title:
> Use a localized Accept-Language header
>
> Status in Oxide Webview:
> Fix Released
>
> Bug description:
> The Accept-Language header defaults to "en-us,en" if it hasn't been
> overridden by the embedder. But the default should be a string that's
> appropriate for the current locale
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/oxide/+bug/1224707/+subscriptions
>

The initial implementation actually used $LANG and as far as I remember $LANGUAGE, but after a discussion w/ Chris some uses cases came out like the one highlighted in his answer: basically it gives a tighter control over some of the values for which the direct value of $LANGUAGE might not be appropriate ...

@dpm the formatting "update" going from one world to the accept-language one, was actually taken care of by the code in the first version of the accept-language support

The initial implementation did use $LANG, but not $LANGUAGE

So, the translations mechanism provides a sane default which apparently $LANGUAGE cannot fully cover in a number of situations. It might be desirable to expose an API to allow overriding this default, such that the user could hand-pick her language preferences in the browser’s settings. This should be tracked as a separate bug though (please file one if you think it would be a useful addition).

We already have an API for that (WebContext.acceptLangs) :)

Oh, right. So I guess all that’s left to do is to make this setting configurable in the webbrowser’s settings page (which doesn’t exist yet).

@Chris: right!

Questions though about this: is this something that would be handy to have designs input on? There are a few unclear bits there, shoudl the setting be per-site or global etc, ... Apparently Chrome for Android does not allow that kind of thing,