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

["David Dalby" <[e-mail]>]

Thank you very much for your helpful e-mail. I shall try to observe the
conventions you have set out, and to respond if anything further suggests
itself. I also am just trying to catch up, after an absence on language
research (including some of the practical implications and applications of
tagging). 

David (Dalby)
The Linguasphere Observatory
Hebron SA34 0XT
Wales

-----Original Message-----
From: Addison Phillips [mailto:[e-mail]] 
Sent: 01 August 2007 22:19
To: David Dalby
Cc: [e-mail]; 'Marion Gunn'; 'LTRU Working Group'
Subject: Re: [Ltru] Updated draft-4646bis...

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