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.
