For the aviary branch, I have coalesced all the localization files that are part of core gecko and the toolkit in toolkit/locales/(en-US). This has allowed other locales to be easily built from the tree using the --enable-ui-locales=ab-CD flag. It also allows automated building and comparison of locales. I now need to land this work on the trunk. Boris was concerned that I had not notified module owners of this change, and that this might be troublesome to some module owners. So I'm filing this bug, and cc'ing all the relevant module owners who might need to be notified. If you have concerns about the localization system I have designed, please let me know (either in the bug or by mail). Otherwise, please mark your r= for this change.

Why is this in toolkit? We already have an l10n directory. And if it is in toolkit, it seems odd to make people who just want the core pull all of toolkit (incl. toolkit/themes) rather than just toolkit/locales/.

Seamonkey already pulls all of toolkit, see bug 251566. The idea that we localize one product at a time, and the "toolkit" will become the xulrunner/libxul, and should be localized as such. To avoid forking these files for seamonkey, the seamonkey build references these files from their "canonical" location in toolkit/locales.

I have the following questions, which I raised at the same time as the "why not tell the module owners?" question and that never got answered: 1) How are reviews being handled for these files? Do DOM/layout/necko/etc localization files fall under "toolkit" review rules? If so, why? If not, how do we make it clear who's responsible for which file? 2) How is localization of gecko-based non-toolkit (and non-XUL, for that matter) products handled in the new world? 3) What's the story on JS engine localization in the new world? Also, I'm not sure it's clear to me how comment 2 addresses the "why is this using toolkit/ instead of l10n/?" question dbaron raised... Localization of Gecko proper is not exactly related to xulrunner (see question 2 in previous paragraph).

> 1) How are reviews being handled for these files? Do DOM/layout/necko/etc > localization files fall under "toolkit" review rules? If so, why? If not, > how do we make it clear who's responsible for which file? Can you suggest reasonable rules? How about "Changes to English localized files that are used only by a particular module can be reviewed by that module owner or a peer. Changes to files accessed across multiple modules need the approval of a toolkit peer." None of the localized strings I've seen across gecko, except for perhaps parts of PSM, are especially complicated or controversial. Changes to non-English files require approval only from the localization owner. > 2) How is localization of gecko-based non-toolkit (and non-XUL, for that > matter) products handled in the new world? It will be handled exactly the same as today, which involves building seamonkey and subtracting what you don't want. As libxul becomes more solid, most embedding apps (except for minimo) will move to use it. > 3) What's the story on JS engine localization in the new world? The JS engine is currently hard-coded in English in js.msg and I have no plans to change that at the present. If localizers complain, I will discuss the options with brendan. Obviously, since the JS engine is self-contained and cannot load URIs from the chrome registry, our standard l10n mechanism does not work. > using toolkit/ instead of l10n/?" question dbaron raised... Localization of > Gecko proper is not exactly related to xulrunner (see question 2 in previous > paragraph). libxul/xulrunner is the consolidated plan, and its home is toolkit/. "gecko proper" is not a localizable product in itself, and there is no need to invent new top-level directories (The old l10n toplevel dir never worked, because it was only non-English languages and had a different directory structure from the rest of the source tree.) If we try to split the l10n up even farther into "gecko", "toolkit", "app", or heaven forbid try to localize each module individually, you have immediately created a maintenance nightmare. Please take a look at the patch in bug 252941, and imagine that yet again, or even more. (And the SeamonkeyAll CVS module becomes useless).

> Can you suggest reasonable rules? It depends on what the goal is. Based on your comments, it sounds like checking with the module owner before making changes to localized strings for the module is not a design goal of the new system. Should it be? If so, then that needs to be the rule and it should be easy to figure out what module each file belongs to. If not, then are module owners OK with that, generally? > "gecko proper" is not a localizable product in itself I'm sorry, but why not, exactly? For that matter, why's Necko not a localizable product in itself? As I recall, one of the goals there is to have Necko be a reasonable standalone library, the way JS is. If there has been an executive decision that all Mozilla modules other than the JS engine must be available only as parts of xulrunner in a usable form, then I have a lot less of an issue with this change, I guess, and some very public announcements to that effect should happen so that embeddors, Minimo included, won't be surprised when the world suddenly breaks. If not, then it sounds to me like we're digging the "chrome registry being used to localize the world" hole deeper and deeper instead of filling it in (the latter is what hyatt has been advocating for forever, by the way).

> Obviously, since the JS engine is self-contained and cannot load URIs from the > chrome registry, our standard l10n mechanism does not work. The JS engine has an API with which you can configure and pass in callbacks, but alas it seems as thought the way the API was designed (not by me) precludes the core engine calling a per-context callback to get a JSErrorFormatString for a given errorNumber. This is a botch. It can be fixed (bug to be found or filed), and then the higher layer C++ code can configure a C callback that does whatever needs doing. There has been no executive decision to make everything depend on toolkit, or on chrome. There has been no executive decision against {js}, {nspr,js}, {nspr,js,xpcom,xpconnect}, {nspr,js,xpcom,xpconnect,necko+what-necko-needs}, etc. bundles that can be used in addition to libxul. There has been a plan to move toward a libxul/xulrunner pairing, where xulrunner work precedes libxul, libxul has minimal and frozen exports, and xulrunner linked with libxul runs as fast (or within epsilon) of current firefox static builds. This will take time, and we do not want to violate modularity at any point. I would go further, and agree with bz that modularity has a human face, which you might call subsidiarity. Individual module owners should care about l10n, and may well. It should not be necessary to put all modules' l10n info in one CVS subdirectory. It might help localizers to do that, but it cuts against module "home rule". (Long ago, someone argued we should locate all header file sources, or at least all public headers and IDL, under one mozilla/public or mozilla/idl subtree -- that has the same modularity problems, both for code subsetting and for human ownership. I nixed that proposal with only the proposer objecting.) This issue needs to be hashed out in a wider audience. There is probably a good technological fix that balances interests, or even gives module owners and l10n folks "best of both worlds" experiences. If at the end of that discussion we decide to consolidate l10n files, I think we should use mozilla/l10n, not mozilla/toolkit/locales. But we may find a better way. Where should we have the wider discussion? Benjamin, feel free to start it with a cross-posted news message with followup-to: set appropriately. /be

For the record, the newsgroup discussion is being carried out in npm.l10n: http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&group=netscape.public.mozilla.l10n&selm=415C96B7.7030306%40covad.net

Oops, I filed a duplicate with patches and such. *** This bug has been marked as a duplicate of 271324 ***