102509 - en-win, en-mac, en-unix are really bad names

Status: RESOLVED FIXED

(Core :: Internationalization: Localization, defect, P3)

Description

[Mike Kaply [:mkaply]]

These names assume that the first two characters identify the language. This is 
incorrect.

Two notable exceptions are zh-TW and zh-CN. according the the en-platform 
concept, we would have zh-win, but we have to have a different zh-win for 
Chinese and Taiwanese.

This even breaks down with something as simple as en-US and en-GB. If the word 
color was in the platform stuff, you would need an en-GB-win and an en-US-win.

Why were these even split off at all?

why not just have a unix, mac, and win directory inside of the en-US.jar? This 
would make things much simpler, and also allow one platform to use some of the 
unix and win translation if necessary.

Comment 1

[Andreas Becker]

Switching qa contact to ruixu and CCing tao and mcarlson.

Comment 2

[Mike Kaply [:mkaply]]

Note you can't use the last two letters either.

de-DE (Germany), de-AT (Austria), de-CH (Switzerland) are all exactly the same 
German and should use the same de-platform file, but all have a different 
locale.

And I do understand why platform subdirs weren't created in xx-XX.jar. This is 
because the goal was to have one file like platformKeys.properties that is 
loaded from the current platform jar. So there is a need for platform jars for 
this purpose, they just need to be named differently, or we need to define an 
architecture that allows some loading of chrome files from different places in 
the jar based on platform.

Comment 3

[tao]

In theory, you're right about the naming. In reality, they shouln't prevent you 
from designating where the resource live. You should be able to register platform 
specific resources for zh-TW localization. Have you run into any problem in
doing so?

Comment 4

[Mike Kaply [:mkaply]]

My goal here to for someone to tell me the "right" thing to do so when I create 
my Traditional and simplified Chinese translations.

And I think we need to set this standard right now to prevent problems in the 
future.

Comment 5

[tao]

For Windows, you can localized en-win.jar into Traditional Chinese and name it
zh-TW-win.jar. You'd need to replace all occurance of "US" in the directory
structure, file name, and registry name with "zh-TW". Let me know if they do not 
work.

Comment 6

[timeless]

do the -'s really add value? why not enUSwin.jar/enUSlin.jar/enUSmac.jar (7.3<=8.3).

I know that these days one of the two codes can be 3 letters, but i don't see
any value in using the extra -'s. (engUSwin.jar anyone?)

Comment 7

[tao]

reassign to new owner ->dbragg

Comment 8

[tao]

new owner ->tao

Comment 9

[tao]

Hi, Bob: please reassign these i18n/l10n/l12y bugs accordingly. thx!

Comment 10

[Martijn Ras]

*** This bug has been marked as a duplicate of 180508 ***

Comment 11

[Constantine A. Murenin]

Bug #180508 does not address the same problem. This bug should be re-opened (and
fixed). 

Comment 12

[Asa Dotzler [:asa]]

not going to block the release for this request. reviewed and tested patches
would be considered during the freeze so please nominate for approval if a fix
becomes available.

Comment 13

[Constantine A. Murenin]

Attachment: rename en-(mac|unix|win) to en-US-(mac|unix|win) in App Suite

This patch was made by running:

find * -type f | xargs egrep -l 'en-mac|en-unix|en-win' > ../filelist

xargs perl -pi -e
's/en-mac/en-US-mac/g;s/en-unix/en-US-unix/g;s/en-win/en-US-win/g' <../filelist


cvs diff -udp8 <../filelist >../diff

Comment 14

[Constantine A. Murenin]

Attachment: Patch for langenus.jst for App Suite

This patch fixes langenus.jst of App Suite, which becomes
langenus.xpi/install.js.

Comment 15

[Constantine A. Murenin]

Attachment: Patch for langenus.jst for Browser and for Mail

This patch fixes langenus.jst of Mozilla Browser and Mozilla Mail, which
becomes
langenus.xpi/install.js.

Comment 16

[Constantine A. Murenin]

Attachment: rename en-(mac|unix|win) to en-US-(mac|unix|win) in Browser and Mail

This patch was made by running:

find browser/ mail/ -type f | xargs egrep -l 'en-mac|en-unix|en-win' >
../filelist.BrowserMail

xargs perl -pi -e
's/en-mac/en-US-mac/g;s/en-unix/en-US-unix/g;s/en-win/en-US-win/g' <
../filelist.BrowserMail

xargs cvs diff -udp8 < ../filelist.BrowserMail > ../diff.BrowserMail

Comment 17

[timeless]

const: please comment on comment 6.

Comment 18

