W3C home > Mailing lists > Public > www-international@w3.org > April to June 2008

Re: 2 many language tags for Norwegian

From: Leif Halvard Silli <lhs@malform.no>
Date: Wed, 30 Apr 2008 04:10:47 +0200
Message-ID: <4817D527.3060909@malform.no>
To: Martin Duerst <duerst@it.aoyama.ac.jp>
CC: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, www-international@w3.org

Martin Duerst 2008-04-29 11.29:
> At 09:47 08/04/26, Leif Halvard Silli wrote:

> >If it is possible to get the browser to a) send out that it prefers 'nn', while b) at the same time get it to fall back to no or nb if nn isn't awailable.
> Just add no and nb to your preferences, after nn.

The question was not about what I can do in my browser. The question was 
how I can get the server to send out "nb" if "nn" isn't available, the 
same way that server algorithms make a server send out "en" if "en-gb" 
isn't available. See below.

> >It should be simple. When I select 'de', then I get de-AT if nothing else in German is awailable. When selecting 'en' then en-GB get served if nothing else is available in English.
> Yes. Depending on whether there is a common first subtag or not,

And this is the - ah - stupidity/lack of logic in the ISO tags. It is 
not my fault that there isn't such a common first subtag for Norwegian. 
Germans are lucky that their language difference follow Geographical 
lines coverd by the United Nations.

If web standards was based on ISO 639-3 instead, then I had more to play 
with, since then I could have used nor-nbo for Norwegian Bokmål. And if 
my browser said 'nor', then that would be a match, due to the way Apache 

(The Apache language algorithm matchin is clearly only suitable for 
languages that are lucky to have only geographical sub tags - or how I 
shall say it.)

> the solution differs, but it's always possible to get things in
> the desired order. Please note that you also need to set two
> preferences in your browser if you prefer en-GB, but are okay
> with en in general.

This, again, was not about me. But how to solve a general problem. A 
German users is allowed to be "lazy" and only select "de". Then he will 
get all variants of "de".

I see no reason why a Norwegian should not be allowed be the same kind 
of lazy. (John had some ideas here, that I should investigate.)

> >I can set *my* browser to permit nb, nn and no. But not any browser. Not on OS X, at least. On OS X, the browser (Safari/Webkit and those that interact with the system - Camino/Opera) only sends out one accept language header.
> In my view, such browsers are simply broken. And that has nothing to do
> with the problem of organizing a hierarchy of closely related languages
> or variants. Many people are multilingual, and need a way to express their
> preferences. In my case, that typically looks like English, Japanese, German,
> French,... Please file a bug for these browsers.

Unfortunatly, I must file a bug for the entire Mac OS X, since it is 
linked to how the language preferences works there.

> >When I set *my* browser to prefer nn,no,nb - in that order - and visit a web site running Apache, offering Norwegiang then it happens that I get the page in English.  This is not strange, because when I look inside Apache 1.3 on my Mac, then it has two AddLanguage options "ready": 'no' for Bokmal and 'nn' for nynorsk.
> No, this IS strange. If you send preferences for all of nn, no, and nb
> before any other language, and there is any of nn, no, and nb, then
> you should get any of these, not something else.

I was not spesific enough about the problem. On my system, Apache had 
only AddLanguage no .no enabled. But it included info about AddLanguage 
nn .nn. That is why it wasn't strange.

> >I can't set 'no' on top in my browser either, because then I will not be sereved 'nn' whenever a page exist as 'nn' and 'no'.
> Of course, if you prefer nn, then that should come first.

We are repeaing issue that has allready be discussed. But there is no 
logic - other than the logic of technical limitations in Apache - to 
what you say. The tecnical limitatiosn are  due to ISO specs which are 
not perfect for this task. The problem is that "nn" is a sublanguage of 
"no" and just as "nb" is a sublanguage of "no". Apache should treat a 
request for 'nn' as a requst for the none existing tag 'no-nn', and thus 
fall back to 'no' if 'nn' isn't found.

As John said, we should be allowed to configure the algorithms of Apache.
leif halvard slli
Received on Wednesday, 30 April 2008 02:11:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:29 UTC