Re: [Ltru] I'm really confused by chinese in 3066bis

[Leif Halvard Silli <lhs at malform.no>]

Debbie Garside 2008-05-10 22.12:
> Subtag: cmn
> Type1: language
> Type2: extlang
> Macrolanguage: zh

Instead of setting a number after the Macrolanguage field,

    Macrolanguage: zh;1

which it seems as if you have dropped anyhow, I would instead propose, 
building on Addison Phillips idea about a Encopassed field, to simply 
insert the Encompassed languages in a **particular order** - or at least 
place the dominant and second most dominant language first:

    Subtag: zh
    Type: language
    Encompasses: cmn, yue, wuu, etc.
      

Omitting the numbers has the advantage of not ranking the languages with 
a number. It also has the advantage of perhaps giving implementors the 
clue that 'cmn' can only be assumed to be number 1 as long as the 
application itself is localized into 'cmn'.

For a user of Cantonese, the default starting point shouldbe 'yue'. 
Thenafter it should go to the left and lookup 'cmn'. Thenafter either 
one of the other Encompassed languages - or a third langauge. (The issue 
of simplified versus traditional Chinese complicates even further, of 
course.)

To explain better what I mean, let's imagine that the encompassed 
languages had numbers instead of alphabetical codes - and imagine that 
the number '0' = macrolanguage. Thus for Chinese 0 = 'zh'. Then, for the 
dominant language within a macrolanguage, we would get this priority order:

    10, 2, (3, 4)
      

Note that '10' stands for 'cmn' (1) + zh' (0). It should check for 'cmn' first, but at the same time consider 'zh' as part of 'cmn' if 'cmn' is unavailable.

Then I would suggest that if the localisation of for instance the Web browser is the Encompassed language number 2, then browser should assume this *default* order instead:

    20, 1, (3, 4)

Again 'yum' (2) and 'zh' (0) are concatenated into 20.

Wheras an applications localized for Encompassed language 4 should 
rather assuem this default order:

    40, 1, (2, 3)

The paranthesis is meant to indicate that it is lesser certainity about 
whether the users actually would appreciate those languages in the 
fallback order.

Because, users of Encompassed language 2, 3 and 4 would probably all of 
them want to also include encompassed language number 1 as part of their 
fallback scheme. Thus a user of an Encompassed languages which isn't the 
dominant language, would normally want at least 3 codes as part of their 
lookup: the particular language itself, the macrolanguage and the 
dominant language. Their preference _after_ those 3 codes, is a bit more 
difficult to say anything about.

The users of dominant language, though, often requires perhaps would 
want dominant language, macrolanguage and often also the second most 
popular language. Thus, like this:

    10, 2, (3, 4)

Although users of a dominant language may sometimes prefer to set an 
paranthesis around all the Encompassed languages, except their own:

    10, (2, 3, 4)

I think it is important that the macrolanguage, 'zh' for instance, is 
not always assumed to be the dominant language. I.e. 'cmn' should not 
always be considered #1 within 'zh'. Doing so would only make the link 
between 'zh' and 'cmn' stronger. That link should only be made when the 
'zh' application actually is a 'cmn' application. If the localisation 
actually is a 'yum' applcation, then 'zh' should primarely be associated 
with 'yum'.

The twist is, that even if 'yum' gets associated with 'zh', then users 
would still - for example in the Web world - for the most part receive 
'cmn' content. But that is fine. That is what the users expect.

Questions to you: Do you agree that the above is a useful way of 
deciding fallback based on macrolangauge information? Or do you find 
anythign of this questionable? Localizers must of course always judge 
thing carefully, but to me the above seems sensisble, if I may say so.

If you agree with my thoughts here, then I hope it somehow can be 
incorporated into the RFC.


(I just  had to get this of my chest. I'll read mail tomorrow.)
leif halvard silli
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru