Variant subtag proposal: Høgnorsk variety ofNorwegian

Leif Halvard Silli xn--mlform-iua at xn--mlform-iua.no
Sun Jan 3 17:34:01 CET 2010


Randy Presuhn, Sat, 2 Jan 2010 20:51:28 -0800:
>> From: "Leif Halvard Silli" Saturday, January 02, 2010 4:51 PM

>> Unless 'nn-hognorsk' breaks my application, then 'no' isn't as sensible
>> as prefix as 'nn' is. But if 'nn-hognorsk' breaks my application, then
>> 'no' is a sensible alternative prefix.
> 
> No, it is not.  The point of using language tags in the manner of BCP 47
> is *interoperability*.   From that perspective, tagging material with
> 'nn-hognorsk' will exhibit far better matching / filtering properties.

Would you say that 'interoperability' doesn't cover '(backward) 
compatibility'?

If it does cover compatibility, then interoperability was behind what I 
said. 'nn-hognorsk' doesn't work in Mac OS X 10.4. I believe 
'no-hognorsk' would work. Also, in content negotiation 'no-hognorsk' 
could work better than 'nn-hognorsk' just as 'no' sometimes works 
better than 'nn'.

It doesn't usually hinder interoperability to say 'en-scotland' instead 
of 'en-GB-scotland' either. I agree with Doug that there are legitimate 
reasons to consider using 'no' over either 'nn' or 'nb'. And in that 
light I don't see that 'no-hognorsk' hinder interoperability anymore 
than 'en-scotland'.

>> For instance, I may need to discern between 'nn' and 'nn-hognorsk', but
>> something breaks so it that 'nn-hognorsk' doesn't work as expected. In
>> a given, practical situation, I could decide to reserve a bare naked
>> 'no' for Høgnorsk. So then I don't understand why one can't state that
>> it then would be perfectly sane to use 'no-hognorsk' as well.
> 
> The problem is that 'no' does not mean "Høgnorsk".  It means "any kind of
> Norwegian".

Problem and goodness.

>  There are times when this is useful and sufficient, as
> in the case of a collection which contains Norwegian material, but lacks
> a tagger with any knowledge of that language.  Using 'no-hognorsk' would
> *not* foster interoperability.  It's a kludge that might do what you want
> it to within the context of a particular (arguably broken) system, but
> not something that should be encouraged, since it would impair 
> interoperability.

I don't see that 'no-hognorsk' hinders interoperability. Instead - in 
the ocean of 'no' tagged material covering both Nynorsk and Bokmål, the 
'no-hognorsk' tagged material would stand out - it would be simple to 
separate it out when needed. Only if 'no' and 'nb' should be treated as 
equal would it make sense to me that 'no-hognorsk' hinders 
interoperability.

 Of course, if the system supports 'nn', then it is likely that a 
Høgnorsk resource would be better off being tagged as 'nn-hognorsk', to 
experience the benefits linked to the 'nn' locale. However, this 
depends: In Mac OS X the benefits have so far not been enough for me to 
be wanting to use 'nn' instead of 'no'.

As for search engines, then 'nn-hognorsk' would probably be beneficial 
to use. But it would be a peace of cake for search engines to link 
'no-hognorsk' to 'nn' as well.

Therefore I would like to explicitly link the choice between 
'no-hognorsk' and 'nn-hognorsk' to the same kind of general 
considerations as the choice between 'nn' and 'no'.
-- 
leif halvard silli


More information about the Ietf-languages mailing list