[Catalyst] I18N

Stuart, I am in no way a Catalyst expert, just a mere beginner. And facing the
same question :-)

I played around with C::P::I18N, and it does perfectly what is says it does -
l10n. But I want (need) more, like localized paths, for example. So I looked
at C::P::I18N::Request which is perfect for that, but decides only on the
browser header setting of accept-language, AFAICS. Which renders it useless
for me.

Then there is C::P::I18N::PathPrefix, which is a helpful and different
approach. It comes in handy when path names are the same even for different
languages, a situation which I have here in my current project.

I haven't used CX::I18N yet, but looking at the docs it also looks promising.
I will certainly give it a try and play around with it to see if it matches my
needs.

As always with Perl, there are several ways... which is good.

Cheers,
Ekki

also consider:
http://search.cpan.org/~wehr/Catalyst-Plugin-Localize-Simple-1.1/lib/Catalyst/Plugin/Localize/Simple.pm

Localised paths can be done though configuration. See Chapter 7 of the Definitive Guide to Catalyst for details (p 187 - relevant snippet of code below, downloadable source for the book available from http://www.apress.com/book/view/1430223650) where I translated the uri paths into Indonesian:

<Controller People>
<action get_ready>
PathPart nama
</action>
</Controller>

<Controller People::Info>
<action get_info_ready>
PathPart siapa
</action >
<action create>
PathPart lagi
</action >
<action delete>
PathPart mengusir
</action >
</Controller>

Thanks for the feedback. CatalystX::I18N looks like it is heading in
the right direction, but it's testing status is pretty awful right now.
I might well fix the worst of the issues, as this has Moosiness and
other goodness.

I looked at C::P::Localize::Simple and its big win is _MISSING_TERM_ .
This is really what I need in C::P::I18N, but which I can't have because
it uses Locale::Maketext::Simple, which forces the Auto mode lexicon
behavior in an apparently non-overridable way, so missing values can
never be detected. This sounds like a significant issue with
Catalyst::Plugin::I18N, but which probably could be remedied by
switching it to use Locale::Maketext::Lexicon. This would be a huge
change, and I'd probably be the only beneficiary. However, I could be
convinced to to fix it if this was considered worthwhile by others.

C::P::I18N::PathPrefix looks cool, but it's a role that processes
request paths, so it could in theory be combined with a variant on
C::P::I18N that did the right thing. Unfortunately, the core C::P::I18N
doesn't, quite. This isn't a URL/path issue. I know the debates, but
we're dealing with an intranet system so clean URLs are preferred to
international support.

CatalystX::I18N does use Locale::Maketext::Lexicon, but may be hugely
overcomplicated for what I actually need, and as I said, it's rarely
passing tests -- although a look indicates this is mostly due to an
erroneous internationalization in currency and a dependency on "use
parent" which is not properly set in the dependencies on CPAN.

I *think* what I need to do is either (a) fork C::P::I18N, or (b) fix
CatalystX::I18N. However, given the Moose changes, I'm not sure which is
a better approach. I'm guessing (b), but this is a guess.

Stuart Watt
ARM Product Developer
Information Balance