418485 - "ja-jp-mac" is not a valid language code. Please stop using it.

Status: RESOLVED WONTFIX

(Mozilla Localizations :: ja / Japanese, defect)

Description

[Nicholas Shanks]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE) AppleWebKit/523.15 (KHTML, like Gecko) Version/3.0 Safari/523.15
Build Identifier: 

The language code for japanese firefox visitors using a Mac, as reported by Google Analytics, is "ja-jp-mac". This is not a valid language code. I don't know if it's coming from the HTTP Acxcept-Language header or from JavaScript, but in either case you should not be using the -mac sufix at all. Indeed, since the country code of Japan is quite redundant for the Japanese language, I suggest reducing this to simply "ja".

Reproducible: Didn't try

Steps to Reproduce:
1. Create a website and ad Google Analytics code to it.
2. Access that web site from Mac Firefox Japanese
3. Look at the google analytics stats.


Expected Results:  
Use "ja" (or at worst, "ja-jp") instead.

Comment 1

[Jo Hermans]

They probably got it from the User-agent, not from Accept-Languages, because "ja-JP-mac" is not a language code, but the code used to indicate a Japanese language version for the Mac (other OS'es use "ja"). I don't know why though, maybe for legacy reasons ?

http://gemal.dk/browserspy/basic.html
http://gemal.dk/browserspy/accept.php

Comment 2

[Phil Ringnalda (:philor)]

Without having given it much thought, it does seem like just hard-coding "ja" in http://mxr.mozilla.org/l10n/source/ja-JP-mac/browser/firefox-l10n.js#39 would be reasonable.

Comment 3

[Marek Stępień [:marcoos, inactive]]

1. The format <language>-<region>-<dialect> is perfectly valid, as defined in RFC 3066. The dialect part is a free 3 to 8 characters string.
See also http://wiki.mozilla.org/L10n:Simple_locale_names

2. The RFC requires <region> to be specified, when <dialect> is. You can't have "ja-mac" or "ja--mac".

3. Japanese/Mac is a different localization than ja (Win/Linux), as Japanese terminology on the Mac is (or, at least is said to be) completely different from the Windows/Linux one.

4. Accept-languages for a locale are defined in intl.properties. For ja-JP-mac this is http://lxr.mozilla.org/l10n/source/ja-JP-mac/toolkit/chrome/global/intl.properties#24 :

intl.accept_languages                   = ja, en-us, en

To sum up, this bug is simply invalid, unless somehow "ja-JP-mac" appears in accept_languages (which I don't think it does).

Comment 4

[Jo Hermans]

So, the only problem is that Google Analytics is looking at the user agent (which reflects the UI that the user is seeing), and not the Accept-Languages (which is what the user is expecting to see in the content) ?

Comment 5

[Axel Hecht [:Pike]]

The problem is merely that navigator.language is a locale code, and not a language code. window.navigator.language is not defined in HTML5, even, so it's pure unspec'ed DOM0 foo, sadly.

I don't know why Nicholas thinks that ja-JP-mac is a problem in the first place, too.

Resolving INVALID, as per comment 3. One could reopen this if "mac" was an illegal dialect specifier, at which point we'd have to figure out if we care. Whether mac-computerspeak in Japanese is a dialect or whatnot is probably a lengthy discussion between various scientific areas, not just linguists.

At which point, I'd be tempted to resolve it WORKSFORME. ;-)

Comment 6

[Nicholas Shanks]

Axel, you can't claim this is invalid based on comment 3 as that commenter is incorrect in his assertions.
I don't know where he gets his imformation from when he says "The dialect part is a free 3 to 8 characters string." as the language variant is EITHER a 5 to 8 alpha string, OR a number followed by three alphanums (minimum four). All variants have to be registered via the IETF LTRU. The only exception is "en-GB-oed" which was registered before the rules were defined.

However "mac" is neither five to eight characters long, nor registered, and such is invalid twice over. Registration would not be accepted because a distinction between using windows or macintosh or linux has no relavance to spoken or written japanese!

The BNF for the locale codes based on ISO 639 and 3166, and RFC 3066, can be found here:
http://www.ietf.org/rfc/rfc4646.txt (section 2.1) or see
ftp://ftp.isi.edu/in-notes/bcp/bcp47.txt

As such I request that the bug be reconsidered and fixed. There should be no difference in locale code between platforms, even if the words used don't match.

In my original post I used "language code" because I wasn't sure the japanese maintainer would be aware of what a 4646 'locale' was (based on the fact that the existing one flouted all the rules).

Comment 7

[Axel Hecht [:Pike]]

As you didn't really say which spec was violated, and which part of it should have been, there wasn't really anything to check against.

I've been reading the rfcs quite a few times now, and never got all of each.

Anyway, we've been using ja-JP-mac for quite some time now, and haven't really learned about any real life issues with it. That might have been due to misreading the original spec, not sure if so.

Given the current state of Firefox 3, we'd need to learn about a real stop-ship problem with ja-JP-mac in order to change it.

ja-x-mac or ja-JP-x-mac might have been a better pick back in the days, and might be for a future gecko release, but it's not going to make it in gecko 1.9 just for conformance reasons.

Comment 8

[Nicholas Shanks]

Can this be reconsidered for Firefox 3.5 now?
The main problem for me is that is needlessly divides Japanese into two groups when using third party software which the author doesn't update, and therefore I am forced to write a first-party log analyser, a laborious process. I now have another year's worth of bad data, and it will continue to accumulate until this matter is fixed.

You say that you "haven't really learned about any real life issues with it", but I would suggest that's because people don't know about it, have sucked their teeth and just lived with it, or have worked around the bug without telling you anything. (c.f. Netscape & Microsoft incompatibilities a decade ago.)

So far we have:
1 person who wants it changed (YES votes)
0 people who want it kept in the current illegal form (NO votes), and
6.8 million people who don't care either way (ABSTAIN)

Do I need a two thirds majority?

Comment 9

[Matthew N. [:MattN]]

Bug 55366 changed navigator.language for mozilla5 to use the first accept-language entry rather than the UI locale so ja-JP-mac is no longer exposed to web content from what I can tell.