Re: Link Relations and languages

On Tue, Jul 14, 2009 at 11:01:43AM +0200, Sam Johnston wrote:
> I'm working on an application of link headers and have thought long and hard
> about the language issue. On one hand we should leave this to HTTP content
> negotiation but on the other we should be fully compatible with existing
> mechanisms and give people the option, removing it later if foud to be unused
> (as was ironically the case with te link headers themselves).

The lang and hreflang parameters can complement content negotiation.

If I create the following HTML resource variants:

I can serve these up with Apache httpd content negotiation at:

With transparent negotiation, I can serve up the following HTTP header:

    {"" 1 {type text/html} {language de} {length 0}},
    {"essay.en.html" 1 {type text/html} {language en} {length 0}},
    {"" 1 {type text/html} {language fr} {length 0}}

A client must send the following additional header to access this information:

  Negotiate: trans

Apache httpd does not let me provide variant titles with this header.

I can add the following elements to the HTML resource variants:

  <link rel="alternate" href="essay.en" hreflang="en" lang="en" title="Essay">
  <link rel="alternate" href="" hreflang="fr" lang="fr" title="Essais">
  <link rel="alternate" href="" hreflang="de" lang="de" title="Aufsatz">

I could mirror this information, and serve up the following HTTP headers:

  Link: <essay.en>; rel="alternate"; hreflang="en"; lang="en"; title="Essay"
  Link: <>; rel="alternate"; hreflang="fr"; lang="fr"; title="Essais"
  Link: <>; rel="alternate"; hreflang="de"; lang="de"; title="Aufsatz"

Being able to provide this information with every request, independent of the
client Negotiate header, and being able to provide variant titles, makes this
application of the Link header more useful than the Alternates header.

With a multilingual site, there may be cases where a related resource is known
to exist, and is only available in another language. These parameters would let
me link to that resource with the proper information, making this application of
the Link header more useful than the Alternates header.

I am doing some free software which manages these link relationships between
resource variants, and it would be nice to be able to use the Link header in a
standard way for this, especially when the media type doesn't allow me to embed
this metadata directly.

I do not think this introduces compatibility problems with existing mechanisms.


Noah Slater,

Received on Tuesday, 14 July 2009 10:33:49 UTC