Mikko,

> > This might have several reasons, but one benefit: Language negotiation
> > is a questionable concept anyway, and the lesser it's getting used, the
> > better. Content negotiation in general is machine-to-machine
> > communication.
> 
> I disagree. Accept-Language would be one of the most important 
> features of an user agent *if* it contained real information.

You're right, I have to correct myself:
Language negotiation is fine if it's agent driven negotiation as defined
in 12.2 of RFC 2616.
It's chapter 12.1 (Server-driven Negotiation) that gives unwanted
results and a bad user experience (this thread might not be the right
place to go into this topic in detail); this, however, is exactly the
part of the http-spec that @hreflang in XHTML2 relies upon primarily.

> I agree that @hreflang as proposed doesn't work. @hreflang should 
> remain as metadata only but I'm not sure if listing multiple 
> languages should be allowed; it would be nice if I could just tell 
> my user agent which languages I can read and the user agent would 
> automatically mark a link as "foreign language" if it's @hreflang 
> didn't contain one of the languages I've listed. What good is a link 
> for me if I cannot read that anyway? It really doesn't help if the 
> content author can *force* me to use language I cannot read!

Agreed in principle; still, as we know from experience, UAs are not
likely to support metadata-information in such useful ways; for the
foreseeable future visualisation will be done using style-sheets. CSS in
particular would have problems with lists containing a mix of space and
hyphen-separated values, as indicated in my first mail.
My point here is that multiple values in @hreflang have well defined use
cases and should be supported eventually, but only after CSS can handle
them. In other words: As long as CSS is the by far most important means
of visualizing @hreflang, don't change @hreflang in a way that can't be
handled by CSS any more as this would drastically reduce the practical
value of the attribute.

> I think that if the spec really wants to say anything about 
> Accept-Language header, it should say that the user agent SHALL NOT 
> send Accept-Language header at all until it has confirmed that the 
> user really accepts all the languages listed in the header. In other 
> words, defaulting to *any* value wouldn't be accepted behavior for 
> an user agent.
> 
> If the user agent doesn't know which language the user can 
> understand, then it MAY use one of the languages listed in @hreflang 
> (preferably it SHOULD prompt user to select one).

Good point for @acceptlang or @getlang or whatever the new beast is to
be called then ;-)
I guess it wouldn't satisfy the needs of those who voted for the
proposed new behaviour in the first place, though.


> > 6.) Browser Behaviour Isn't Specified 
> > 
> > The spec now reads: "The user agent must use this list as the field
> > value of the accept-language request header when requesting the resource
> > using HTTP." - My interpretation is: The UA must do this _when following
> > the link_. What about the user interaction following immediately
> > afterwards?
> > Take the example from point 4.: The link forces my browser to use an
> > accept-language request header of "en" even though I prefer german and
> > the website is available in german. 
> > What if I follow a link on this website? Like I click on a headline to
> > read the article? Will I get the english version that corresponds to the
> > english headline? Or will my browser suddenly suprise me by presenting a
> > german text?
> 
> I think that for the proposed @hreflang to make any sense, following 
> a link on the target page should keep the same language that the 
> @hreflang set(*). However, it really doesn't make sense to change 
> Accept-Language for all pages so user agent should use the forced 
> @hreflang only for the that site. How is the user agent supposed to 
> indentify a "site"?

I'd happily leave these considerations to be worked out in the
definition of a new @acceptlang or @getlang attribute :-) 


Regards,

Oskar