Re: [Ltru] Macrolanguage usage

Mark Davis 2008-05-20 22.44:
> On Tue, May 20, 2008 at 5:20 AM, Leif Halvard Silli <lhs@malform.no> wrote:
>
> > Mark Davis 2008-05-16 23.15:
> >
> >> Yes, clearly. Although even that takes time and effort to do; there is no
> >> magic wand. (As I've said, the addition of non-predominant encompassed
> >> language subtags like "yue" is important and useful for us. The addition
> >> of
> >> the predominant encompassed language subtags just means a lot of work for
> >> no
> >> additional benefit to us or our users.
> >>
> >
> > Sad to hear a Google representative speak like that. Because it does add
> > benefit to your users. Macrolanguage information represents reality - it is
> > not just teory.
>
>
> Actually no. According to everything I've heard, the macrolanguage was
> devised as a construction which is an attempt to rationalize inconsistent
> approach to languages used by previous versions of ISO 639. It does not
> represent any particularly reality beyond that. As said before, whether two
> languages are closely related or not is pretty much orthogonal to whether or
> not they share a macrolanguage: ro and mo are examples.
>
> You appear to be generalizing from the case of no, nn, nb to all
> macrolanguages.
>   

When this group first has one member which speaks and writes as minority 
encompassed language of a Macrolanguage, then it is of course best to 
write him off.

So, why do you think ISO 639-1 is inconistent? By accident?

The inconsistencies of ISO 639-1 are very much based on reality.

> >  We could remain silent on this issue in the spec, but that would just be
> >> withholding useful advice for people in terms of "tagging wisely", advice
> >> that would allow people to interoperate more effectively.
> >>
> >>
> >
> > As long as you are not silent on the issue that 'zh' equally well can be
> > used for Cantonese, then pleas also tell that it can be used for Mandarin.
> > Both things are true and must be stated - not hidden.
>
>
> My opinion, and I've hardly been quiet on the issue, is that for a large
> class of implementations it is best for backwards compatibility to continue
> to have resource lookup map 'ar' to Standard Arabic, 'zh' map to Mandarin,
> and so on, and use the new codes for other languages, eg 'yue' for
> Cantonese. And the text of draft #14 allows that possibility, which is after
> all perfectly legal. If you choose to map 'zh' to Gan in your resource
> lookup, be my guest.
>   

This is hiding facts. You can have that opinion that 'zh' is best for 
Mandarin.

But you should not hide that 'zh' is perfect for Cantonese as well. It 
is the best choice for Cantonese, if you want backward compatibility.

In fact, the best thing is the opposite of what you say.

The mayority has lots of power. The minority gets ignored. THerefore, be 
careful so you not destroy what the minority rely on, because the 
minority is the last ones to be handled. They will receive web browsers 
with support for the new Cantonese tag much later than the Mandarine 
users will get the same tag. (Not to speak about web pages using those 
tags.)

I must again generalize based upon my experience as minority extlang 
user:  In Mac OS X "Leopard" Apple introduced support for "Nynorsk". But 
in a way that dissassociated it from "Norwegian". So, because Norwegians 
often are of the kind that "either Nynork or Bokmål", if I disseleect 
support for Bokmål, then my applicatinos will launch in English instead 
of "Norwegian" - or, if you wish, Bokmål.

And in my view, this "Leopard" solution for Nynorsk is exactly what you 
propose for Cantonese.  What you propose would, in a very likely worst 
case, cause that selecting Cantonese leads the user to get English 
instead of Mandarine when Cantonese is lacking.

> >  > What happens for other language tags that change?  Like serbian (serbian
> >> > remains the same, but data tagged at the region level will change.)
> >>  Needing
> >> > to support zh + cmn isn't that different than other common scenarios.
> >> >
> >>
> >> Right, I've been saying all along that this is the same issue with any
> >> predominant encompassed language.
> >>
> >>
> >
> > As it is the same issue as with any predominant region variant of English,
> > for instance.
>
>
> I have no idea what you mean by this.
>   

I am not surprised that you say so.

Basically, for English the "remove from right" language fallback 
negotiation method works all the time.
-- 
leif halvard silli
_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru