Closed
Bug 258246
Opened 21 years ago
Closed 17 years ago
Accept language header: 'en-gb' and matching of templates/en/
Categories
(Bugzilla :: Bugzilla-General, enhancement)
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.
Assignee | ||
Comment 1•21 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•20 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•20 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•19 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Comment 4•17 years ago
|
||
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•17 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
Comment 6•17 years ago
|
||
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•17 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
Closed: 17 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.
Description
•