Re: Default language

Andreas Prilop wrote:

> When you have no Accept-Language header or an unsual one (say,
> Finnish only), then  http://jigsaw.w3.org/css-validator/  looks like
>
>  http://www.google.com/search?q=cache:jigsaw.w3.org/css-validator

I don't know why Google has such an archived copy, but I get the English 
version in the cases you describe.

> I don't think this is a good idea.

Sending a 300 Multiple Choices response is protocol-correct, though it 
might be argued that 406 Not Acceptable (despite its user-unfriendly 
name) is more correct, if the request contained an Accept-Language 
header.

However, as regards to the accompanying explanatory HTML document, 
sending a typical default menu automatically generated in a simplistic 
manner is not user-friendly at all. Language codes should not be assumed 
to be widely known, when feasible alternatives exist. Moreover, a 
user-friendly menu would contain the name of the document in each 
language, in addition to the name and code of the language. (Note that 
the HTTP 1.1 protocol says that the entity SHOULD contain "a list of 
resource characteristics and location(s) from which the user or user 
agent can choose the one most appropriate", and a mere list of 
relatively obscure URLs and Q =1 notations hardly satisfies this.)

> The default version sent to the reader should be English.

That's debatable.

When _no_ Accept-Language header is present, it means that all languages 
are equally acceptable, according to the HTTP 1.1 protocol. Thus, it is 
sensible to send the version that you regard as primary or assume to be 
most widely understood. Note that by the protocol, a client MUST NOT 
send an Accept-Language header, if a choice of linguistic preference is 
not made available to the user.

When a specific header is present, say Accept-Language: fi, then "all 
languages which are assigned a quality factor greater than 0 are 
acceptable". This does not strictly say that no other languages are 
acceptable, but this seems to be the general idea. Thus, if the document 
is not available in any of the languages listed, this is an error 
condition, and 300 Multiple Choices should be the response. The protocol 
is somewhat vague, though, since it allows automatic redirection to a 
resource preferred by the server, under some loose terms, and the HTTP 
1.1 generally allows a non-acceptable response to be sent (indicating, 
in effect, that the word "acceptable" is a technical term and doesn't 
quite mean what it says).

I think that if language negotiation is used, it should be consistent so 
that if the resource is not available in any of the languages allowed in 
the request, a 300 Multiple Choices or 406 Not Acceptable response 
should be sent, together with a _helpful_ menu in the accompanying 
entity (HTML document explaining the situation).

The language of this entity may appear to be an unsolvable problem 
(which language do you talk to a user when telling that you can't talk 
in his language?), but this is superficial. I don't think "English rules 
OK" is the right principle here. Rather, the document should be 
understandable in any of the languages in which the resource is 
available; hence the idea of listing the resource name in each language.

One could actually do better than that, since the unavailability of the 
resource in any of the acceptable languages does not mean that the 
server needs to be unable to say _anything_ in any acceptable language. 
You could use a boilerplate 406 document in an acceptable (more 
specifically, the most preferred language) explaining that the requested 
resource is not available in any of the languages declared as acceptable 
in the request but it is available in the following languages, with the 
following names: ... (The server would need to pick up those names from 
a .var file or something similar, and it could pick up the names of 
languages from the CLDR data.)

Well, this isn't really something worth doing just for the CSS 
Validator, but I think it would be worth doing for W3C pages in general, 
especially to set a good example.

Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Received on Sunday, 6 April 2008 07:38:30 UTC