I've got CVS write access for some time now because I'm supposed to checkin German L10n (see also bug 57878 Comment 19) - it hasn't happened yet because I'd need some directions to go from here. On August 8th, I mailed staff@mozilla.org about that, only blizzard answered me, saying "tao? Any complaints? Otherwise, I think we're just going to give Robert the go ahead. Speak now, as they say." Tao has never replied, I didn't hear a word from anyone else as well. What I'd need now is some advice on how the directory structure should look in CVS. As I'm a pioneer here and no other L10n pack (besides en-US) sits in our CVS tree until now, we have to construct something that can serve all the translations in the future. It would be nice if I could check in small things like a script that I'm using as a helper to build XPIs as well as the real L10n files (perhaps, uder the root L10n dir, have dirs for all the translations, under them split into a dir for L10n files, and a dir for tools/utilities/helpers/whatever). I think it would be nice to get that solved soon, as 1.2 would be a great point for starting this :)

It is a good idea to have build script/CVS to create the language pack. Let's have a detail plan to layout the idea. Some thought came of my mind: 1. The l10n pack should not be built by default. I think most of the developers don't need the packs. We should not take their build time for something they don't want. 2. The build script can take another variable which switchs on the l10n build and defines the target language. 3. Should we also restrict the l10n pack to the major milestone? Because it will be hard to keep in sync. with en-US files all the time. We can tag the l10n files to the milestone release to make sure they work for the release builds.

> 1. The l10n pack should not be built by default. Right. I'm not sure if it should even be checked out automatically (if not built) > 2. The build script can take another variable which switchs on the l10n build > and defines the target language. Sound good. > 3. Should we also restrict the l10n pack to the major milestone? Restricting wouldn't be good, I think because e.g. I'm able have them updated almost dialy :) Tagging is nice and good though, as most L10n people won't be able to deliver changes that frequently, and of course people building some milestone build do want to be able to check out the files that fit exactly for that build.

Something to build de in addition to en would be nice. Should we really use de-AT and not de-DE? I realize that Robert is Austrian and that de-AT is correct for him. If it's easy to change, I don't care, but I'd need to ship de-DE (and I assume most other distributors as well), and changing that proved to be a major hassle in the past, at least with the existing binaries. is there any plan to deal with that?

Ben: I've discussed that topic a lot in recent years, and I still believe that a generic "de" would fit our needs best. But that would confict with the names of content packs. As we con't go this way currently, I think it shouldn't matter a lot, not even for distributors, how the pack is called internally. If it's de-DE, de-AT, de-CH, or de-EU or anything, that all shouldn't matter as long as it's just an internal name (and it is). Just to think we have to call it de-DE, because some others use de-DE for generic German packs, is not the right we, IMHO. To do it for the reason that Germany is bigger than other German speaking countries, isn't right as well, IMHO - it's just a discrimination. To name it de-AT because most work for it is done in Austria (not only by me, btw), is a reason that counts for me. That's the reason I still have it named de-AT, and remember, it's just an internal name, nothing else.

rchen, tao: What's your word on this now? What rules should I obey for cheking it in (directory structure, any/which reviews needed)? It would be nice if I could start that project with the 1.2 release...

Ying had done some work on this front. CC him.

We had some language translation contribution from Netscape 7.0, you can check out it by: cvs co mozilla/l10n/nscp and the tagging is NSCP-L10N-1-0-1-RC1. We didn't check it into the trunk, we think other people may have different translation, if anybody want to contribute, they can check in their files like: mozilla/l10n/yourname Localizer can pick up any translation they like... In the trunk "mozilla/l10n/langpacks" directory, the files are too old, and only few languages there. We need to clean it up.

SeaMonkey trunk de has landed over time for testing purposes. The missing parts for bug 286110 are code restructuring issues that probably require re-translation of the new strings anyways, so in fact the issue here has been solved. Getting automated translated builds will be another issue that needs 286110 completely resolved before it can be attacked.