Variant subtag proposal: Høgnorsk variety ofNorwegian

[Kent Karlsson]

Den 2010-01-03 17.34, skrev "Leif Halvard Silli"
<xn--mlform-iua at xn--mlform-iua.no>:

> 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'?

"hognorsk" is a new sbtag, so there is no backwards compatibility issue
with it.

> 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'.

Again, this is not relevant to the request to register "hognorsk".
The backwards compatibility issue I mentioned does not lay where
you think it does. It's got to do with users having chosen "no"
and stays with that. If someone chooses "høgnorsk" ("nn-hognorsk)
there is no reason to also have to support "no-hognorsk".

Also, the LSR is about language tagging. Locale identification
is a spinnoff, not the other way around.

> 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'.

This example does not involve macrolanguage codes/primary subtags at all,
and has completely different mechanisms.

>>> 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.

I agree with Randy that it does.

> 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.

Again, if tagging/retagging material known to be in Høgnorsk, there is
no reason whatsoever to use no-hognorsk.

>  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'.

This is specific application localisation system, that may have it's own
quirks (bugs if you like), but that is not relevant for the LSR.

> 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.

Why complicate it this way?

> 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'.

I agree with Randy and Michael that that would be a bad idea.

    /kent k