On 18/08/07, Mike Rylander <[EMAIL PROTECTED]> wrote: > 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).)
Well, if it's any consolation, the Mozilla documentation for stringbundle itself switches almost randomly between %S and %s, so at least it's not just me getting confused. I agree that the most correct approach would be to simply use standard sprintf formatting, and really wish http://ecmascript-lang.org had a proposal for sprintf in the next iteration of the language -- or that Mozilla had exposed a JavaScript interface to the sprintf implementation they have in nsTextFormatter (or whatever it's called, flying blind trying to get this response out!). > > 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. Naw, you're absolutely correct. That's how I had it in a previous patch, but I changed it (for the purposes of testing embedded newlines, actually), and it just stuck after that. I lost my focus on the goal! > > 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. Well, thanks for the initial iteration! I'll try to poke away. -- Dan Scott Laurentian University
