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

Re: Language tag education and negotiation

From: Leif Halvard Silli <lhs@malform.no>
Date: Sat, 26 Apr 2008 14:57:40 +0200
Message-ID: <481326C4.2040500@malform.no>
To: John Cowan <cowan@ccil.org>
CC: www-international@w3.org

John Cowan:   ­  
> Leif Halvard Silli scripsit:
> > Technically, when a 'en-GB' tagged file gets acceped by a browser 
> > preferring 'en' tags, then the magic must be happening inside the Web 
> > browser.
> In fact no: *that* magic happens in the server, which sees that the
> document tagged "en-GB" is a partial match for the request "en" and
> returns it in the absence of a document tagged "en".

So, is that a regex kind of match? Meaning that if the server sees a 
request for 'no', then it would send 'no-nyn' or 'no-bok'?

I tested it now, and yes, it seems to be so. When the browser is set to 
prefer simply 'no', then it will send 'no-bok' if that exist, or 
'no-nyn' if that exist. If both exist, then 'no-bok' is sent. Probably 
only because 'bok' comes before 'nyn' in the alphabet. So, quite 
"neutral" positive discrimination of Bokmål ... ;-)

Thus, simply the way servers *work* tells us that the nn,nb,no approach 
is completly foolish.

The BCP 48 says that no-nyn should be a synonym for nn, but that is not 
what it is in Apache then. (And it would not have been of any help if it 

> > So, speaking about eudcation: where shall the education take place, if 
> > we want that 'nn' tagged files shall be served to a browser preferring 
> > 'no'? Is it not the User Agents that needs to learn?
> Yes.

What you said above indicates that servers also must learn.

> > Ok, so we agree that for Norwegian, 'no' is the problem. But then it 
> > seems to me that it is in the *web browsers* that it ought to be close 
> > to impossible to select 'no' as preferred language tag.
> It's all right to make the order no, nn, nb (or no, nb, nn) if you truly
> have no preference at all and are prepared to read either.  I don't know
> if there are any Norwegians that are that bidialectal.

I am. And most are, especially when it comes to *reading* (and hearing). 
(Writing is another matter. Preference is also another matter. Skill as 
well: Nynorsk users are also more used to Bokmål than the opposite.)

But what you say there comes through as somewhat "in the teory".

Most persons have preferences. Most know what they want. Even if you 
know an love both the same, you are not interesting in being an experiment.

The 'no' is not meant for users. It is meant for authors. And that is 
the problem. For instance, Norwegians find it difficult to explain all 
this about Nynorsk and Bokmål. And so 'no' might be an anticipation of 
the the need for forreigners to simply say 'Norwegian'.

> > The Nynorsk order of preferences should be nn,no,nb.
> > The Bokmål order of preferences should be nb,no,nn
> Yes.
> > Ha, perhaps we should even be more drastic and have this order of 
> > preference:
> > 
> >    Nynorsk profile: nn,nb,no
> >    Bokmål profile: nb,nn,no
> I think that last would be a mistake: on bidialectal 

bidialector is the wrong word

> sites that use no instead of nb, you'd get nn instead.

But it is exactly that author behavior we want to avoid. However, you 
have a valid point there.

> > Effectively, for the Nynorsk user, both 'nb' and 'no' would map to 'nn'. 
> > Whereas 'nn' and 'no would map to 'nb' for the Bokmål user.
> Yes.
> > In order to generalise so it is useful not only for the Norwegian 
> > situation, I think that for instance the way Firefox lets me choose 
> > language is meaningless. 
> Well, you can use the low-level interface and be precise.  Go to
> the page about:config and scroll down to intl.accept_languages;
> you can set that to a list of language tags separated by commas.

I see little difference between doing that and using the regular 
language interface of Firefox.
leif halvard silli
Received on Saturday, 26 April 2008 12:58:21 UTC

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