Closed Bug 654467 Opened 11 years ago Closed 3 years ago

Locale matchOS doesn't take into account variant information

Categories

(Core :: Internationalization, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: toniher, Assigned: smontagu)

References

(Blocks 1 open bug)

Details

(Whiteboard: [bcp47])

This comes after a bug in Ubuntu:
https://bugs.launchpad.net/ubuntu-translations/+bug/776301

As I can presume from bug 44070, if intl.locale.matchOS is set to true (http://kb.mozillazine.org/Intl.locale.matchOS), default in most Linux distros, but not from Mozilla side (bug 331779), only language and country subtags are considered.
Aside from more current BCP-47, Linux systems have been using for long time @variant for noting the variant, but also the script (http://www.gnu.org/software/hello/manual/gettext/Locale-Names.html).
Examples: sr_RS.UTF-8@latin o ca_ES.UTF-8@valencia

I wonder whether there could be a way that matchOS locale could handle this in order to avoid issues as listed above and, at the same time, discriminate from the proper interface locale (that should be BCP-47 compliant).

I found a similarly related thread in an OOo list: http://www.mail-archive.com/dev@openoffice.org/msg13739.html
This probably depends on bug 525494. Doesn't seem to be strictly relating to bug 356038, IMHO.
Depends on: 525494
(In reply to comment #1)
> This probably depends on bug 525494. Doesn't seem to be strictly relating to
> bug 356038, IMHO.

Given that BCP 47 does provide for the subtags of type 'variant' (of which 'valencia' is one), I'd say this does indeed relate to bug 356038. Adding dependency as such.
Depends on: bcp47
Whiteboard: [bcp47]
Blocks: bcp47
No longer depends on: bcp47

matchOS is gone, resolving WORKSFORME. Please reopen if the intl.locale.requested logic still has the same bug.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.