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

[Mike Rylander]

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).)

> 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
miker at esilibrary.com
http://esilibrary.com/