Talk:Create a new localization

From MDC

This page misses out on the community building aspect of a new locale.

We should somehow make clear that we expect a community to form, just because Firefox is popular pretty much anywhere, and if the folks interested in contributing a localization already have an idea on how to organize and support that community, that'd be a interesting data for us to know about.

Also, we should be aware of ways that we can help, though that is hard, given that we don't really want to be sucked into hosting forums, due to legal problems coming from that. And I at least think that forums are somewhat central. We could offer a mozilla.dev.l10n.AB_CD newsgroup (with google groups peer), though, I guess.

--AxelHecht 16:16, 9 February 2007 (PST)

The "Bootstrapping a new localization" assumes... well, something, but I'm not sure what. Certainly, if I followed those instructions, I'd fail with

>MOZ_CO_PROJECT=browser make -f client.mk l10n-checkout
'MOZ_CO_PROJECT' is not recognized as an internal or external command,
operable program or batch file.

Is this a Unix-vs-Windows thing, or do we need a pointer to "getting a build environment", or both (or something else)?

--MarkTyndall 02:16, 14 March 2007 (PDT)

Some queries:

• Para 1: Does "this" at the very end refer to the Firefox process or the Seamonkey process?
• "Bootstrapping a localization for review": I don't quite understand the last sentence of the first paragraph, about LOCALES_ in client.mk. Can this be expanded?

Gerv 13:21, 14 March 2007 (PDT)

More questions and hints about possible typos:

• In "Bootstrapping a localization for review", I agree with Mark Tyndall that it should be made clear if those instructions are only useful for Unix-based environments (which I think they are). Also, I remember having read recently something regarding build process dropping support for Cygwin for Windows; it would be nice if someone could point to Windows equivalents to what we have here.
• Regarding the targets, I know this is probably outside the MLP competencies, but making that "browser" and "mail" targets checkout just browser and mail, leaving toolkit aside, has more sense to me. It is not so unusual that teams divide the work, and when that happens is likely that either browser or mail people don't actually need toolkit content. It even could happen that one person is caring about everything but s/he wants to work module by module, and there is no way to just update browser and mail changes. Another possibility would be provide "browser-only" and "mail-only" targets.
• Just under the .mozconfig file creation instructions, it is not clear to me that the document is actually telling the reader to create a l10n/ab-CD/ directory structure; it looks more as an overview of what will be eventually created if the reader follow instructions ahead in the documents.
• The above is even more amusing as you type the next code sample, "make -f tools/l10n/l10n.mk check-l10n", which will report an extensive list of errors, since l10n/ab-CD/ doesn't exist yet.
• Just above that sample, I think there is a typo: where it says "The simplest tool is the makefile l10n.mk that we already mentioned above. It offers two targets, check-l10n and create-%" I think it should end with "...and create-ab-CD". Also, it should be emphasized that "ab-CD" needs to be replaced by the actual locale code. It is easy to think that such replacement wouldn't be needed as .mozconfig has the actual value.
• Below the create-ab-CD sample, there is a paragraph ending in "...That is, you'll have all the strings, but untranslated, so you'll need to do the progress checking yourself." I suggest adding something like "Some L10n tools may help you with this issue". MozillaTranslator can do it, and I guess that TranslateToolkit (well, PO-based tools, to be precise) also do it.
• In the paragraph "To keep up with the changes in the Mozilla codebase, run the l10n-checkout target regularly, and check the notifications about updates to see which files have changed." I would add a suggestion to previously run something like "cvs -z3 diff -u | less" or so.
• At the bottom of the document, the rule "Do not change the names in the files brand.dtd and brand.properties."; are you sure absolutely no locale has had the need to change it. Maybe it should be end with "...without filing a bug for approval telling really good reasong why it should be done". Also, since the rules come after a "You should:", shouldn't this second rule start just like "Not change the names..."?

--RickieesES 14:54, 23 March 2007 (PDT)