Re: WG meeting at Vancouver IETF?

Hi -

As co-chair -

I believe we have a rough consensus to *not* request an ltru WG
session at the Vancouver IETF meeting.  So, everybody, PLEASE
recouble your efforts to wrap up the remaining issues.

Randy

teleconference information...

Hi All,

We had a teleconference last week as a kick-off. We'll be holding a 
follow-on call this week, on Wednesday 3 October 16:00 UTC.

Time: 9:00-10:00 Pacific Daylight Time
USA Dial-In #:+1.888.371.8922
International Dial-In #:+1.617.224.4792
Participant Passcode: 58371972

Addison

--

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

Internationalization is an architecture.
It is not a feature.

Summary of 2007-10-03 teleconference

Hi -

There was a teleconference to discuss remaining open issues in
the ltru drafts this morning.  I volunteered to serve as scribe.
I hope I got it right.  If I didn't, I'm sure someone will
correct me.  In any case, let's see if we can finish this discussion
by working through the tradeoffs and agreeing on something, since
it's pretty clear at this point that neither approach is perfect.

The primary topic of discussion was the question of what to do
about macrolanguages and extlangs.  The two major alternatives
both had implications for matching.

There was general agreement that remove-from-right matching is not
a panacea.  There was less agreement about whether a macrolanguage-
extlang construct is ever helpful, or actually counterproductive,
in its interactions with matching.

One consequence of the "flat" approach (not including encapsulating
subtags in a language tag encoding) is that more intelligent matching
would require additional information from the registry, which would
increase the risk that someone might build applications that would
read the registry, presenting a possible DoS with respect to IANA.

There was some disagreement about what is meant by a macrolanguage
subtag by itself.  Two examples: does zh mean the same thing as zh-cmn,
and does ar mean the same thing as ar-arb?  A *rough* consensus
of those participating in the teleconference (this must not be
understood as a determination of WG consensus) was that they mean
different things.  In this view, "zh" means "undifferentiated Chinese"

Clarifying Suppress-Script

Hi -

Based on recent discussion on the ietf-languages <at> iana.org list,
as a technical contributor I think we should clarify section 3.1.8
in the current draft by adding the following paragraph to that section:

  Suppress-Script is a compatibility measure, and as such is
  only appropriate for languages whose subtags were added to
  the registry before RFC 4646 was approved.  Even for such
  languages, Supress-Script SHOULD NOT be used unless there
  exists a significant body (as determined by the Language
  Subtag Reviewer) of material tagged before the approval of
  RFC 4646 without a script subtag.

Thoughts?

Randy

Re: Clarifying Suppress-Script

Randy Presuhn scripsit:

>   Suppress-Script is a compatibility measure, and as such is
>   only appropriate for languages whose subtags were added to
>    the registry before RFC 4646 was approved.

+1

>   Even for such
>   languages, Supress-Script SHOULD NOT be used unless there
>   exists a significant body (as determined by the Language
>   Subtag Reviewer) of material tagged before the approval of
>   RFC 4646 without a script subtag.

Neither the LSR nor anyone else (not even people who work for
search-engine companies) is in a position to make any such determination.
Not all tagged material is open to public scrutiny.  I am therefore
opposed to adding this sentence.

--

-- 
With techies, I've generally found              John Cowan
If your arguments lose the first round          http://www.ccil.org/~cowan
    Make it rhyme, make it scan                 cowan <at> ccil.org
    Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie

RE: Clarifying Suppress-Script

Hi,

I object to this whole paragraph.  Because RFC 4646
*inserted* scripts between the two previously main
subtags (language and region), Suppress-Script is
necessary for MANY languages tagged in the future.
It has nothing to do with an existing body of tagged
material.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald <at> sharplabs.com

-----Original Message-----
From: John Cowan [mailto:cowan <at> ccil.org]
Sent: Wednesday, October 03, 2007 7:35 PM
To: Randy Presuhn
Cc: LTRU Working Group
Subject: Re: [Ltru] Clarifying Suppress-Script

Randy Presuhn scripsit:

>   Suppress-Script is a compatibility measure, and as such is
>   only appropriate for languages whose subtags were added to

Re: Clarifying Suppress-Script

Re: Summary of 2007-10-03 teleconference

Re: Clarifying Suppress-Script

Hi -

As a technical contributor...

> From: "Mark Davis" <mark.davis <at> icu-project.org>
> To: "McDonald, Ira" <imcdonald <at> sharplabs.com>
> Cc: "John Cowan" <cowan <at> ccil.org>; "Randy Presuhn" <randy_presuhn <at> mindspring.com>; "LTRU Working
Group" <ltru <at> ietf.org>
> Sent: Thursday, October 04, 2007 10:06 AM
> Subject: Re: [Ltru] Clarifying Suppress-Script
...
> On the other hand, whether or not the language code was pre or post 4646
> doesn't seem to make much difference as far as the question of what I should
> do when interpreting these codes, so it seems from that that we should not
> make Suppress-Script depend on pre or post 4646.
...

As I recall, we added Suppress-Script because there was a large body
of already-tagged material which lacked script subtags, and we wanted
to be able to process that material as though it had been given
script subtags.  In this context, suppress-script is only meaningful
for coping with such material.

Somewhere along the way, the language in what became RFC 4646 got a bit
stronger, eventually ending up as "5.  There MUST be at most one script
subtag in a language tag, and the script subtag SHOULD be omitted when
it adds no distinguishing value to the tag or when the primary language
subtag's record includes a Suppress-Script field listing the applicable
script subtag."  This is still OK with me, but...

There seems to be a bit of semantic drift in the understanding of "Suppress-
Script", from its original meaning as a legacy data compatibility kluge
to a way of indicating for a particular language that a script subtag
would probably not add "distinguishing value".  It's clear from this
discussion that not all of us (myself included) have made such a shift.

If we as a WG want to adopt such a semantic shift, we should do so consciously
and explicitly, because it has a dramatic impact on the number of languages
for which the ietf-languages <at> iana.org list will have to debate the merits of
adding this information to the registry.

Randy

Re: Clarifying Suppress-Script