Re: Re: Sqwebmail roadmap

On Mon, Apr 19, 2004 at 08:54:07PM -0500, James A Baker wrote:
> Though you're also correct, in that one of the translators' biggest 
> complaints has been that whenever the HTML files are changed, you have 
> to very carefully check to see if your strings include any needed 
> changes too... and even if they don't, you have to open each HTML file 
> and copy your old translated strings into each file.

The aim should be that you can release a new version of sqwebmail with an
existing translation, and it will just work out of the box.

If Sam has added a new message into sqwebmail, then that message will be
displayed in it's default (English) form; all messages which have been
previously translated will remain in their translated form.

It would be nice to have a feature for the maintainer, which would
automatically generate a list of untranslated messages for each language.

> I mean, as opposed to integrating gettext, which I think would be a 
> fairly involved undertaking (esp. for me, since I don't know anything 
> about how that system works at all), then merely consolidating the 
> strings used into one file (instead of being in each individual HTML 
> file) should be a fairly simple thing.
> 
> It could mean an extra file open for every page sent... but I think 
> that should be a minor enough bit of overhead to make it worthwhile to 
> all except the few (very few??) servers which are already greatly 
> over-stressed.

sqwebmail is now a daemon of course, so you can load it at the start.

It does seem appealing to write a simple key->string lookup system (where
'key' is some message tag plus the language, and 'string' is a UTF8 result),
But I think it's worth taking on board the point that eventually such a
system is going to reach its weak points and you might as well invest in
learning gettext in the first place.

Regards,

Brian.