A lot of Mozilla localizers think that the Mozilla Foundation doesn’t care about them. This is simply not true. Nobody I’ve talked to at MF denies the importance of localization. However, there is plenty of disagreement about what should be done, and who should do it. Many code developers (who deal with source code all day long) wonder why translators can’t just translate the source files. They look down on the semi-automated tools like Mozilla Translator as a crutch.

I like the automated tools. Anything that makes the workflow faster, without sacrificing quality, is great and should be supported. However, I don’t want the Mozilla applications to be a slave to the tools. I have designed changes to the localization system which will provide significant benefits in terms of the maintainability and scalability of the localization process. I believe that the model we have now, where we take a build and extract files to localize, and then repack the build, is a model that already scales poorly, and will get worse as we add more separate applications like NVU and Sunbird. In addition, it makes it pretty much impossible for mozilla.org to release official version of the localized build. Instead, the localizations should be done at the source level. This is bound to cause some difficulties simply because it is different than what is currently done. The goal is to provide automated scripts to reduce the pain as much as possible.

What I need is an enterprising hacker to modify Mozilla Translator just a little. I’ve tried to get in touch with Henrik Lynggaard but I haven’t been successful, so I’m going to try to pingback his weblog. In any case, MT does not like the directory structure of the new JAR files I am trying to feed it. I am hoping it would be simple to modify the assumptions of MT so that it recognizes the new directory structure (which is the directory structure in CVS).

Here is an incomplete example of the directory structure for the toolkit locale source. Java hackers, please help!

toolkit-en-US.jar
chrome/global/contents.rdf
chrome/global/localized.dtd
chrome/necko/contents.rdf
chrome/necko/localized.properties
installer/install.rdf # for installable langpack
installer/install.jst # for localized build

I also have a sample JAR (very incomplete) available for download.

I keep blogging about Mozilla and not about the important stuff:

I had an epiphany the other day, and I haven’t had time to explore every niggly little detail. So I am proposing a challenge for some enterprising hacker: make firefox.exe an out-of-process COM server for the mozilla activeX control.

Then, once it’s working, have the control register itself as a full-page handler for the text/xml, application/xhtml+xml, and application/vnd.mozilla.xul+xml mime types. This would allow IE to seamlessly/silently display XHTML and XUL content using the (much more powerful and standards-compliant) gecko rendering engine. Note: this would not replace the default IE HTML rendering engine, which is possible if you hack the IE binary or the windows registry, but isn’t a “good thing”.

I don’t have the time/energy to actually code this, at least not for a decent while, but I would happy to give detailed assistance to an enterprising hacker: what’s involved is basically calling CoRegisterClassObject during the bootstrap process (somewhere in nsAppRunner.cpp or nsNativeAppSupportWin.cpp). It’s likely that the existing activex control code can be used almost unchanged, but you would probably need to excise some of the custom profile-handling code. There’s a little bit of COM magic needed to inform the appshellservice that it shouldn’t shut down until all embedded instances have gone away, in addition to ordinary XUL/browser windows.

Note: I haven’t talked to Adam Lock about this yet… I just posted on the spur of the moment. If somebody wants to make this happen, we definitely need to talk with him.

I ended up volunteering to architect the localization of Firefox 1.0 and beyond into the new toolkit. This is not a small undertaking, but it looks to be relatively manageable on the aviary branch, since I don’t need to worry about breaking seamonkey on the branch.

The consensus between developers is that we need to get the localizations into the CVS repository. This will help with quality control and openness, and perhaps help companies that base products from the mozilla codebase to benefit from localization efforts. In addition, we need to collect all the en-US locale files that are scattered throughout the tree into a small set of locations. These will be:

toolkit/locales/ab-CD
browser/locales/ab-CD
mail/locales/ab-CD

“pseudo-extensions” (xmlextras) that are actually part of the toolkit will be moving into the toolkit directory. “Real extensions” (DOM inspector) will be localized in their own tree (extensions/inspector/locales/ab-CD).

I hope to blog regularly with updates, as I make progress and make decisions. There are still some leftover issues with how the installers are going to be shipped. We want to strike a balance between not forcing leaf to build 10-20 releases, and not having a single release with all localizations in it, which has the possibility to be quite bloated.

