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 > Are pages in different languages different resources or different versions of > the same resource? They are different *representations* of the same *resource*. The dimension of variation in this case is the Accept-Language: request header. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.4 and you might reasonably vary the content type returned according to the client's Accept: header too. > Obviously, the prefix is easier if you use relative URLs, but uri_for makes > adding the query parameter easy. Although, probably could argue that the > prefix approach is more efficient than wrapping uri_for for every generated > link. 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 A better question is: what kind of problems are you solving where server-driven or agent-driven content negotiation as described in the HTTP 1.1 RFC (an excellent and very readable document, honestly) are insufficient? /joel _______________________________________________ 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/
