[Catalyst] Re: Language selection in URLs

[Aristotle Pagaltzis]

* 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’s a good idea for non-human-readable content
served in a variety of formats, but for variants of anything
that’s like a “page” 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’s OK to accept conneg on neutral URIs and then *redirect* to
specific URIs based on the Accept-* headers. But don’t make
conneg the *only* way to pick a specific version of a resource.

> They are different *representations* of the same *resource*.

They are almost never *exact* equivalents. There are almost always
slight differences in content depending on language. _The medium
is the message._

And there is no reason not to have more than one URI for the same
resource anyway. Yes, you should pick one of them as canonical,
and unless you have good reason for doing otherwise, all the non-
canonical URIs be redirects. But these are merely good ideas, not
hard and fast rules.

> 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.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>