Oxide

Bug #1224707
Comment #5

Comment 5 for bug 1224707

Revision history for this message

David Planella (dpm) wrote on 2014-09-29: Re: [Bug 1224707] Re: Use a localized Accept-Language header

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
>

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.

Cheers,
David.

On Mon, Sep 29, 2014 at 11:04 AM, Chris Coulson <chris.coulson@canonical.com
> 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
>