Re: [Ltru] extlang

Hi -

As a technical contributor...

> From: "Mark Davis" <mark.davis@icu-project.org>
> To: "John Cowan" <cowan@ccil.org>
> Cc: "LTRU Working Group" <ltru@ietf.org>
> Sent: Tuesday, August 28, 2007 2:59 PM
> Subject: [Ltru] extlang
...
> You are not revealing some important hidden assumptions in your statements.
> 
>    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.

I don't see how the use of extlang would require this as an assumption.
Making such an assumption seems a bit like assuming that all languages whose
tags begin in "a" are somehow related.

>    2. People don't lose anything by having the fallback. I dispute this
>    as well. As previously noted:
>    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".

It is the nature of truncation fallback to lose information.  No matter
what order the subtags are trimmed off, someone will be able to argue
that for some particular case, a different order might have been better.
This isn't an argument against extlang; it's an argument against unrealistically
high expectations for truncation fallback.

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

This would not be desirable.  However, I wonder whether the semantic associated
by most taggers and users of tags with "ar" is "standard Arabic" or merely "Arabic".

>    3. People can't get along without this.
>    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.

I think this argument is flawed in that it neglects the cost of supporting
such constellations of languages.  There are already some messes that we're
stuck with, and that have to be handled in an ad hoc manner.  This doesn't
justify requiring ad hoc handling for every other such constellation of
languages.

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

This would be a compelling argument, if fallback were the sole reason for extlang.
However, fallback is not the sole motivation for extlangs; they are also
of use to taggers with incomplete knowledge of the languages used in the
materials they are tagging.  The library staff in my home town would be
doing well if they correctly recognized material as "zh" or "ar".  It would
be quite unrealistic to expect them to be any more precise.

Of course we'd all like everyone who has to tag material to have perfect
knowledge of the languages involved so that tags with sufficient precision
and accuracy would be used.  But we also know that in reality people work
with incomplete knowledge.  Consequently, I think we should allow people to
who by necessity tag with low precision to nonetheless do so accurately.

> > >    2. it is sufficiently better to warrant making the language tags more
> > >    complicated by the addition of this mechanism.
> >
> > Language tags become more complicated *if* it is desired to make them
> > so.  Those who find "zh" sufficient may continue to use it while still
> > interoperating with "zh-cmn", "zh-yue", and so on.  Existing deployed
> > matchers will continue to work, as will existing deployed software
> > that understands specific tags; they will not need to become more
> > complicated to understand the out-of-band relationship between "zh",
> > "cmn", "yue", etc.
> 
> 
> 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'm missing something.  Precisely what scenario was it that was expected to
work that did not?

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru