Re: [Ltru] Re: no teleconference this week

Addison Phillips <addison at yahoo dash inc dot com> wrote:

>> I'm opposed to spending time on a revision of RFC 4647, since we 
>> expect everyone to ignore it anyway and stick with remove-from-right.
>
> I'm completely mystified by this statement, which you've made several 
> times already. I don't at all expect that 4647 will be ignored. Quite 
> the contrary. However, "remove-from-right" *is* the heart of the 
> algorithms described in that document. Removal of extlang means we 
> don't have to modify the actual algorithms to do other than RFR. Or 
> did I miss something?

Remove-from-right is, indeed, the essence of basic filtering and basic 
lookup.  However, if RFR were all there was to it, we wouldn't have 
bothered creating a separate matching document that wasn't on the 
original LTRU 1.0 charter.  We would have covered matching within 4646, 
just as Harald did in 1766 and 3066.

But with the advent of script subtags, and the expectation of ISO 
639-3-based extlangs, we felt something more was needed.  John Cowan 
came up with the idea of "scored matching," which disassembled the tag 
and assigned point values to individual subtags, and this led to 
extended filtering, in which wildcard asterisks take the place of 
optional subtags.  These algorithms are *not* primarily based on RFR; 
they allow for possibilities like "hi-Deva-IN" matching "hi-IN", and 
they would have provided additional flexibility in matching "zh-yue" 
with "zh".

However, during the recent extlang debate, almost the entire focus was 
on whether extlangs would behave well in the presence of basic filtering 
and basic lookup.  Even John Cowan, in throwing in the towel, emphasized 
this:

"The strongest argument against extlang tags is that our simple 
remove-from-right lookup algorithm ends up losing too much information. 
If you ask for 'zh-yue-Hant', and there are no Cantonese resources, then 
by the time you have truncated the tag to just 'zh' you have forgotten 
that Traditional Han script was required."

Not necessarily if you use extended filtering.

"In order to prevent it, we would have to change 4647 to specify a 
sequence like zh-yue-Hant > zh-yue > zh-Hant > zh, where the extlang tag 
is treated magically; in essence, stripping it restores all other tags."

The way I read 4647, section 3.3.2, extended filtering would give you 
two options:

- "zh-*-Hant" would yield zh-yue-Hant > zh-Hant > zh
- "zh-yue-*" would yield zh-yue-Hant > zh-yue > zh

Which one you choose would depend on whether "Cantonese" or "Traditional 
Han" is more important to you.  This is no different from requesting 
"sr-Latn-ME" with the understanding that, if this exact combination is 
not available, a choice must be made as to whether "Latin script" or 
"Montenegro usage" is more important.

"That would be fine, except that no one actually does it or is likely to 
for some time to come."

And that is the crux: we don't expect people to take advantage of the 
advanced features of RFC 4647.  Meanwhile, the basic features of 4647 
are little changed from (though much better explained than) what we had 
in 3066.  Thus my claim that, by expecting people to stick with blind 
RFR, we are expecting them to ignore 4647.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://home.roadrunner.com/~dewell
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

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