Maxime Petazzoni wrote:
There's no reason the strings have to be hard coded into the C code.
You can pull them out into some sort of language specific file, just
like any other C program that worries about i18n.
This would mean more file I/O every time mod_mbox runs, and maybe
using an external library such as gettext (quite heavy stuff for
mod_mbox needs). Maybe some home-made system, but I fear that it won't
be fast enough.
? Why not? You can cache the results per language in memory.
Honestly, that seems like a far better solution to me. XML+XSLT
seems like extreme overkill if all you want is a way to have the
strings change on a per-language basis.
I did not proposed XML+XSLT as a solution to i18n problems. It is just
an interesting system that can provide both templating-like mechanism
and i18n facilities (still, not as clean as I would like).
Quoting from your previous mail:
- With the XML+XSLT output, these strings are in the XSLT so they can
be easily translated. Two "sub-solutions" are available :
* provide a full XSLT per language
Not maintainable if you ask me. Code duplication is something we want
to avoid, and having to push xsl changes to n translations seems like
a bad idea.
* use variables for strings and a sub XSL defining this variables
depending on the language.
This is, at least in my mind, not going to be one bit faster than using
(cached) gettext.
FWIW, I'm not too worried about i18n and mod_mbox. It's only the interface
changing language anyway.
Sander