[Constantine A. Murenin]

(In reply to comment #17)
> const: please comment on comment 6.

(In reply to comment #6)
> do the -'s really add value? why not enUSwin.jar/enUSlin.jar/enUSmac.jar
(7.3<=8.3).
> 
> I know that these days one of the two codes can be 3 letters, but i don't see
> any value in using the extra -'s. (engUSwin.jar anyone?)

We are over the time of 8.3. :-) 

By RFC 3066, the language code for American English is "en-US", not "enUS". Why
void the standards if they are easy to follow? 

Comment 19

[Constantine A. Murenin]

RFC 3066 suggests using hyphens to separate the fields of the language tag...
I.e. "en-GB-oed" is "English, Oxford English Dictionary spelling"
(<http://www.iana.org/assignments/lang-tags/en-GB-oed>). By this convention, we
have three different versions of the en-US language --- mac, unix, win, which is
rather odd. What about naming the packages as en-US.mac.jar, en-US.unix.jar,
en-US.win.jar? 

Comment 20

[Constantine A. Murenin]

Comment on attachment 143693 [details] [diff] [review]
rename en-(mac|unix|win) to en-US-(mac|unix|win) in Browser and Mail

Apparently, this patch contains a fix for "mail/base/content/hiddenWindow.xul",
which it should not (blame RegExp). Do not apply it to the mentioned file.

Comment 21

[Constantine A. Murenin]

Comment on attachment 143688 [details] [diff] [review]
rename en-(mac|unix|win) to en-US-(mac|unix|win) in App Suite

These patches need to be landed as soon as possible, if not sooner. :-)

I compiled everything on unix, and it worked fine. Please, could someone test
it with the installer? I was unable to create the installer on FreeBSD-4.8 with
gcc2.95.4 due to some other compile problems.

Comment 22

[Robert Kaiser]

Comment on attachment 143688 [details] [diff] [review]
rename en-(mac|unix|win) to en-US-(mac|unix|win) in App Suite

The patch looks good to me.  You should get r=bsmedberg though, IMO.
Be sure to drop Sunbird/Calendar people a note before this gets checked in, as
this patch affects their product as well.

Comment 23

[Robert Kaiser]

Comment on attachment 143689 [details] [diff] [review]
Patch for langenus.jst for App Suite

This patch looks quite nice... I think it should/must go in together with the
other one, it might break nightly builds to check in only one of them.
It's nice that it does some small and easy cleanup of that section in the files
as well :)

Comment 24

[Benjamin Smedberg]

Comment on attachment 143688 [details] [diff] [review]
rename en-(mac|unix|win) to en-US-(mac|unix|win) in App Suite

I don't think this is the way to go. We should not be renaming these just for
theoretical purity. Localizers are still free to localize en-win.jar using a
better filename scheme (I recommend en-GB-win.jar).

The real solution, and one that I can endorse, would be to merge all these
files into en-US.jar. In the meantime, the status quo is not a bug.

Comment 25

[Benjamin Smedberg]

Suggestion for merging en-win.jar into en-US.jar: we currently ship the
platform-localization files thus:

en-win.jar!/locale/en-US/communicator-platform/contents.rdf
en-mac.jar!/locale/en-US/communicator-platform/contents.rdf
en-unix.jar!/locale/en-US/communicator-platform/contents.rdf

We can ship these all in en-US.jar thus:

en-US.jar!/locale/en-US/communicator-platform-win/contents.rdf
en-US.jar!/locale/en-US/communicator-platform-mac/contents.rdf
en-US.jar!/locale/en-US/communicator-platform-unix/contents.rdf
or
en-US.jar!/locale/en-US/communicator-platform/win/contents.rdf
en-US.jar!/locale/en-US/communicator-platform/mac/contents.rdf
en-US.jar!/locale/en-US/communicator-platform/unix/contents.rdf

When we actually *install* the langpack, we should only register one of these
three directories, whichever one corresponds to the platform. This would require
a little bit of hackery to the install.js script, but that's really easy...
Constantine, if you muck with the jar.mn stuff, I can fix up the install.js scripts.

Comment 26

[David Fraser]

Re comment 25:
I think this is a much better way to go... it's annoying having all those little
jar files :-)

Comment 27

[Constantine A. Murenin]

