Variant subtag proposal: Høgnorsk variety of Norwegian

Leif Halvard Silli xn--mlform-iua at xn--mlform-iua.no
Sun Jan 3 18:49:37 CET 2010


Kent Karlsson, Sun, 03 Jan 2010 11:29:28 +0100:
> Den 2010-01-03 04.12, skrev "Leif Halvard Silli"
>> 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.

It was for backwards - and forwards - compatibility that I said that 
'no' should be presented to users as 'Norwegian' - the way it was in 
version 10.4. Nynorsk applications labeled as 'no' in 10.4 shouldn't 
suddenly appear with the label 'Bokmål' in 10.5.
 
>> 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 [...]

Since you want to debate the example instead of the point:

Some words are chiefly Finland Swedish - I've heard Swedish Finns 
rejoice for having gotten particular words into  the standard Swedish 
dictionary. Preferred wording/way of putting it may also differ - and 
the Finland-Swedish localizer could be wanting to take a more "from 
scratch"/purist approach - instead of relying on common Swedish 
localizations. (E.g. because choosing chiefly Finland Swedish wording 
could give Swedish higher credibility within Finland.)

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

If fact, in OS X 10.4, when things were labeled 'Norwegian', then both 
'nb' and 'no' were  supported - and put under the 'Norwegian' label.

> And OS X has its own
> way of handling fallback: you give your personal fallback list as a system
> preference setting.

Yes. And no. Choosing 'no' when 'nb' isn't available is fallback, yes. 
Choosing 'nb' when 'no' isn't available is better labeled as using 'no' 
as an alias for 'nb'. Unfortunately OS X seems to be treating 'no' as 
an alias for 'nb'. Thus, only on the surface is OS X 100% governed by 
user preferences in this regard.

If the issue of 'nb' vs 'no' vs 'nn' instead were to _really_ be 100% 
solved via the personal preference system , then it would be entirely 
possible to put both Norwegian, Norwegian Nynorsk and NOrwegian Bokmål 
- 3 options - in the OS X configurations panel. And to, in addition, 
guide users to _please_ not unselect 'no' - regardless of their 
preference for 'nn' or 'nb'. (It should probably be impossible to 
select 'no' as the only localization without simultaneously selecting 
either 'nn' or 'nb'. But it could be possible to deselect 'no' once 
either 'nn' or 'nb' had been chosen.)

In OS X the choice of locale also directly affect the content 
negotiation. 

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

Hm. Indeed: http://unicode.org/cldr/apps/survey?_=no&x=misc

Thanks. Looks as if I need to file a bug report with that thing as well.

The CLDR system could work, however, because the fallback for 'nb' 
includes 'nn' and the fallback for 'nb' includes 'nn'.

http://unicode.org/cldr/apps/survey?_=nb&x=misc

But that is not how OS X works, unless the users actively sets it up 
like that.

However, even the CLDR system would not cover the issue that I took up, 
where 'no' is presented as 'Bokmål' to the user.  The CLDR system would 
work better if it instead of treating 'no' as an alias for 'nb' would 
say that the first fallback option for 'nn' is 'no' and the first 
fallback option for 'nb' is also 'no. There should be zero degradation 
in anyone's user experience from this. Instead it would increase the 
user experience of some.

This doesn't mean that I support that 'no' should be recommended as a 
locale - I support that 'nn' and 'nb' are the recommended locales. I 
just say that 'no' should be included in the fallback scenario for 
either. 

Btw, here is a Weather Forecast web site which uses 'no' on the front 
page (because it uses places mixed Norwegian content there), while it 
uses 'nn' and 'nb'  - and gives users the ability to choose  - on on 
the sub pages: http://www.yr.no

> 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 really see the problem you see. I instead see that you think 
macrolanguages are bad and that you want to limit them even more than 
BCP47.

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

Not sure I understand where you want. I am satisfied with how it works 
for English.

In OS X there is strong link between content negotiation and 
localization. If you were to select "US English" as your preferred 
language (you can do that), then it would signal that you do not want 
"British English" content. It could be very confusing, considering the 
way OS X otherwise works, if you could select "US English" but still 
get "British English". 

However, it would not be confusing for Norwegians, that you can select 
Bokmål and "still" get Norwegian ... 

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

We may not agree about what is different and same ... 

>> 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'.
-- 
leif halvard silli


More information about the Ietf-languages mailing list