Re: [Ltru] Macrolanguage usage

Comments below.

[snip]

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

I'm writing off nobody based on what language they speak and write.

What I'm saying is that the relationship between no and nn/nb, in terms of
mutual comprehensibility, are not typical of other macrolanguage
relationships, based on conversations with Peter Constable, who played a key
role in the development of the macrolanguage concept. If you have evidence
to the contrary for the other macrolanguages (see all of
http://www.sil.org/iso639-3/macrolanguages.asp), it would be good to bring
that forward.

[snip]

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

Not at all. When filtering for just Cantonese, you absolutely don't want to
get Mandarin content as well, since you would be swamped with irrelevant
results. If you want Cantonese + Mandarin, you should ask for it. When doing
fallback for Bokoto, you don't want to get Gbaya-Mbodomo. If you want Bokoto
OR Gbaya-Mbodomo you should ask for it.

You seem to think of "no-nno" or "no-nob" as a convenient way to get
automatic fallback. Someone might equivalently think that "ro-mol" is a
convenient way to get fallback from Moldavian to Romanian, or that "tl-fil"
is a convenient way to get fallback from Filipino to Tagalog (or "fil-tgl"
for the reverse), or "de-gsw" to get fallback from Swiss German to German,
or any number of other cases. After all, those relationships are far closer
than the vast majority of relationships between macrolanguages and
encompassed languages.

But in practice, having such compound tags complicates matters more than it
helps, as detailed in the document I sent out.

[snip]

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 you are really asking for is for a reasonable fallback strategy that is
likely to get you to a language that you want. After all, exactly the same
situation applies for the Moldavian speaker who would rather see Romanian
than English, and they have no macrolanguage relationship. For that matter,
someone might think that "da-nor-nno-nob" is the answer for them, since they
can understand Danish better than English.

The solution is not to complicate language tags. This is looking in the
wrong place for the solution. What you really want are provided in
LanguagePriorityLists, where you can precisely specify exactly which
languages you can understand, and in what order of preference.

[snip]

I am not surprised that you say so.
> Basically, for English the "remove from right" language fallback
> negotiation method works all the time.

Ad hominem attacks are hardly a way to convince anyone. I've had a
reasonably long career devoted to software internationalization, with
*the*goal being to let people be able to use their languages on
computers no
matter what language. To accuse me or any others on this list of only caring
about English makes me, let's just say, irritated.

Our position on extlang is the result of fairly extensive software testing
of a number of different models of language fallback, filtering, and
matching. In our experience in implementations it causes many more problems
than it solves, and is especially negative for the minority languages, even
more so than the predominant ones. The macrolanguage relationships are
published in the registry, so it is trivial for any implementation to
achieve exactly the same effects as extlang if desired for their
application. (Although as I've said, in general the results would not be
particularly good, because the question of whether A is a good fallback for
B is simply orthogonal to the question of whether A is a macrolanguage for
B.)

If you have implementation experience with a variety of different models --
covering all the combinations with scripts and countries -- dealing with
closely related languages like ro/mo -- and handling both filtering and
lookup -- if you have some basis for your statements, you should bring that
forward, or encourage others to do so.

> --
> leif halvard silli
>

-- 
Mark