Variant subtag proposal: Høgnorsk variety ofNorwegian

[Leif Halvard Silli]

Kent Karlsson, Sun, 03 Jan 2010 18:07:33 +0100:
> Den 2010-01-03 17.34, skrev "Leif Halvard Silli":
>> 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.

With the 'subtag', no. But with the 'tag', there is. I would like to 
construct a tag made up of subtags that results in a good result.

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

Again, I feel like saying the same to you.

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

There is no reason to make any extra effort to also support 
'no-hognorsk'. As long as the system also supports 'no', then it will 
most likely also support 'no-hognorsk'. Also, applications may be made 
compatible with several systems - some of which includes support for 
e.g. 'nn-hognorsk', and some of which do not.

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

Disagree. They are practically very related. But I know that you 
consider macrolanguage just a collection tag. Our views on 
macrolanguages and extlang are diametrically opposite. 

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

Again there is. If 'hognorsk' existed when I localized iCab for OS X, 
then it is not unlikely that I would have used 'no-hognorsk'. It is 
entirely certain that I would not have used 'nn-hognorsk'. And it may 
/still/ be the case that I would not use 'nn-hognorsk' on Mac OS X.

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

BCP47 mentions that 'zh' may be expected for Mandarin. That mention is 
based on experience/knowledge about specific systems.
-- 
leif halvard silli