Re: XHTML 2.0 and hreflang

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Oskar, dear list members,


Am Donnerstag, 13. November 2003 22:36 schrieb Oskar Welzl:
> Christian,
>
> > - From the German page, he follows a link to another page with
> > the following
> > hotspot:
> > <a href="glossary" hreflang="de, en;q=0.8" title="Das
> > Glossar">Glossar</a> Now he should get glossary.de if it exists,
> > glossary.en otherwise (user's choice, overriding the user agent's
> > configuration).
>
> Christian, if a german version of 'glossary' wouldn't exist, it would be a
> bad practice for the author of the linking document (star.de) to link to
> it, wouldn't it?
Why should it be bad practice? In some cases it might be bad practice, but in 
other cases it might be quite okay.

The href attribute points to a language independent canonical base URI, not a 
document in a certain language.
Larger multilingual sites are full of links. Currently, no content negotiation 
is used because based on current possibilities in (X)HTML all possible 
choices of e.g. document / language combinations have to be handled by the 
author seperately.

> in your example, there's no choice for the user. the user
> clicks on a link. he's not offered a menu or something. he wants the
> glossary. and he probably wants the glossary in german, because he starts
> from a german page using a german language link.
But the glossary might only exist in English. There might be 487 links in a 
document, and I don't want to bother with "does link x exist in language y" 
with each of these links.

Currently I handle this using XSLT and only using content negotiation for the 
start page, but it's impossible to use language independent URI's then.


> i wonder why on earth hreflink should be so complicated all at once after
> it has existed for quite a while now and nobody ever thought of it as being
> in any way related to http-information.
Of course @hreflang is somehow related to the Accept-Language / Language HTTP 
headers, similar as the @type is related to the Accept / Content-Type 
headers.
The current XHTML 2.0 draft suggests even stronger relationship between @type 
and HTTP, so why not also have a stronger relationship between @hreflang and 
HTTP.
By the way I always thought @hreflang of being related to HTTP. If everything 
is fine, the HTTP Language header of the referenced document corresponds with 
the @hreflang attribute of the referencing document.

> > I would normally not request the
> > user to change
> > his/her user agent's accept language settings, since most average
> > web users
> > would be swamped with tampering with their user agent's settings.
>
> most certainly we would not want our users to change their UA settings. the
> web works fine now without this, i get every language i want without ever
> changig anything.
I regularly deal with multilingual sites, and there's nothing okay the way it 
currently is.
It's impossible to use content negotiated language docs with international 
uris because author and user have no ability to simply temporarily overide 
the user agent's accept language setting.
And it's impossible to use content negotiated language docs with uris 
containing the language information because if there's no accept language 
override, the user will often see a 406 response instead of a document that 
suites him/her, e.g. usually always if he requested a document in a language 
that doesn't suit his user agent's Accept-Language header.

Currently, because of the limitations of the @hreflang, content negotiation 
for the language is nearly limited to the start document of a site.

You may not have encountered that 406 response problem yet, because usually it 
only occurs if the content negotiation has more dimensions than just the 
language. I use at least three dimensions of negotiation: Language, 
Content-Type and Content-Encoding, sometimes also the charset.

Imagine the following choices:
start.de.xhtml start.de.xhtml.gz start.de.html start.de.html.gz
start.en.xhtml start.en.xhtml.gz start.en.html start.en.html.gz
(with their intuitive content-types, languages and encodings)

Imagine the following request:
GET /start.de HTTP/1.1
Host: somehost
Accept-Language: en, pl;q=0.5
Accept: application/xhtml+xml
Accept-Encoding: x-gzip
Connection: close

This will result in a 406 response.
If the @hreflang contained in the document had been taken into account, the 
request would look like e.g. this:
GET /start HTTP/1.1
Host: somehost
Accept-Language: de
Accept: application/xhtml+xml
Accept-Encoding: x-gzip
Connection: close

The author could use the canonical uri without any negotiated information in 
the uri itself. The @hreflang attribute overriding the default 
Accept-Language header does its job. And if the request URI is /start.de, the 
request will not cause a 406 response anymore.


Bye
- -- 
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter (Shareholding CEO)
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/tCxCzu6h7O/MKZkRApY4AKC2Y75hhYgTDtC1QeVAwMtzSaTBewCfT+19
QGgbIoOxMsdfaELWuYq7BXw=
=+u10
-----END PGP SIGNATURE-----

Received on Thursday, 13 November 2003 20:16:15 UTC