Re: hreflang

Oskar Welzl wrote:
> 5.) It's Based On a Questionable Concept That Is Hardly Used
> 
> I don't have exact figures, but I made a quick check and examined a few
> sites that do have multi-language versions. I chose sites I regularly
> visit and websites of bigger companies. Only two of them use language
> negotiation: hotmail and google (google only to display a tiny link to
> the real localized version). 
> 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.

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!

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).

> The natural language that the human user might prefer/understand is
> generally unknown to the user agent. People are meant to set this option
> in the configuration dialogue, but how many really do? And even if they
> do: Does the person who uses the browser right now prefer the same
> language as the person who configured it?
> It's reasonable to ask why there should be an attribute that completely
> relies on a 'broken-by-design' feature hardly used in real life. 

The Accept-Language is broken-by-implementation. The design is solid 
as far as I can see. The problem is that user agents are sending 
*random* information.

I think that proposed @hreflang feature is broken-by-design.

> 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 think that the intended usage for this attribute is to allow 
user to change the content language of a web *site* to alternative 
presentation (via UI provided by the web site). However, if the 
feature is indeed supposed to be used to translate only a single 
page, then a better solution would be for *server* to send header 
"Alternative-Accept-Language: en;q=1,de;q=0.8,ja;q=0.5" with the 
response so that user agent could provide the translation in it's 
own UI. The example header above tells the UA that content has been 
originally written in English and it has a pretty good translation 
to German and somewhat acceptable translation to Japanese available. 
This method could be easily extended to Alternative-Accept to list 
available content types, for example. Think it as improved Vary header.

-- 
Mikko

Received on Friday, 11 November 2005 08:49:35 UTC