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
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