To facilitate the transition, I am adding support for preprocessing jar.mn files. Please do not use this feature unless you are aware of the issues (in particular, don’t use platform-specific #ifdefs in jar.mn files… it causes havoc when you start to ship language packs).

Thursday, July 1 at 7pm, St. Patrick’s will host the orchestra and choir of the Imperial College School of Medicine, London. They will perform a free concert at the parish:

• Beethoven Coriolan Overture
• H?ndel Dixit Dominus
• Bach Brandenburg Concerto #2

This should be a a fantastic concert, please consider coming!

I was giving a talk to a class of seminarians a few months ago, and their most-asked question was “what can I do to promote good music at my future parish.” The answer to this question is multi-faceted, no doubt, but I feel that there are three necessary components of a good music program which are frequently overlooked:

1. Junior choirs and music education: The choir is the foundation of any good music program; the really good singers are the leaven which help the rest of the congregation to active musical participation in the Mass (singing and listening). Good choirs do not just appear from nowhere; it takes careful and sustained music education, from an early age, to have a truly excellent music program. Start with a junior choir, for children in 3-8 grades; continue with a youth choir (if there is enough interest) for high-school youth; finally, graduate singers to the senior choir. For those who are tone-deaf but have good rhythm, there should be a bell choir.
2. Singing the basic responses of the Mass: it is amazing to me how many parishes sing an opening hymn and have good choirs, but the priest will not sing the basic responses of the Mass (“The Lord be with you”). It is explicitly required that the basic responses of the Mass be sung, if any of the more-complex parts of the Mass are sung.
3. Consistency is a virtue, variety is not: most parishes sing a different tune for the Memorial Acclamation (“Christ has died, Christ is risen…”) each week. There is no need for this “variety for variety’s sake”. This is one of the most basic responses of the Mass, why not sing the same tune at every Mass? I can guarantee that a good, simple tune for the basic acclamations will not become boring, no matter how many times you sing it.

There are, of course, many additional ways to foster singing in the parish. Hiring a good organist is one of the basic necessities for most parishes. And, at some other time, I will begin posting on my thoughts about the need for a unified repertoire of chant for the entire U.S. (a national hymnal).

Most mail readers have a feature by which incoming messages can be sorted into categories (folders) based on characteristics of the message, such as the sender, the mailing list it was sent to, the priority assigned to the message, etc. The rules defining this sorting process are called “Filters” by Mozilla Mail and “Message Rules” by Outlook Express. These filters/rules are generally quite static; if you are computer-savvy enough to figure out how to create a filter, you set it up and leave it alone. However, I have found that static filters frequently do not meet my needs: I want to manually sort messages into various folders, and then have the mailreader filter all replies to these messages into that same folder. For example, I am currently involved in 100+ Mozilla bugs, divided into several general categories:

semi-single-profile/firefox 0.9
xulrunner/mozilla-the-platform
xpinstall/installer (mainly as a reviewer)
build config (random crap)
RDF implementation bugs and API redesign

I want the ability to sort messages from two mailing lists, several newsgroups, private mails, and bugmails into folders for each of these categories. I don’t find it especially onerous to drag the “first” bugmail, private mail to the subfolder. But after that, I want all subsequent mails to be auto-sorted into the correct category.

It doesn’t seem to me that this would be especially hard, if we’re only discussing email. Newsgroup messages are a lot harder to handle in this scheme. Maybe I’ll break down and use the mailing-list versions of the netscape.public.mozilla.* groups instead.

P. S. I also want the view-sorting mechanism to be smarter; my preferred view-sort would be “threads with unread messages first, and then threads sorted by the newest message in the thread.”

Part of the mozilla2.0 project is providing generic support for running XUL applications. This has been known by various names, including the XRE and the apprunner. The current way to run a XUL application is to run mozilla.exe -chrome <url>. However, this is a poor solution for several reasons:

1. Apps have little/no control over command-line param handling (the default handlers installed by the mozilla app are always active)
2. Apps have little/no control over window icons.
3. Apps have to use the mozilla profile, and have odd or no control over remoting (xremote/DDE/appleevents)

The solution to this is a dedicated program to run XUL apps. This “xulrunner” will run XUL applications, from the smallest one-file applications to the largest apps such as firefox and thunderbird.

The first steps for the apprunner will be basic. However, I (and others) intend to work the xulrunner to a feature-complete solution within the next six months. There are several feature requirements for a full-featured xulrunner:

• Apps must be able to integrate with the OS/shell in an cross-platform way. This includes file assocations and icons, “start menu” icons, and desktop/quicklaunch icons.
• Native uninstall support on windows.
• App must have the option of running with shared preferences for all gecko-based apps.
• The app will have the option of running with it’s own app-specific profile, or no profile at all.
• Finally, I’m doing a simple GUI builder/packager to automate the app-building process. As a first step this will not do GUI XUL editing, only “packaging/building” using a wizard-like interface.

As a second step, I would like to give the xulrunner the ability to run apps in a restricted security space. This might involve some major backend changes to how mozilla handles security contexts (more on this later).

I have just landed semi-single-profile on the firefox trunk. It will probably take a couple days (or more) to settle out the major regressions in the startup code. It will probably take even longer to settle out the interesting problems with the extension manager (it’s a totally-new functionality, and it’s hard to debug).

When reporting bugs, please make sure to say what version (trunk or branch) you’re using, and what the build date is. Please also search for existing bugs carefully… I have been surprised at how many duplicates are files of firefox branch bugs for 0.9.

Right now, we are using the same restart mechanism on the trunk as we did on the branch. On most platforms (except Mac) this involves using execv to replace the current process. On mac, it turns out that execv doesn’t work for bundled apps, so we have to use trickier system calls.

This is going to change, relatively soon. I have been working at making XPCOM re-startable, so that you can call NS_InitXPCOM2/NS_ShutdownXPCOM several times over the life of the app. This is more “dangerous” because of static data in the tree that might not be cleaned-up properly during XPCOM shutdown.

Suzanne and I proudly announce the birth of Eleanor Park Smedberg, born June 15, 2004 at 9:33 a.m. Her birth weight was 6 lbs., 6 oz.

She is so cute.

Suzanne is doing well, and will be coming home from the hospital (GWU) tomorrow: