swatt at infobal.com
Fri Oct 15 14:57:38 GMT 2010
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 faci=
>> same question :-)
>> I played around with C::P::I18N, and it does perfectly what is says it d=
>> l10n. But I want (need) more, like localized paths, for example. So I lo=
>> 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 usel=
>> 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 differ=
>> languages, a situation which I have here in my current project.
> Localised paths can be done though configuration. See Chapter 7 of the D=
efinitive Guide to Catalyst for details (p 187 - relevant snippet of code b=
elow, 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
> <Controller People::Info>
> <action get_info_ready>
> PathPart siapa
> <action create>
> PathPart lagi
> <action delete>
> PathPart mengusir
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Catalyst