On 8/17/07, Dan Scott <[EMAIL PROTECTED]> wrote: > 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. >
(stringbundle-ish side note: messagecatalog now supports %S. I can't justify keeping support out now that it has an in-line sprintf implementation, especially if there is real concern that there will be confusion (which... there has already been).) > 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'). > For that particular example, I think it makes more sense to adjust the code. I don't think it's sane to have individual messages controlling more than their own layout, and having a trailing newline seems to be only useful for that. So ... I adjusted the code and removed the trailing newlines from the messages. If I'm off base please let me know (and know why). Embedded newlines are another matter altogether, and have yet to be successfully dealt with. > 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 took a stab at replacing the characters that JS treats specially, including escaped unicode, but I don't have the special sauce working just yet it seems. See the getFormattedString element in bindings.xml for specifics, and feel free to poke at it. > 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. :) > Agreed on the need, though I'll be surprised if that method isn't spelled 'replace'. ;) -- Mike Rylander Equinox Software, Inc [EMAIL PROTECTED] http://esilibrary.com/
