On Mon, Apr 19, 2004 at 09:47:26PM -0400, Sam Varshavchik wrote: > The point I was making is that we are not talking about wrapping gettext() > around literal strings in C code, then feeding it to gettext to generate PO > templates. That's not going to work here. > > The only way I see to use gettext with sqwebmail is to: > > A) Go through all the HTML files, locate all translatable text, and > demarcate it somehow. > > B) Modify sqwebmail's main generation loop to read the translatable text, > and feed it to gettext. > > Note: special-case the existing [#$ -- #] macros in sqwebmail's template > files. > > C) Put together a tool that reparses all the translatable strings and places > them into a dummy source file that's fed to gettext in order to generate > the pot template files. > > > B and C is not too bad. The killer is A: a lot of manual work. It might be > possible to write a once-only tool to automate the demarcation of > translatable strings in html template files.
(A) would be a one-off hit, and I don't think would take long. I wouldn't actually mind doing that part; it's the incorporation of gettext into the source which would take a lot of learning (for me). The huge win would be that there would no longer be a need for separate html/<lang> directories, just a single html/ set of templates. The only things I can think of which need to remain language-dependent are FOOTER and ISPELLDICT; the former can look for FOOTER.<lang> and the latter just needs a mapping table. I don't know how gettext works, but sqwebmail, as a persistent daemon, should be able to read the language files into RAM at startup - then the HTML generation should be no less efficient than it is now. Cheers, Brian.
