Am Freitag 01 Oktober 2010, 12:13:44 schrieb BUCHMULLER Norbert: > On Thu, 30 Sep 2010 22:32:03 +0200 Ekki Plicht (DF4OR) wrote: > > Am I right that this combination (see subject) does not work well > > together? > > Dunno, never tried them, but if they don't work together it's a bug that > should be fixed. > > > AFAICS C::P::I18N::Request modifies the path very early in the request > > cycle, before the dispatcher and C::P::I18N::PathPrefix can kick in, > > right? > > Yup, but if you swap the order of these two plugins, ::PathPrefix can act > before ::Request (and, BTW, ::PathPrefix also acts before the dispatcher, > these two modules hook to the same method:-). > > Can you try if it works if you simply change the order of > loading ::Request and ::PathPrefix? (If it works then I'll update the > documentation to mention it.)
Doesn't work, sorry. Ok, here goes: in wshop.pm: # sequence of I18N::PathPrefix and I18N::Request changed order use Catalyst qw/ -Debug ConfigLoader Static::Simple I18N I18N::PathPrefix I18N::Request Authentication Authorization::Roles Session Session::State::Cookie Session::Store::FastMmap Email /; in Root.pm: sub egalwie :Path('/target') :Args(1) { my ( $self, $c, $testparam ) = @_; } in de.po: msgid "PATH_delocalize_dogerman" msgstr "target" in en.po: msgid "PATH_delocalize_doenglish" msgstr "target" So both paths, 'doenglish' and 'dogerman' should point to the same action 'target'. In header 'accept-language': en URI requested: /en/doenglish/1 Result: 200 $c->language as displayed in template: en URI requested: /de/doenglish/1 Result: 200 $c->language as displayed in template: de URI requested: /en/dogerman/1 Result: 404 $c->language as displayed in template: en URI requested: /de/dogerman/1 Result: 404 $c->language as displayed in template: de In header 'accept-language': de URI requested: /en/doenglish/1 Result: 404 $c->language as displayed in template: en URI requested: /de/doenglish/1 Result: 404 $c->language as displayed in template: de URI requested: /en/dogerman/1 Result: 200 $c->language as displayed in template: en URI requested: /de/dogerman/1 Result: 200 $c->language as displayed in template: de The results are understandable and logical - only a path for the current language _as_ _defined_ _by_ _the_ _accept-language_ _setting_ is localized and found. The PathPrefix language is ignored at this point in the request cycle, only later it is properly set, as the $c->language var in the template shows. And that seems to be independent of the order of the plugins in the use statement. Yup, just tested the old sequence, same result. So the header setting of 'accept-language' always takes over for path localizations. When set to 'en' english localizations are used, when set to 'de' german localizations are used. Regardless of the path prefix. That's not what I expected or want. I want the PathPrefix to override the 'accept-language' setting in the browser much earlier, at a place where path localizations done by C::P::I18N::Request. Feasible? Maybe, but wouldn't it break the behaviour of PathPrefix when used in conjuntion with I18N::Request? Localized paths are nice to have, but not a must at this moment. So I could live with out using I18N::Request. Thanks & Cheers, Ekki _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/