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.

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).

What exactly does this has to do with Bugzilla?

> 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.

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.

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.

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.

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