[Catalyst] Re: Language selection in URLs

Bill Moseley moseley at hank.org
Wed Nov 18 19:19:15 GMT 2009

On Wed, Nov 18, 2009 at 9:55 AM, Aristotle Pagaltzis <pagaltzis at gmx.de>wrot=

> * Joel Bernstein <joel at fysh.org> [2009-11-15 16:30]:
> > No no no! Allow the client and server to negotiate what content
> > to serve for the resource identified. As a URI to a resource
> > which may vary according to many dimensions,
> > /path/to/some/content is fine.
> >
> > GET /path/to/content HTTP/1.1
> > Accept-Language: en
> > Accept: text/html
> Conneg sucks. It=92s a good idea for non-human-readable content
> served in a variety of formats, but for variants of anything
> that=92s like a =93page=94 you should have separate URIs, so that
> people can reliably bookmark one of them, or send someone else
> a link to talk about it and not have the other person see
> a completely different page (or file or whatever), etc.
> It=92s OK to accept conneg on neutral URIs and then *redirect* to
> specific URIs based on the Accept-* headers. But don=92t make
> conneg the *only* way to pick a specific version of a resource.

I think this is very good advice.

> > If you really must stick it in the URL, I'd go for something like:
> > /path/to/content/en
> > /path/to/content/pt_BR
> > etc
> Worst of all worlds, IMO. The query parameter is easiest to
> implement for the server, while the path prefix allows the user
> to hack the URI conveniently (so the latter is what I would do).
> Your suggestion is harder to implement than both and makes URIs
> annoying to hack.

I think Catalyst makes the path prefix the easiest.  WIth the query
parameter (which I'm doing now to be compliant with a legacy app) it's
trivial to by using "around uri_for", but I'd much rather do something once
(modify $->req->base) than override every uri_for.

I do have a slight fear of the query parameter messing with caching.  I
doubt it's much of an issue these days, though.

-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091118/21220=

More information about the Catalyst mailing list