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