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




14 years ago
10 years ago


(Reporter: burnus, Assigned: burnus)





14 years ago
Current behaviour:

matches templates/{en,en-gb,en-us,en-gb-cockney}/

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

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

14 years ago
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

14 years ago
What exactly does this has to do with Bugzilla?
Severity: normal → enhancement
Summary: RFC: Accept language header: 'en-gb' and matching of templates/en/ → Accept language header: 'en-gb' and matching of templates/en/

Comment 3

14 years ago
> 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

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.
Severity: enhancement → normal


12 years ago
QA Contact: mattyt-bugzilla → default-qa
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

11 years ago
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.
Severity: normal → enhancement
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 4.0
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

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

ok, ok. WONTFIX then.
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
Target Milestone: Bugzilla 4.0 → ---
Duplicate of this bug: 474762
You need to log in before you can comment on or make changes to this bug.