[OPEN-ILS-DEV] messagecatalog -- linefeeds and other escaped characters

[Dan Scott]

On 18/08/07, Mike Rylander <mrylander at gmail.com> wrote:
> On 8/17/07, Dan Scott <denials at gmail.com> 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