...I have some users in my office who would always want the
Japanese versions if available, and most who'd always want the
English. Since we're in the same office, not only is
the domain name the same, but many times even the hostname is
identical, since some people are on X-terminals.
One can express one's language preferences with the Accept-Language
header in the request message. But there are two problems, one
specific to Accept-Language, the other more general
The problem with Accept-Language (it's really quite minor) is
that the HTTP specification is not yet written on this point. In particular
the means of expressing preferences is not worked out. Note that
Accept has a means of expressing preferences (the q parameter). But
it's not clear how q from Accept (which deals with content TYPE)
ought to interact with q from Accept-Language. Can you say
for instance that you would prefer written Dutch to spoken Dutch,
but spoken English to written English? (als je kan Engels heel
goed pratten, maar je vindt nederlands een beetje moeilijk?)
So suppose we extend the spec so that Accept-Language allows one
to ask for just what one wants, and that servers are able to handle it.
But we still have the problem that there's no way (at present) for
the user to tell the client (Mosaic, tkWWW, Cello...) about his or
her preferences. To give another example
The client might need to encode preferences based on the
type of hardware available (e.g. on black and white monitor,
or workstation with real good audio). IN this case the client
can express preferences automatically, based perhaps on
a template taken from the user. The user might change those preferences in real time, e.g. would rather see a low-resolution image first, to make
the search faster. (So this is independent of the hardware).
Anyway, what this means is that implementors of clients (may they see long
life and happiness) should provide means to specify information
such as required by headers like Accept and Accept-Language.
Best wishes to all