[Ltru] Re: extlang

[John Cowan <[e-mail]>]

Mark Davis scripsit:

> Not single-handedly: Addison has also commented on it. 

AFAIK he has acquiesced in, but not defended, your position.
(I may be wrong.)

> And on the other side, I've heard 3 strong proponents. So not exactly
> overwhelming either way.

FWIW, I have heard privately from several normally active listmembers
supporting my position.  I assume that you know I wouldn't lie about this.

> I've said before, and will say again: it was never a foregone conclusion. 

I have never said so.  I do say that it is the status quo, and it's
a change to the status quo that requires defending.

> Do I really have to repeat this over and over????

Alas, we do seem to be looping.  I wish I saw the way ahead.

>    1. The macrolanguage is always a better fallback for every encompassed
>    language than other alternatives. Out of the many encompassed languages, you
>    implying that a speaker of every encompassed language will be able to
>    understand the macrolanguage, or at least better than the alteratives.

RFC 1766 already said that fallback doesn't always work, and sometimes
produces something unintelligible to the requester.

But I believe you are misusing the term "macrolanguage".  A macrolanguage
is not to be equated with a "main" or standardized variety.  Some
macrolanguages like Chinese and Arabic have such varieties, others like
Quechua and Nahuatl do not.

Rather, a macrolanguage is a group of languages that *in some domain*
is recognized as a single language.  By definition, if you speak
Sudan Arabic, you are speaking something that is part of the Arabic
macrolanguage, even if you cannot speak modern standard Arabic at all.
Thus it may be empirically sound to assume that anything (or at least
any text) tagged "ar" is in MSA, it is not certain.

>    1. Truncation fallback from zh-cmn-Hant-SG to "zh" loses the Hant and
>       the SG; falling back from ar-arb-SA to 'ar' loses the "SA".

So it does.

>       2. It introduces ambiguous language names. Right now, in the
>       overwhelming majority of practice, standard Arabic is "ar"; after the
>       change, standard Arabic is "ar-arb".

You propose in the alternative that "ar" and "arb" both be understood
as modern standard Arabic.  I submit that that is worse.

>    1. Anyone who has to deal with language issues on all but a trivial
>       level must already have a mechanism to deal with sh, sr, hr;
>       with no, nb, nn. Those are macrolanguages and encompassed
>       languages. They exist right now WITHOUT an extlang mechanism,
>       and people deal with them. The proposed mechanism won't handle
>       these, and anyone who can handle these doesn't need extlang.

True, but not everyone does.  As I have said before, the majority of
language-sensitive applications, I believe, deal only with recognizing a
short list of languages that they know what to do with, and all others
have the semantics of "unknown language".  It's perfectly compliant
just to look at the first subtag, decide if it is 'en', 'fr', or 'ar',
and throw away all other information; furthermore, I believe this to
be typical.  Most applications just don't involve processing almost
every document known to man.  I want this sort of application to continue
to work without having to be modified to add "arb" as a fourth alternative.

>       2. With the Macrolanguage field, there is sufficient information
>       for *anyone* who wants to to implement extlang-like fallback
>       (including for sh or no), *without* encumbering the IDs with
>       superfluous information.

I support the Macrolanguage: field for the uses which you mention.
Furthermore, I support extlangs *only* in the context of using newly
introduced 639-3 identifiers that are encompassed by a macrolanguage
registered in 639-2.  Thus, I do *not* support changes to language
tags based on shifting macrolanguage information as SIL learns more,
just the 350+ specific code elements of 639-3, and no more.

> This is untrue. As soon as we implemented extlang in prototype, we ran into
> the problems listed above. It *didn't* work out of the box.

I can well understand that in certain applications having an unusual
breadth of scope, both in the matter of documents and in the matter
of languages, that it might well not.

-- 
Dream projects long deferred             John Cowan <[e-mail]>
usually bite the wax tadpole.            http://www.ccil.org/~cowan
        --James Lileks


_______________________________________________
Ltru mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ltru