mod_mbox and i18n

[Maxime Petazzoni <ma...@bulix.org>]

Hi,

Last week, we've been discussing what mod_mbox should output (XML+XSLT
or XHTML?) and we seemed to settle our minds on a simple XHTML output
for the interface, plus of course the XML backend for AJAX
sub-requests.

Still, someone on the #apache-modules IRC channel (was it chipig or
iholsman ? I don't remember) came up with some questions about
mod_mbox internationalization.

mod_mbox does not have a lot of strings ('prev', 'next', etc. Stuff
like that), but it actually does not contain any i18n mechanism (these
strings are hard coded in the C code).

We are here facing problems, whatever solution is used :

- If we choose XHTML output, strings of the interface will be
  hard coded in the C code (in 'normal' / non-javascript browsing)

- 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
   * use variables for strings and a sub XSL defining this variables
     depending on the language.

In both cases, all strings of the interface in the AJAX browser (I'll
tell more about this in another thread tomorrow) are generated from
the Javascript.

I don't know much about i18n, neither in XSLT nor in
Javascript. Comments and ideas are welcome while I'm gathering more
information.

- Sam

-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.

Re: mod_mbox and i18n

[Maxime Petazzoni <ma...@bulix.org>]

> ?  Why not?  You can cache the results per language in memory.

I have to investigate on how to do this. Any pointers ? For the
moment, I don't have enough Apache and APR knowledge not to see in a
"per-request" mode.

> 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.

Absolutely. I know this, but I needed to present all solutions that
came to me.

> FWIW, I'm not too worried about i18n and mod_mbox.  It's only the
> interface changing language anyway.

Of course, but if we want it, it would be nice to choose now an output
format that will -later- comply to our i18n needs. I'm just trying to
think about a not-that-far future.

- Sam
-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.

Re: mod_mbox and i18n

[Sander Striker <st...@apache.org>]

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

Re: mod_mbox and i18n

[Maxime Petazzoni <ma...@bulix.org>]

> 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.

> 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).

- Sam

-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.

Re: mod_mbox and i18n

[Garrett Rooney <ro...@electricjellyfish.net>]

Maxime Petazzoni wrote:
> Hi,
> 
> Last week, we've been discussing what mod_mbox should output (XML+XSLT
> or XHTML?) and we seemed to settle our minds on a simple XHTML output
> for the interface, plus of course the XML backend for AJAX
> sub-requests.
> 
> Still, someone on the #apache-modules IRC channel (was it chipig or
> iholsman ? I don't remember) came up with some questions about
> mod_mbox internationalization.
> 
> mod_mbox does not have a lot of strings ('prev', 'next', etc. Stuff
> like that), but it actually does not contain any i18n mechanism (these
> strings are hard coded in the C code).
> 
> We are here facing problems, whatever solution is used :
> 
> - If we choose XHTML output, strings of the interface will be
>   hard coded in the C code (in 'normal' / non-javascript browsing)

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.

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.

-garrett