Re: [evolution-patches] HIG errors for mailer monster patch

[Jeffrey Stedfast <fejj ximian com>]

ugh, having to scan for the proper xml node is painful. A couple ideas, not sure if any will fly:

1. after loading the xml file, rip out the nodes that don't match our locale (leaving the C lang for any nodes where we can't find a matching lang)

2. any way to get intltool to generate different xml files, 1 per lang? and then place the xml files in different directories or something or name them somehow so as to allow us to only load the appropriate xml file? composer-errors-C.xml, composer-errors-en_AU.xml, etc?

having all the translations for all the langs for each error is gonna sue up a fair bit of memory I'd imagine :-(

Jeff

On Fri, 2004-04-16 at 17:31 +0800, Not Zed wrote:

"Team",

This is a snapshot of the work i've been doing - i branched evo as notzed-eerror-branch for it too.  This isn't fully complete yet, and not widely tested, however it should provide hig'd errors for:

- filter stuff
- all mailer errors and questions (incl get password, etc).
- most composer errors
- camel errors, even if the text itself isn't hig yet.

It does a lot more than the error list from Ben provided alternate text for, although not everything he listed - yet.  But now error text (apart from camel) is quite separate from the code and can be changed in most cases independently of it.

For the error text, instead of using ${n} i borrowed the C# idea of just using {n}.  So you can't put { in errors anywhere (or at least in the formats), but the numbering scheme saves a lot of bother with repeating values or re-using values in different fields.  Except all the arguments must be strings (all the mailer errors were strings anyway).  Hence as jpr asked - no issue with plurals, you can do that in code if required and pass it as a string.  I also extended the code a bit from the blog entry so it can do substitution in window titles too.

Does i18n, blah blah etc.  Although i'm not that fond of the way i18n is done, but intltool does "strange things" (from what i can tell, a mixture of gettext requiring translations for params and in-built xml:lang alternatives for elements), and the code should work (even if its not that efficient, though scanning 10 language alternates 5 times for 50 messages wasn't even a fly wing's flap on a C=64).

And if it isn't fully hig (i copied the glade file exactly though), or heaven forbid, the hig changes, it can be fixed in one place.

Well, I was almost "Big Kev Excited" about this yesterday, but maybe i'm not so sure anymore - it does the job, saves code (particularly with the HIG targetted buttons stuff), and decouples the interface from the code (so non-coders can tweak and test, without source), so it can't all be bad.

PS might've missed something in the patch (but nobody's gonna try it anyway).

Michael Zucchi <notzed ximian com> Ximian Evolutionand Free Software Developer

Novell, Inc.