Closed Bug 258246 Opened 20 years ago Closed 16 years ago

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

Categories

(Bugzilla :: Bugzilla-General, enhancement)

2.18
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: burnus, Assigned: burnus)

References

Details

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?
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/
> 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.
Severity: enhancement → normal
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.
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.
(In reply to comment #6)
> We shouldn't dump Bugzilla's history of conforming to standards.

ok, ok. WONTFIX then.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Target Milestone: Bugzilla 4.0 → ---
You need to log in before you can comment on or make changes to this bug.