httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Striker <stri...@apache.org>
Subject Re: mod_mbox and i18n
Date Sat, 09 Jul 2005 22:58:42 GMT
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

Mime
View raw message