I implemented a custom tag in my pages <I18N id='1234'>Your text
here</I18N> (the syntax is a bit uglier than that since it has support
for arguments and other fun things, I also have a toolchain to maintain
the IDs and the catalog)
I then set my mason handler up to make a compiler and interpreter for
each locale. The compiler has custom preprocess hooks to translate the
strings using the gencat libraries, so the Mason components get
translated when they are compiled. Any I18N strings inside my core
modules need to be wrapped with an explicit translate call.
The other pain is that I have had to litter my mason handler with
POSIX::setlocale calls (and calls to set $ENV{LC_ALL}) since Mason
really wants to be in a consistent locale when it is running, but the
pages should be in the appropriate locale so that dates, number formats,
etc. are correct.
Works fairly well.
-ben
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Oliver Jeeves
> Sent: Tuesday, January 09, 2007 5:51 AM
> To: Kovacs Baldvin
> Cc: mason-users@lists.sourceforge.net
> Subject: Re: [Mason] l10n efficiency
>
> Kovacs Baldvin wrote:
> > Hi!
> >
> > I find l10n solutions somewhat questionable: it seems that they use
> > runtime lookups even for things that could be done in
> compile time. I'd like
> > to ask you to point me to some readings on this topic if I
> am missing
> > something.
> >
> > A very good l10n doc is
> http://code.bestpractical.com/bps-public/Locale-Maketext-Lexic
> on/docs/webl10n.html
> > It suggests constructs like these:
> >
> > % $m->print(loc("Another line of text", $args...));
> > <&|/l, $args...&>Single line of text</&>
> >
> > I am wondering if a different approach would be possible:
> why don't we
> > hack the mason compiler to compile not just .obj files from the
> > templates, but .en.obj, .fr.obj, .de.obj, ... When a
> component is to be
> > run, then the appropriate .obj file is taken, and would run the same
> > speed as there were no internationalization would be in place.
> >
> > I know that if a new feature is asked for, it is best to
> give some code,
> > not just "bright" ideas... I am ok with it, however, before I try to
> > tweak Mason this way, I'd like to ask you if there exists
> prior art, so I
> > don't reinvent the wheel. Also, I'd like to hear criticism
> of the idea,
> > because if it is stupid, I'd better not invest too much
> time in it...
> >
> > Best regards,
> > Baldvin Kovacs
>
> It sounds like you're basically trying to implement content
> negotiation
> inside Mason.
>
> I think the approach I'd use, would be to have several components, in
> different languages, and then get the dispatcher to dispatch to the
> correct component (with a default fallback). This strikes me as being
> easier to achieve, you might even be able to get Apaches content
> negotiation module to do the leg work for you here, maybe.
> This strikes
> me as being easier to achieve.
>
> Just my thoughts on the matter.
>
> -Oli
>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
