[Catalyst] Working with C::P::I18N::Request and C::P::I18N::PathPrefix at the same time?

[Ekki Plicht (DF4OR)]

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