Variant subtag proposal: Høgnorsk variety of Norwegian

[Kent Karlsson]

This is getting a bit off-topic; this subthread on locale/localisation
handing certainly has no relevance to the "hognorsk" variant subtag
discussion...



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

> Kent Karlsson, Sat, 02 Jan 2010 12:54:20 +0100:
>> 
>> The case for locale data is a bit different from that of language tagging.
>> If a request for locale data (and by extension, "translation"/localisation
>> of a computer application) is via a macrolanguage code, what is reasonable
>> to do?
> 
> Why perform it via the macrolangage language tag at all?

Backwards compatibility.

> But anyway, I accept that 'no' can contain Bokmål - and only Bokmål for
> that matter. And of course, only Nynorsk as well. I just don't accept
> that a resource tagged as 'no' should be presented as 'Bokmål' to users.

Well, if the "no" resources does contain Bokmål and only Bokmål, then that
should be made clear... But I agree that it should also be clear if one has
chosen "no" or "nb".

>> Should one randomly (at program start, or even for each data item)
>> pick from the entire range of languages covered by the macrolanguage code?
>> While that may give an amusing mixture,
> 
> A piece of work, such as a computer application, should of course
> ideally have a unified style. But such patchwork localization that you
> fear here, is not an issue in OS X.

I do see such mixtures sometimes. Not so much in OS X, though fallback to
English happens for some apps that are not localised. But I've seen
web pages with (for instance) an English sentence with a date formatted
in Swedish (picking up my language preference setting in the browser)
injected into it...

> In OS X, if your language preference is set to Swedish, then if a
> particular application only exists in the Finland Swedish variant and

There are no spelling (or grammatical) differences between "Swedish Swedish"
and Finlandish Swedish (unless you try to write down actual pronunciation in
say IPA, but I have seen no UI do that...). There are (dialectal)
pronunciation differences...

> thus perhaps contains a localization resource tagged as 'sv_FI', then
> you will get the application in Finland Swedish interface and not in
> English or whatever. There is no user interface that lets you say no to
> Finland Swedish, as long as you have accepted Swedish. The only way out
> is to manually disable the particular localization directly for that
> particular application.
> 
>> it does not seem to be a reasonable
>> way of dealing with this case; it would also need extra machinery for the
>> randomisation. Instead one manually preselects one of the encompassed
>> individual languages. So for "no" it is reasonable to preselect "nb" data,
>> since "nb" (at present) is more often used than "nn".
> 
> I would have preferred that 'nb' was treated by the OS as if it was
> encompassing 'no' - meaning that if no 'nb' resource is available, then
> a possible 'no' resource is the next priority. 'nn' could likewise be
> treated as if encompassing 'no' as well, since this is expected by most
> of the 'nn' users. I realize that this would lead 'nn' users to receive
> many resources in Bokmål.
> 
> This is not any very technically tricky at all. All the resources are
> there, in OS X. I is just a tagging/classification question.

What you are talking about here is called fallback. And OS X has its own
way of handling fallback: you give your personal fallback list as a system
preference setting. In CLDR there is also a fallback list, that one can use
if there is no personal fallback list. For "nn" that list is "nb da sv en";
see http://unicode.org/cldr/apps/survey?_=nn&x=misc (note: "no" is simply
aliased to "nb"). But in OS X there's the personal list instead. I don't
really see how one could combine those approaches without creating a mess.

> I don't complain that 'en' resources in Mac OS X, from Apple's hand are
> filled with US English content and that it is presented as 'English' -
> no more or less - to the users. But I would complain if these 'en'
> resources with US English content were presented to users as 'US
> English'.

That content is a bit of a problem, since most users of English use
something closer to British English, though it is spread over many
countries several of which are not as "computerised" as the US.

But for "naming the content" it should be made clear that it is US
English *and* whether one has chosen "en" or "en_US".

> Or, if 'sv' was presented to OS X users as "Swedish Swedish".

Well, "Swedish Swedish" looks a bit redundant; I know what you mean
by "Swedish Swedish", but most users would find that a less than
desirable presentation... But that is a different issue of course.

> In OS X, Finland Swedish does have the choice of using 'sv'. British
> English does have the choice of using 'en'. But since 'no' is presented
> to users as 'Bokmål' (despite that 'nb' is also in simultaneous use),
> Nynorsk resources have a very high barrier against using the 'no' tag -
> as it will literally be presented as 'Bokmål'.

    /kent k