[Catalyst] Language selection in URLs

Pedro Melo melo at simplicidade.org
Mon Nov 16 12:24:17 GMT 2009


On 2009/11/15, at 15:23, Joel Bernstein wrote:

> On 15 Nov 2009, at 15:06, Bill Moseley wrote:
>> What's your preferred approach to specifying a language tag in a  
>> URL?  Is there strong argument for one over the other?
>> http://example.com/en_us/path/to/some/index.html # language prefix
>> http://example.com/path/to/some/index.html?lang=en_us
> 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

This is the proper solution, in a perfect world.

The resource /path/to/some/index.html has multiple representations and  
ideally you would use Accept* headers to choose between them, but it  
might make sense to provide several ways to access your data:

/path/to/some/index.html => give me HTML and pick the language based  
on content negotiation
/path/to/some/index.en.html => give me HTML in english
/path/to/some/index.pl.pdf => give me a PDF in polish.
/path/to/some/index.bork.json => give me a json file for swedish chefs

The reason to support this is to use with external web services. If I  
want to translate to russian, and I know that this cool web service  
has a very good polish-to-russian translator, but only accepts PDF  
files, I have a URL for that: /path/to/some/index.pl.pdf

So yes, please use content negotiation be default, but leave the door  
open to explicit addressing to specific representations of a resource  
to be used when content negotiation is not an option.

IMHO, it is not a mistake to add such alternative addresses.


More information about the Catalyst mailing list