I know messagecatalog has nothing to do with stringbundle, but as long as we're sort-of working towards more-or-less compatibility with the XUL stringbundle format there are a few niggling details to take care of.
The most important detail in the short term is to render '\n' as linefeeds, '\t' as tabs, etc, as specified in http://www.mozilla.org/projects/l10n/mlp_chrome.html. Currently, escaped characters are passed directly through _props2object, resulting in rather unsightly alert dialogs when strings containing linefeeds are concatenated together (take offline register patron for a spin and don't include any required fields if you want a demo of what I'm talking about -- 'Missing address: Postal Code\nMissing address: City\nMissing address: Line 1\n'). I initially thought we could map these special characters to escaped Unicode characters (\uxxxx) instead. However, a quick test of offline_checkout.xul using messagecatalog vs. stringbundle shows that unescaped Unicode (like \u000A for a linefeed) is passed through as the literal individual characters '\u000A' when I use messagecatalog, vs the desired linefeed when I use stringbundle. :( On the bright side, thanks to the addition of Unicode support to JavaScript 1.5, there's no need for escaped Unicode characters in the properties files. Entering characters like éèêç directly in the property file source results in the expected output in both stringbundle and messagecatalog -- meaning that there's no need for the native2ascii step. I'm willing to try attacking messagecatalog to fix this up, as there's no urgent need for it right away -- but we will have to have it worked out by 1.4 release as that's when i18n is scheduled to be on the table. This is mostly a heads-up. I am mostly hoping that there's an existing XUL method I can call to handle the escaped characters. :) -- Dan Scott Laurentian University
