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