Hi,
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.
Bye,
_______________________________________________
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/
