Subject: [Ltru] Re: no teleconference this week

From: "Doug Ewell" <[email-masked]>
Date: Tue, 4 Dec 2007 20:41:48 -0800

Mark Davis <mark dot davis at icu dash project dot org> wrote:

> We can close the telecon down, if we don't think that it would be 
> useful in clarifying and finishing off the remaining items.

Is there still talk of opening up 4647 to add something about the 
Macrolanguage field and its potential use in matching?

(not arguing for or against)

--
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 4 Dec 2007 20:51:02 -0800

If we wanted to do the minimum, we'd put at least a note in 4646bis about
the potential use of the macrolanguage field, with some cautions (something
like a very limited version of the text I'd proposed for 4647bis);
alternatively, I put the latter text out on the table, and could make a
4647bis draft on that basis (as modified during subsequent discussion -- I'm
not wedded to that exact text).

What do people think?

Mark

On Dec 4, 2007 8:41 PM, Doug Ewell <[email-masked]> wrote:

> http://home.roadrunner.com/~dewell <http://home.roadrunner.com/%7Edewell>

-- 
Mark

---

From: Addison Phillips <[email-masked]>
Date: Tue, 04 Dec 2007 20:56:07 -0800

There is already a note in 4646bis about Macrolanguage. Perhaps take a 
look at it and comment directly on the text?

Addison

Mark Davis wrote:
> If we wanted to do the minimum, we'd put at least a note in 4646bis 
> about the potential use of the macrolanguage field, with some cautions 
> (something like a very limited version of the text I'd proposed for 
> 4647bis); alternatively, I put the latter text out on the table, and 
> could make a 4647bis draft on that basis (as modified during subsequent 
> discussion -- I'm not wedded to that exact text).
> 
> What do people think?
> 
> Mark
> 
> On Dec 4, 2007 8:41 PM, Doug Ewell <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <http://home.roadrunner.com/%7Edewell>
>     <http://www1.ietf.org/html.charters/ltru-charter.html>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
> 

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 4 Dec 2007 21:21:35 -0800

> look at it and comment directly on the text?

I assume this means the three paragraphs near the bottom of Section 4.1. 
I think this text is really the best we can do to capture the intent of 
the WG.  Anything more specific will raise more questions than it 
answers.

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.

---

From: Addison Phillips <[email-masked]>
Date: Tue, 04 Dec 2007 21:34:25 -0800

Doug Ewell wrote:
> the WG.  Anything more specific will raise more questions than it answers.

Exactly so. I think this is best.

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

It might be nice to revise 4647 to specifically deal with Macrolanguage 
information and the like. However, I think we can have tutorials or text 
published on the general problem of language negotiation separately (I 
certainly intend to help revise the one at W3C!) and this will allow us 
to finish this work sooner rather than later. Since the algorithms are 
unaffected by the editorial changes suggested, I would think we could 
deal with Macrolanguage in the section in 4646bis on tag/range choice as 
a suitable workaround.

Best Regards,

Addison

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 4 Dec 2007 21:51:26 -0800

Fine by me.

---

From: "Doug Ewell" <[email-masked]>
Date: Tue, 4 Dec 2007 22:54:34 -0800

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

---

From: Shawn Steele <[email-masked]>
Date: Wed, 5 Dec 2007 00:44:22 -0800

> everyone to ignore it anyway and stick with remove-from-right.

If we expect people/systems to correlate cmn-HK and zh-HK, which seems somewhat useful to me, then I don't think we can stick with remove-from-right.
I can't change the OS's UI language to cmn-HK if the legacy apps are all tagged with zh-HK resources.  OTOH, if I want to encourage good behavior, then I have to change the UI language.  I can't expect everything to be rebuilt though, so I need to make the correlation somehow (which is why I like zh-cmn-HK :))

- Shawn

---

From: Martin Duerst <[email-masked]>
Date: Thu, 06 Dec 2007 16:27:42 +0900

At 14:21 07/12/05, Doug Ewell wrote:
>> There is already a note in 4646bis about Macrolanguage. Perhaps take a look at it and comment directly on the text?
>
>I assume this means the three paragraphs near the bottom of Section 4.1. I think this text is really the best we can do to capture the intent of the WG.  Anything more specific will raise more questions than it answers.
>
>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.

A really cheap way out would be to put the necessary language in
RFC 4646bis, and leave RFC 4647 alone. Just an idea, probably not
a very good one, it depends on the exact text that's needed.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 6 Dec 2007 21:16:36 +0100

> a very good one, it depends on the exact text that's needed.

I like "KISS".  In that case 4646bis should get an "updates 4647".

 Frank

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 6 Dec 2007 06:57:32 -0800

Martin Duerst <duerst at it dot aoyama dot ac dot jp> wrote:

> A really cheap way out would be to put the necessary language in RFC 
> 4646bis, and leave RFC 4647 alone. Just an idea, probably not a very 
> good one, it depends on the exact text that's needed.

It might be that the new text in Section 4.1 is all we need to say, or 
can say.