Closed Bug 57878 Opened 24 years ago Closed 20 years ago

Translations should be in CVS

Categories

(mozilla.org :: Miscellaneous, task, P3)

Product:
mozilla.org
Component:
Miscellaneous
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: axel, Unassigned)

References

Details

Hi, as a little post processing of the european mozilla conference: The translations should be in CVS. They should probably not be part of SeaMonkey, but go into their own module. Please comment, structure?, organisation? Axel
Reassigning to Dawn
Assignee: mitchell → endico
Here is the current langpack (translation) directory structure in Mozilla: http://lxr.mozilla.org/seamonkey/source/l10n/langpacks/ It uses the same build script as the Seamonkey build. Note that chrome directory structure has undergone a few evolution since this directory first created. We probably need to bring them up-to-date.
I guess the next question is, what are the requirements for getting a language pack checked in to the tree?
langpacks seem to be sensitive to being synced up with certain files. So we need some way for whoever checks them out to know which builds it works with. Maybe we need to check-in for a give M-build and tag it accordingly?
Some points to discuss, IMHO: 1) the langpacks should go into CVS to make translating easier. Translations shouldn't stay single person efforts for the rest of our lifes, and cvs is just the tool to coordinate the work of several contributors. 2) only very few people will need more than one or two localisations. Looks like SeaMonkeyL10N should go out of SeaMonkeyAll, or client.mk should check out SeaMonkeyEditor instead of SeaMonkeyAll. And we should add some magic to check out parts of SeaMonkeyL10N, something similar to extensions (added leaf and cls for this). This should support checkout, more like the BUILD_MODULES 3) Tagging releases is good, but should we introduce some supporting tools for tracking "regressions" from SeaMonkeyEditor to SeaMonkeyL10N? Some addition to bonsai? Or is the mozillaTranslator handling this ok? Is that tool enough? (added lynggaard) 4) Both the en-GB and en-DE dirs are outdated, no jar.mn, no contents.rdf Axel
Axel, an addition to 4): Only having no .jar or contents.rdf doesn't say it's outdated. My current de-AT packages still use "old" structure (manifest.rdf and locales/<name>/ directory with extracted files in it), and that packages are _not_ outdated. That's still a valid structure and can still be used... BTW, en-DE (dunno about en-GB) only changes default profile content and no locale content, so it doesn't need .jar or contents.rdf files anyway...
addition to Alex's point 3: This is from IRC #mozilla: <Pike> KaiRo: tagging is only for release, I want to get stuff into cvs to work on ;-). So I was thinking about something that would say, this .dtd changed since you changed the translation. I recall the mozillatranslator does that, right? [KaiRo] Pike: yep. MT compares current (original) strings with original strings stored in its glossary, and if that has changed, it shows you that one to edit - so that's a very good way to do it
One feature I would like to see, is Mozilla using the English strings if no localized strings are available. Currently, even if just a single string is added in the English files, a whole dialog may disappear if the langpack was designed for yesterday's build (or the last milestone). I have also noticed that localizable packages which aren't available in all languages, *tries* to use the non-existant language pack chosen in the profile. Example: I installed Aphrodite and use the Norwegian Nynorsk (nn-NO) locale. I see *no* text at all in Aphrodite, since it tries to uses Norwegian strings (which aren't available). If Mozilla could use English strings in localized ones weren't available, this would be very useful
> Some points to discuss, IMHO: > 1) the langpacks should go into CVS to make translating easier. Translations > shouldn't stay single person efforts for the rest of our lifes, and cvs is > just the tool to coordinate the work of several contributors. yes, >2) only very few people will need more than one or two localisations. Looks >like SeaMonkeyL10N should go out of SeaMonkeyAll, or client.mk should check out >SeaMonkeyEditor instead of SeaMonkeyAll. And we should add some magic to check >out parts of SeaMonkeyL10N, something similar to extensions (added leaf and cls >for this). This should support checkout, more like the BUILD_MODULES The first time I checked langpacks into Mozilla, I made some changes to the makefiles so we can selectively build/install langpacks in the daily build process. However, the second it breaks the release build due to some discrepency between development build and release build. (don't remmeber if it is mozilla or commercial build...) I can resurect those code if we can iron out the release build script problem.
Adding granrose for info on release build, he's doing the script, IIRC. Should we spawn another bug for build issues? Seems to be a separate bug. How about the cvs modules? If we get more data in mozilla/l10n, should every- body be annoyed by hebrew and catalan? So move SeaMonkeyL10N out of the default checkout target? Axel
Blocks: 60743
*** Bug 60748 has been marked as a duplicate of this bug. ***
Hmm, this issue doesn't seems to get easy... I looked at the documents about Mozilla CVS accounts, esp. http://www.mozilla.org/hacking/getting-cvs-write-access.html I think there is currently not a single L10n contributor who would be able to get cvs access by that creteria. But that creteria don't fit for checking into L10n tree, I think. L10n is not part of the standard build process currently (see other comments), and doesn't include any C++, .js or similar code but only those files in language packs (mainly .dtd, .properties, also some .rdf and .html files), so we don't need to know XPCOM or XPIDL... (if we're only checking into L10n tree) From those documents I also see that anyways we need to get super-reviers to help us, and shaver is the only one cced here (and he didn't comment on the bug so far). As http://www.mozilla.org/hacking/reviewers.html says that erik@netscape.com is responsible reviewer for L10n, I'll cc him here. erik, we need input from someone who can decide! what's your opinion to this bug?
This opens another question I forgot: How about reviews? Right now, l10ns seem to be mostly 1-man-tasks, and it seems to work well. Do we need 2 reviews (r=, sr=) to update l10ns, if some xul change broke them horribly, or to change a spelling error or to use a better word or...?
I agree with "Additional Comments From Robert Kaiser 2000-11-20 10:26". L10N should be treated differently from checking in code as long as the only files being altered are in the localizable locale files. erik is the wrong person for super-reviewing. tao is probably the best person for localization super-reviewing because he know this stuff inside-and-out.
I tend to agree that checkins to l10n directories should not be restricted to the same set of rules followed by core checkins. Dawn: Who do we contact to make an exceptions for checkins under mozilla/l10n ?
I agree with Bob that I am not the right person to super-review L10N changes. Is Tao the right person? Brendan, should we add Tao to the list?
You're right. mozilla.org staff agrees that the super-review requirements don't make sense for all areas of the CVS repository, including localized content. I've just about finishing revising the relevant docs (Getting CVS Access, Mozilla Code Reviewers) to fix this. Super-reviewer approval won't be required for CVS access to check in localized content; and we'll ask everyone to respect this scope and not check in code to other parts of the tree where super-review is required. I'm hoping to have the new versions posted in a small number of days.
I've asked for cvs access now in bug 134496 - I hope we'll get the first localisation into CVS soon!
OK, I got CVS access now. What are mozilla.org directions on that? I want to get German L10n work in, don't want to do any checkins that don't accomodate mozilla.org decisions though - and it doesn't have to be a matter of days (as I have little time currently anyway)... Would be nice to know what the structure should be, and how I should proceed.
Depends on: 179949
2 years have passed since the last activity here, has anything happened with this?
In the staff meeting on 2003-12-08, mozilla.org staff agreed on this to happen - http://groups.google.com/groups?as_umsgid=3FDB8346.9010004@mozilla.org - "Agreed: translations need to be in CVS; too separated from release process". I'm now thinking of how to structure the data, so that we can get this in motion. Localizations go into the /mozilla/l10n/ directory in CVS, under that, we need some agreed structure (below is a proposal that seems reasonable to me currently, but I'm not completely sure yet if it's best in all the details). I. What data do we want to get in? 1. content of locale chrome (gets packed into .jar files), including platform-specific and region (content pack) locale chrome 2. localized default files (profile, messenger) 3. localized installer files (.ini for win32, .spec for rpm, install.js for XPI file, etc.) 4. probably some scripts that do creation of various packages 5. additional resources that might go into an XPI package: a) used MySpell dictionaries for affected language(s) (do we want that?) b) locale-specific search engines (do we want them here?) 6. Somehow we want to be able to fit different products (Seamonkey, Firefox, Thunderbird, etc.) into the structure (currently unsure how) II. How to structure that data into directories, so that it's visible for someone else where to find what (s)he wants to have? This is my current proposal (placeholders are in <> brackets, the legend for those is at the bottom, directory names end in slashes): /mozilla/l10n/ README (top-level README explains structure) <project>/ README (project-level README - contributors etc.) chrome/ (all chrome files) <pack-code>/ locale/<loc-code>/<chrome-pack>/*.dtd|properties defaults/ (localized defaults, use region code) <loc-code>/<chrome-pack>/* install/ (files need for installers) install.js *.ini etc... scripts/ (resources/ ?) (any helpful scripts, etc.) make-xpi-package do-a-new-rpm-for-me make-windows-installer.bat <project> is a L10n project name/code, e.g. "de" for German project, "en-GB" for British/UK project <pack-code> identifies a .jar package for chrome L10n content, i.e. "lang" for a language pack, "lang-unix|mac|win" for platform packs, "region" for region/content packs. The structure below is 1:1 the structure of the files inside the .jar <loc-code> is a locale code used in chrome, e.g. "de-AT", "en-GB", or "DE", "GB" (for region content) <chrome-pack> is a chrome package name, e.g. "browser", "global", "communicator-platform", "nevigator-region", etc. Unresolved issues in the current proposal: A) Where to put additional files (of point I. 5.) B) What to do about different products (point I. 6.) - some (e.g. Sunbird<->Calendar, Seamonkey<->Fx/TB, Inspector?) may even share files with other products, making things even more complicated...
why do we need both a <project> and a <loc-code>? aren't they the same? and on a seperate issue: why is this bug depending on bug 179949? shouldn't it be the other way around?
(In reply to comment #22) > why do we need both a <project> and a <loc-code>? aren't they the same? e.g. for my German project, I'd have "de" as <project> (or might we even decide to write a full name, e.g. "german"?), but <loc-code> could be "de-AT" or "AT", depending if it's locale or region pack. (well, I'd want to move them both to use "de", but that's a different bug - I only want to use the status quo in this bug, not eventual fututre directions) > and on a seperate issue: why is this bug depending on bug 179949? shouldn't it > be the other way around? Well, it could be both ways. Getting German into CVS is one step of getting translations into CVS. OTOH, here we're laying the ground work that's needed to get German into CVS. Bug 179949 has a clear target when it can be resolved, this one actually hasn't. Following the topic, it can only be resolved when "translations" are in CVS (whatever goal that is) - and that's why 179949 is blocking it; following what I think now, is that we can resolve it when the structure is clear, a README describing the structure is checked in, and at least one project that follows that (and if I'm driving the effort, the German project will be among the first).
is this what the new /l10n $CVSROOT is for?
(In reply to comment #24) > is this what the new /l10n $CVSROOT is for? For the tookit apps, yes. There is no concept for SeaMonkey still, and it's not too likely that we will get one. That is, without porting SeaMonkey to toolkit. Which is a target for some, so this is not yet WONTFIX.
Depends on: 286110
endico is no longer around. I'm not aware of anyone working on this.
Assignee: endico → nobody
QA Contact: mitchell
(In reply to comment #26) > I'm not aware of anyone working on this. I am. But probably this bug should move to Core/L10n or Seamonkey. Actually, the issue is resolved for Firefox (We have localizations in CVS there), and it will be resolved for Thunderbird when work on bug 286108 is done. For Seamonkey, it may take a bit longer, but when bug 286110 gets done (and either gandalf or I will work on it), we will be able to get those translations into CVS as well.
Resolve this bug, we have app-specific bugs to track this now.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Hell, this always was about SeaMonkey, and it doesn't "work for me" until at least one SeaMonkey localization _is_ in CVS. I'll leave this bug to the dead though and go back to real work, even if the dependencies here are still open and more pressing than they ever were for me.
You need to log in before you can comment on or make changes to this bug.