Re: [Ltru] Updated draft-4646bis...

Addison Phillips <addison@yahoo-inc.com> Wed, 01 August 2007 21:19 UTC

Return-path: <ltru-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLbG-000225-5U; Wed, 01 Aug 2007 17:19:22 -0400
Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IGLbE-000220-Kf for ltru-confirm+ok@megatron.ietf.org; Wed, 01 Aug 2007 17:19:20 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLbE-00021f-8S for ltru@ietf.org; Wed, 01 Aug 2007 17:19:20 -0400
Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGLbA-0003by-Hl for ltru@ietf.org; Wed, 01 Aug 2007 17:19:17 -0400
Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l71LIr52067026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2007 14:18:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=ysRueKNEA3uWQZtvGH0oLvgbq3wzD+uLhxI2H33f0simRH3psshEMhVR/jNLNtRu
Message-ID: <46B0F8BD.7050503@yahoo-inc.com>
Date: Wed, 01 Aug 2007 14:18:53 -0700
From: Addison Phillips <addison@yahoo-inc.com>
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: David Dalby <daviddalby@linguasphere.info>
Subject: Re: [Ltru] Updated draft-4646bis...
References: <auto-000109992662@customermail2.easily.co.uk>
In-Reply-To: <auto-000109992662@customermail2.easily.co.uk>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -15.0 (---------------)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: 'LTRU Working Group' <ltru@ietf.org>
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org

David,

There is nothing wrong in terms of the *meaning* of your sentence :-). 
However, as a contributor, I suggested an alternative phrasing that also 
took into account other's suggestions on list, including a paragraph 
structure previously approved by this WG. I have not seen a groundswell 
of support for any particular version of the paragraph, so the issue is 
also not closed yet.


David Dalby wrote:
> Addison, You seem to have missed the second in my quick sequence of two
> e-mails. 

No, I just don't feel obliged to respond to every email in the thread.

> What is wrong with the simple statement (?):

The proposed text is imprecisely worded. When suggesting replacement 
text, if you do not fully and completely spell it out, the editor is 
likely to need to edit it for consistency, which can defeat the proposed 
purpose. I attempted to take each person's suggestions and combine them 
into a single proposed text (or exclude bits of text or suggestions for 
various reasons expressed on the thread). Note: my proposals are always 
made as a contributor to the list and not as one of the editors.

> 
> "A langtag may be formally valid but remain unrealized in meaning, e.g.
> ...."  This even allows for the unlikely event of its meaning becoming
> realized.

This text has several editorial problems with it.

- We say "language tag", never "langtag"

- The word "may" is one of the normative words from RFC 2119. We never 
use it except with its normative meaning.

- As noted previously, we have defined "valid" to have a specific 
meaning. "Formally" is superfluous and could be confusing as a result.

- We always spell out the Latin abbreviations "e.g." and "i.e." using 
their English equivalents ("for example" and "in other words").

Finally, you didn't include the example text itself, which includes some 
non-simple statements. I note that minor edits suggested out of context 
often make no sense when they are inserted in context. I fine it best to 
be careful to quote the entire proposed paragraph each time and in full 
to help avoid this.

As a result, your suggestion is actually:

<t>
A language tag might be valid but remain unrealized in meaning. For 
example, a tag such as "ar-Cyrl-CO" (Arabic, Cyrillic script, as used in 
  Colombia) is both valid and unlikely to represent a useful combination 
of language attributes.
</t>

So, finally, the substantive part: I think that the phrase "remain 
unrealized in meaning" is somewhat obscure. A newbie, especially one who 
cannot avail herself of this list's mail archive, will have no idea what 
we're talking about. Thus I prefer my (actually an adaptation of 
Peter's) "might not represent any real language usage". Note that this 
formulation does allow for it to either have or acquire real language 
usage in the future.

> 
> Of course, the large majority of ALL potential langtags with subtags will
> never be realized in meaning, but this very obvious point should surely be
> dealt with as briefly as possible.

It was dealt with not-at-all in RFC's 1766, 3066, or 4646. The WG felt 
that some mention was warranted now. We're debating what form that 
mention should take.

Addison

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

Internationalization is an architecture.
It is not a feature.


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