[Catalyst] Re: Language selection in URLs
* Joel Bernstein j...@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/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Language selection in URLs
On Wed, Nov 18, 2009 at 9:55 AM, Aristotle Pagaltzis pagalt...@gmx.dewrote: * Joel Bernstein j...@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. 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 mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Language selection in URLs
why shouldn't you use domain as the part of the language? like en.example.com, cn.example.com and something like that? Thanks. Octavian Râsnita wrote: From: Bill Moseley mose...@hank.org 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 I prefer the former way because the URL looks nicer. (Not a very strong argument:) Are pages in different languages different resources or different versions of the same resource? In most cases I think it is the same content with a different presentation style, language... 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. There is an example on the Catalyst wiki for overriding prepare_path() in order to use urls like /en/path/to/another/file.html without needing to change all controllers. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Language selection in URLs
From: Fayland Lam fayl...@gmail.com why shouldn't you use domain as the part of the language? like en.example.com, cn.example.com and something like that? Thanks. Because each sub-domain would require another SSL key (or a special group SSL key that can be used with more subdomains. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
