versioning of locale in chrome registry, fed into it by contents.rdf files.
<br>Those were <span class="hilite">previously hardcoded</span> and I did big manual patches to change them. After I found a way to
insert the versions at build-time and patched the whole tree to do that using the C preprocessor
- (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=154927">bug 154927</a>),
+ (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=154927" title="automate localeVersion updates based on milestone.txt">bug 154927</a>),
I was told we should use the <span class="hilite">XUL preprocessor</span>. I made that change recently
- (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=232011">bug 232011</a>)
+ (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=232011" title="Use the XUL preprocessor for build-time inserting of localeVersion strings">bug 232011</a>)
and set tinderboxen on fire (as some of you may remember)...
<br>After some help from tinderbox admins and bsmedberg (who had to fix make-jars.pl for a bug I triggered),
we should now have that long-standing bug finally resolved (and themes will follow that way soon -
- <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=234014">bug 234014</a>).
+ <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=234014" title="Use the XUL preprocessor for build-time inserting of skinVersion strings">bug 234014</a>).
<br>BTW, all chrome version strings are now defined in
<a href="http://lxr.mozilla.org/mozilla/source/config/chrome-versions.sh">mozilla/config/chrome-versions.sh</a>.</li>
<li class="minus"><b>XPI error -239</b>: When installing our <span class="hilite">locale XPI files</span>, we often ran into XPInstall
error -239 (CHROME_REGISTRY_ERROR), especially on unix machines. This had been happening quite
- frequently for at least 18 months (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=109044">bug 109044</a>),
+ frequently for at least 18 months
+ (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=109044" title=" Install error -239 registering chrome on some systems">bug 109044</a>),
and noone had an idea why that happened, when it started magically disappearing in some cases last summer.
<br>DocWilco then <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=109044#c64">filed a patch</a>
for a case where he was still seeing (and which was "a tough one to crack"), and we didn't hear a lot about
The first L10n IRC meeting was on 2003-12-15, The 1.6 CD shipped with a few important / finished-in-time
localization XPI packs, we're still hoping further actions will happen. The first string freeze (1.7b -> 1.7)
is still to happen, and getting translations into CVS is actually a quite old bug report,
- <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=57878">bug 57878</a> that still doesn't have much attention, as well as the one for
- getting German L10n into CVS (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=179949">bug 179949</a>).
+ <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=57878" title="Translations should be in CVS">bug 57878</a>,
+ that still doesn't have much attention, as well as the one for
+ getting German L10n into CVS
+ (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=179949" title="Get German/de-AT translation into CVS">bug 179949</a>).
<br>Let's hope the positive movement of December can be carried on into the future.</li>
<li class="plus"><b>Mozilla Europe</b>: Just last week, the <a href="http://www.mozilla-europe.org/">Mozilla Foundation Europe</a>
has been launched, having a <span class="hilite">multi-language web site</span>, and that probably will
<span class="hilite">after a locale switch</span>. There is a workaround in place (killing the FastLoad file),
which also fails sometimes, and was promised to be replaced by a fix for 1.1 final (!).
See <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=142623" title="No reload of Language strings due to XUL FastLoad">bug 142623</a>.</li>
- <li><b>Hardcoded content</b>: Yes, there's still some hardcoded un-localizable code in UI files left,
+ <li><b>Hardcoded content</b>: Yes, there's still some hardcoded <span class="hilite">un-localizable code</span> in UI files left,
a big part of this is low-hanging fruit for contributors and blocks L10n severily sometimes.
<br>All relevant bugs (should) have <a href="http://bugzilla.mozilla.org/describekeywords.cgi#l12y">the "L12y" keyword</a> set.
Query for <a href="http://bugzilla.mozilla.org/buglist.cgi?keywords_type=allwords&keywords=L12y&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED">All bugs with L12y keyword set</a>
and they forget about i18n issues or things like locale switching altogether.
<br>I had to fix breakage of the locale switching pref panel four times from 2002-03-31 to 2002-08-26 -
the FastLoad workaround (see above) was the fith issue that broke it during that time span!
- See <a href="http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/extensions/content-packs/resources/content/pref-contentpacks.xul">CVS Log of the pref panel</a>.</li>
+ See <a href="http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/extensions/content-packs/resources/content/pref-contentpacks.xul">CVS Log of the pref panel</a>.
+ <br>BTW, <span class="hilite">locale switching is now broken once again</span> (even in 1.7a): See <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=235058" title="Content/language switching from UI is broken">bug 235058</a>.</li>
<li><b>No stringbundles from non-privileged files</b>: This started to hurt me when trying to make about:plugins
localizable (see <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=56863" title="make about:plugins localizable">bug 56863</a>).
In fact, I had to give about:plugins full chrome privileges just to access stringbundles - this opened
a potential security issue though.
See <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=98298" title="do not have stringbundle access from about:plugins">bug 98298</a>.</li>
<li><b>Content packs</b>: We should investigate if we really need seperate packages for that content,
- as the real idea never took off. Merging them back into normal localization content could ease a few things.</li>
+ as <span class="hilite">the real idea never took off</span> (mainly Netscape had further plans with that).
+ Merging them back into normal localization content could ease a few things.</li>
</ul>
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...
projects / slides.git / commitdiff