As always, there are some more or less big problems in current Mozilla L10n:
- Hardcoded content: Some projects still have hardcoded un-localizable code in their UI files,
e.g. Calendar and ChatZilla - but also Browser and MailNews have a bunch of those left.
A big part of this is low-hanging fruit for contributors and blocks L10n severily sometimes.
All relevant bugs (should) have the "L12y" keyword set.
Query for All bugs with L12y keyword set
(44 bugs found as of Fri Feb 7 06:30:17 PST 2003).
- Ignorance: Many US programmers think "It works for me and my collegues, and so it's alright" -
and they forget about i18n issues or things like locale switching altogether.
I had to fix breakage of the pref panel four times from 2002-03-31 to 2002-08-26 -
the FastLoad workaround (see below) is the fith issue that broke it during that time span!
See CVS Log of the pref panel.
- Content packs: Content packs (a.k.a. "region" packs) were a somehow interesting idea, but they
aren't used by anyone. 99.999999% of our users only use one language pack and one content pack together.
They should get re-merged into one pack again, the files should stay seperate though, as it's quite good
to have all URLs that are used in the UI seperated from the other content.
It looks as even Netscape, who had originally created that split-up has no interest any more in those
content packs. It even blocks me from renaming the generic German language pack to a simple "de.jar".
- localeVersion updates: locale packs from different Mozilla versions are incompatible because of
changed, added or removed texts in the UI. Quite some time ago, we introduced a localeVersion attribute
in chrome registry that has to fit, so that Mozilla knows it has a working set of chrome files.
So far, so good. Lots of contents.rdf files in the tree carry that information, which is hardcoded
there, and it's a big pain to update them for every version.
See bug 175853,
bug 185698
and bug 154927.
- no fallback mechanism: If people would try to use some non-fitting locale packs, they get crashes
and XML errors because we have no fallback if lookup for a locale string fails somewhere (string or file not found).
See bug 71797.
- XUL FastLoad problems: XUL FastLoad fails to update the strings after a locale switch.
There is a workaround in place, which also fails sometimes, and was promised to be replaced by a fix for 1.1 final.
See bug 142623.
- XPI installation problems - error -239: This bug is a really strange thing, and does hurt us mainly on unix.
When installing an XPI on most unix systems and some other systems as well, it fails with
error -239 (CHROME_REGISTRY_ERROR) for no obvious reason.
We're using a workaround for unix, but this workaround prohibits installing a new locale into the
profile directory, which would be needed for non-root users in the common case.
See bug 109044.
- No stringbundles from non-privileged files: This started to hurt me when trying to make about:plugins
localizable (see bug 56863).
In fact, I had to give about:plugins full chrome privileges just to access stringbundles - this opened
a potential security issue though. Even if about:plugins might go a different way now (HTML created by C++),
this is a potential issue for other areas.
See bug 98298.
- Resources: Currently, there's no single collection of documentation, tools, etc. for L10n people.
We're currently working on getting such a thing up and running now though.
See l10ntools.mozdev.org.
This should be some points to start for contributors who want to help us, and an overview what's bugging
us most currently. I'm sure the list is not complete, but it's what came to my mind when writing the slides...