258246 - Accept language header: 'en-gb' and matching of templates/en/

Status: RESOLVED WONTFIX

Description

[Tobias Burnus]

Current behaviour:

HTTP ACCEPT LANGUAGES: en
matches templates/{en,en-gb,en-us,en-gb-cockney}/

HTTP ACCEPT LANGUAGES: en-gb
only matches templates/{en-gb,en-gb-cockney}

This is according to the specs:
        # Per RFC 1766 and RFC 2616 any language tag matches also its
        # primary tag. That is 'en' (accept language)  matches 'en-us',
        # 'en-uk' etc. but not the otherway round. (This is unfortunally
        # not very clearly stated in those RFC; see comment just over 14.5
        # in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4)

And makes sense, but it is not very intuitive.
Being in Germany I'd set 'de-de' in the browser. The w3c's comment suggest that
the browser then ask to add/automatically adds 'de' as well. But for instance
Mozilla doesn't do this.

The question is: Should we change the behaviour of Bugzilla? That is
'en-gb' should match 'en' (and (?) 'en-*'?). Should this be optional? Or what is
the right (TM) way to proceed?
I currently recommend:
ln -s de de-at
ln -s de de-be
ln -s de de-ch
ln -s de de-de
ln -s de de-lu
and "languages = de-at,de-be,de-ch,de-de,de-lu,en", defaultlanguage=en
But this is quite cumbersom.

Comment 1

[Tobias Burnus]

One comment I found:
Bugzilla should use a kind of cascade for the translation, i.e. for
accept-language=en-gb-cockney try to find the template 'en-gb-cockney' first,
then fall back to 'en-gb' and then to 'en' (and then, since we add it always, to
the defaultlanguage).

Comment 2

[Anne (:annevk)]

What exactly does this has to do with Bugzilla?

Comment 3

[Tobias Burnus]

> What exactly does this has to do with Bugzilla?

Bugzilla does supports the automatical selection of the language of the template
based on the HTTP ACCEPT LANGUAGE Header. (Selects
templetes/$language/{default,custom}/.)

This bug regards whether the language selection matches should be changed or
not, since many browsers send e.g. "en-us" when the user actually means "en,
en-us". (Mozilla also leads to this wrong assumtion.) While the current
implementation is correct, the question is whether we should anticipate that
most browsers have this problem.

Comment 4

[Marc Schumann [:Wurblzap]]

We should not change Bugzilla's behaviour, because it conforms to the spec as stated in comment 0. Proposing WONTFIX or WORKSFORME, or even INVALID.

Comment 5

[Frédéric Buclin]

I agree, en-* should fall back to en if en-* cannot be found, same for other languages. Some web browsers have fr-FR only (or de-DE, etc...). Bugzilla should be clever enough to handle this.

Comment 6

[Marc Schumann [:Wurblzap]]

While I don't have a sensible use-case in hand for this, the idea of the spec is that you can have your client specify something like "fr-CH, en-GB, en, fr", and the server serves en if there is fr and en installed. It must not serve fr in this case.

We shouldn't dump Bugzilla's history of conforming to standards.

Comment 7

[Frédéric Buclin]

(In reply to comment #6)
> We shouldn't dump Bugzilla's history of conforming to standards.

ok, ok. WONTFIX then.