256188 - Land toolkit locales-in-CVS on the trunk

Status: RESOLVED DUPLICATE of bug 271324

(SeaMonkey :: Build Config, defect)

Description

[Benjamin Smedberg]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 2

[Benjamin Smedberg]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Benjamin Smedberg]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Brendan Eich [:brendan]]

> 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

Comment 7

[Benjamin Smedberg]

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

Comment 8

[Benjamin Smedberg]

Oops, I filed a duplicate with patches and such.

*** This bug has been marked as a duplicate of 271324 ***