On Apr 25, 2008, at 8:55 AM, Ian Docherty wrote:
Dave Rolsky wrote:
On Fri, 25 Apr 2008, Ian Docherty wrote:
http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12
Yes, I have done this previously, it is elegant, but not RESTful
and does not make it easy for users to change their settings on a
site-by-site basis dynamically, as you could if you provided a
language selection box on each page.
Why do you say it's not RESTful?
I think it's very RESTful, but it depends on how you think about
it. If the language of the content is basically an issue of
"formatting", then switching language based on a header is
perfect. The client provides sufficient information to produce a
correct response _on each request_ as part of HTTP. This is
basically the essence of REST.
OTOH, if you consider each language's content fundamentally
separate things, then each language should have its own set of URIs.
Yes, this is exactly what I had in mind. I did not (and still
don't) consider the language of the content as 'formatting', the
content for each language is different (in my mind).
I agree that it's content, not formatting. If CSS/client-side-JS can
(in a practical fashion) change it, it's formatting, otherwise, it's
content.
While a headers based solution sounds neat, it would cause several
problems. A multi-lingual user, like our friendly neighborhood
Aristotle who surely knows everything I'm saying already, might well
like to have his default/first accept in Swahili but read a certain
resource in Japanese, for whatever reason. Changing browser settings
to see a different resource would be awful UI. Also, the big search
bots would probably only end up indexing one version of your site.
The base/path swap sounds like a great approach.
_______________________________________________
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/