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

RESOLVED WONTFIX

Status

()

--
enhancement
RESOLVED WONTFIX
14 years ago
10 years ago

People

(Reporter: burnus, Assigned: burnus)

Tracking

Details

(Assignee)

Description

14 years ago
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.
(Assignee)

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/
(Assignee)

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

Updated

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.
Status: NEW → RESOLVED
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.