(In reply to comment #25)
> Suggestion for merging en-win.jar into en-US.jar

Benjamin, I do not think it is a good idea to merge it into en-US.jar. There are
a few reasons why I think this way:

1. It will complicate the code in install.js and possibly other files. 
2. Files will have different locations on the disc and in the registry. 
3. It will void the idea of modularisation. See bug #230596 and bug #234261. 

mkaply did not suggested to get rid of platform jars, see his comment #2 --- we
do need platform jars. 

There is no reason for one platform wanting to use things of the other --- if
there is such a need, then those files are platform-independent and should go
into en-US.jar. 

The simplest, easiest and "right" solutions is to rename en-(mac|unix|win).jar
to en-US.(mac|unix|win).jar. And we do need to do this today --- this bug
already got into Firebird and Thunderbird; we must stop this monster today, or
it will eat us tomorrow. :-)

Comment 28

[Robert Kaiser]

I'm with Benjamin here.
As I already said in bug 180508, I don't think we need that
believe-to-be-modularisation at a file level, when we have the real
modularisation at a chrome registry level.
And I don't think that our install.js code would get more complicated, I believe
it could quite easily be the other way round...
The argument of file and registry locations doesn't really come through for me
as well, as we already have that in a few cases (more in content/ than in
locale/ or skin/ though), and it doesn't really make up problems.
btw, what mkaply said, was that we'd need them "for this purpose", and we won't
need them if we could deal with it in the chrome registry. And I believe that we
can already deal with that. If I come around to do it, I'll probably make a
prototype language pack that show that.

Comment 29

[Constantine A. Murenin]

Attachment: complete patch to rename en-(mac|unix|win) to en-US.(mac|unix|win) in the whole tree as of 2004-05-16

This is a complete patch for Mozilla App Suite, Browser, Mail as of 2004-05-16.
It does not violate RFC 3066 (see comment 19) and makes the naming to be RFC
3066 compliant.

Comment 30

[Constantine A. Murenin]

Attachment: complete patch to rename en-(mac|unix|win) to en-US.(mac|unix|win) in the whole tree as of 2004-06-08

Comment 31

[Robert Kaiser]

I've made up a test XPI pack with everything merged into one jar, like Benjamin
proposed in comment #25 - and it works perfectly!
The modularization is still there at the chrome registry level, as I said, but
the files are easier to handle.
I also even renamed the region pack to the same name as the locale and
integrated it into the jar, and even that does work, except of global-region -
but that's a different issue and blongs to the region pack topic.

If you want to see how it does work, I can put up that experimental 1.7rc2 "de"
(German) XPI pack  to some public place...

Comment 32

[David Fraser]

re comment 31: please make it available!
I am busy rewriting the xpi-handling code for translate.sourceforge.net and if
we can use this method it would be great...

Comment 33

[Robert Kaiser]

The XPI with the merged jar is up on
http://www.hirsch.sth.ac.at/~robert/mozilla-test/de-lang-merged-mozilla1.7rc2.xpi

(This is exactly the same as my official de-AT 1.7rc2 XPI pack but with the
merged jar - so it even includes German myspell directories, local searchplugins
etc.)

Comment 34

[Constantine A. Murenin]

(In reply to comment #33)
> The XPI with the merged jar is up on
> http://www.hirsch.sth.ac.at/~robert/mozilla-test/de-lang-merged-mozilla1.7rc2.xpi
> 
> (This is exactly the same as my official de-AT 1.7rc2 XPI pack but with the
> merged jar - so it even includes German myspell directories, local searchplugins
> etc.)

If you install it and uninstall all other language packs, will mozilla still
work? Could you try? I think, it ought not to work...

Comment 35

[Hung-Te Lin]

Agree with Benjamin (#25).

While the Mozilla core itself is still using platform jars,
Firefox, Thunderbird, and other extensions like Chatzilla are
already puttying more and more platform stuff into their global locale.
And currently we already have a complex install.js trying to
determine platform OS. It will not be more complex.

Another issue is that more Mozilla* installers are not putting all
platform resources into their package. So it's very difficult for
a localizer to get en-mac.jar if he has only a Windows Box.
You can see localizers asking "Who is kind enough to extract the
en-unix.jar and en-mac.jar and put them on web?" all the time.
A more bad news is that sometimes the platform jars are not synchronized.
That means, the en-unix.jar you fetched from a Windows version
is out-of-date in comparision to a UNIX version. It will only 
popup a XUL error window for you.

And new Firefox/Thunderbird Extension uses new "install.rdf" instead of
install.js. So we can't do platform selection anymore with it.

Keeping a real centralized jar seems like a solution to all these
problems.

Region resouce US.jar has same issue. Thunderbird is merging US.jar and 
en-US.jar into en-US-mail.jar. 

Comment 36

[Robert Kaiser]

bug 328317 has merged platform files into en-US.jar and removed en-<platform>.jar packages, which means that this bug is fixed now for SeaMonkey as well.