179949 - Get German/de-AT translation into CVS

Status: RESOLVED FIXED

(Core :: Internationalization: Localization, defect)

Description

[Robert Kaiser]

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 [e-mail] 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 :)

Comment 1

[rchen]

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.  

Comment 2

[Robert Kaiser]

> 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.

Comment 3

[Ben Bucksch (:BenB)]

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?

Comment 4

[Robert Kaiser]

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.

Comment 5

[Robert Kaiser]

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...

Comment 6

[tao]

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

Comment 7

[Ying-Lin Xia]

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.

Comment 8

[Robert Kaiser]

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.