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
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
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.
ARM Product Developer
On 10/13/2010 6:35 PM, Kieren Diment wrote: On 14/10/2010, at 8:25 AM, Ekki Plicht (DF4OR) wrote:
Am Dienstag 12 Oktober 2010, 22:04:23 schrieb Stuart Watt:
Quick question: I'm currently using Catalyst::Plugin::I18N. Should I
be planning to move to CatalystX::I18N? Any thoughts...?
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
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.
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:
Searchable archive: http://firstname.lastname@example.org/
Dev site: http://dev.catalyst.perl.org/
This message was scanned by ESVA and is believed to be clean.
Click here to report this message as spam.http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=5077128085.81EFD
-------------- next part --------------
An HTML attachment was scrubbed...