Variant subtag proposal: Høgnorsk variety ofNorwegian
Leif Halvard Silli
xn--mlform-iua at xn--mlform-iua.no
Sun Jan 3 20:03:39 CET 2010
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)
> "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
More information about the Ietf-languages