[Catalyst] Multi-language and REST

[Ian Docherty]

Christopher H. Laco wrote:
> Ian Docherty wrote:
>> Christopher H. Laco wrote:
>>> Ian Docherty wrote:
>>>> I have been pondering how to take an existing Catalyst application 
>>>> and make it multi-lingual.
>>>>
>>>> I would prefer to use a RESTful method, so this would translate 
>>>> /foo/bar to /en/foo/bar or /fr/foo/bar (for English and French 
>>>> respectively).
>>>>
>>>> The problem as I see it is how to do this. I don't want to move all 
>>>> my controllers, e.g. MyApp::Controller::Foo::Bar to 
>>>> MyApp::Controller::Lang::Foo::Bar
>>>>
>>>> What other alternatives are there?
>>>>
>>>> Regards
>>>> Ian
>>>
>>> Well, I'm sure there's a somewhat elegant way to do this with 
>>> Chained, but it the other controllers don't use Chained now, that 
>>> could get fun.
>> I have considered chained, and would be prepared to re-write the 
>> existing controllers. A bigger decision would be renaming the 
>> controllers or moving them.
>>
>> e.g. existing MyApp::Controller::Foo::Bar maps to URI /foo/bar
>>
>> To match against /<lang>/foo/bar either I can leave the controller 
>> where it is (lib/MyApp/Controller/Foo/Bar.pm) or move it 
>> (lib/MyApp/Controller/Lang/Foo/Bar)
>>
>> The first approach is less work (only using chained) the second is 
>> more work, but maps the URI namespace more logically to the Class names.
>>
>> What would people do if they were writing a Catalyst App from scratch 
>> with this feature? That would tell me what the 'best practice' is 
>> even if it means a big re-write exercise.
>>>
>>> The brute force way is to inspect the request and rip out the 
>>> language portion before sending it on to get dispatched...just like 
>>> the Flavour plugin does with file extensions:
>>>
>>> sub prepare_path {}
>> One of my pet peeves  is exemplified in the 'Flavour' plugin. It is 
>> such minimal documentation that it neither tells you what it does or 
>> why it does it. OK, I can look at the code, but it is too much effort 
>> unless I think I have a good reason to do so. I assume in this case 
>> that it is something to do with date strings in the URI (for 
>> blogging?). I can't be ar**d!
>>
>>
>
> It does just what just what Bill suggested.
>
> "I check if the prefix is a valid language (if it's one of the language
> files I loaded at startup), if so I then remove it from the request
> path and append it to the request base."
>
> In prepare_path.. you inspect the requested path.. yank out the 
> language.. then pass along the remaining path...which should map to 
> your existing controllers just fine.
I have actually taken a look at the Flavour plugin (can't see for the 
life of me why it is called that!) and it gives an example of yanking 
off the /yyyy/mm/dd at the start of a path, putting the values into 
accessors of flavour (e.g. $c->flavour->year) leaving the rest of the 
path to be processed as normal. This is pretty much what I want to do 
for the language so thanks for pointing out the plugin to me.

I am pretty confident that I can now write a plugin to strip out a 
language from the start of a path in the same way.

Looking at the Catalyst best practices, am I going to be polluting the 
catalyst namespace by writing this as a plugin? I can't see any 
alternative (making it a base Controller is actually what I am trying to 
avoid).

Any suggestions as to a namespace for this? Catalyst::Plugin::LangURI 
perhaps?
>
> As far as chained goes... I thought there was an example floating 
> around that has Root::lang as Chained, then all other modules Chaine 
> against /lang as their root instead of /...
I should not need this if I do the above then I can leave my existing 
controllers unchanged (and unchained).
>
> -=Chris
>