I think this is misguided. The problem here that we seem to be
struggling with is that we don’t wish to insinuate that one form or the other
is “better” because we cannot agree amongst ourselves which form is better… or
we fear that some nameless parties will object later (why they don’t object now
I don’t understand---it’s a kind of DoS attack on the WG not to say what one
prefers now).
I cannot understand how a subtag can have a “preferred value”
(implying that it is at least “not preferred”) and not say that it is
deprecated. Deprecation is not the end of the world for a subtag. If what we’re
saying is that deprecation of (either) one of the forms is a non-starter, then
let’s go with:
1.
There are two forms Y
and X-Y.
2.
Neither form is
preferred and neither form is deprecated. Either MAY be used to form the
language tag.
3.
Choosing one form or
the other has implications, especially for naïve matching algorithms (list
these implications where known)
That strikes me as a workable compromise if we cannot agree to
deprecate one form or the other. Implementations are still free to choose one
form over the other and still free to “normalize” tags to that form for
processing.
Addison
Addison Phillips
Globalization Architect -- Lab126
Internationalization is not a feature.
It is an architecture.
From:
ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of Mark
Davis
Sent: Monday, July 07, 2008 9:24 PM
To: Doug Ewell
Cc: LTRU Working Group
Subject: [Ltru] Possibly a way forward? (was extlang & deprecation
(was draft updated...))
I ran the following by a few
people, and it may offer a way out of our current situation, by taking
the following steps.
- Tie "Preferred Value" more closely to
canonicalization.
- Decouple "Preferred Value" and
"Deprecated"; a subtag can have a Preferred Value without
being Deprecated.
- Make it very clear that when there is a Preferred
Value or when there is Deprecated, the tag or subtag is still valid, and
perfectly acceptable.
- In particular, make it clear that the X-Y values
are perfectly acceptable, and as valid as the Y forms.
- Add that some implementations will find it more
convenient to have their own canonical form. Give examples of
"iw" for Java, and of X-Y forms.
Can
anyone not live with the current draft plus these changes?
Mark
On Tue, Jul 1, 2008 at 6:31 PM, Doug Ewell <doug at ewellic.org> wrote:
John Cowan <cowan at ccil
dot org> wrote:
That's not the definition of Deprecate:
Dictionary definitions of "deprecate" aren't relevant, because it is
a term of art among programmers and standardizers. From Wikipedia:
In computer software standards and documentation, the term
deprecation is applied to software features that are
superseded
and should be avoided. Although deprecated features remain
in the current version, their use may raise warning
messages
recommending alternate practices, and deprecation may
indicate
that the feature will be removed in the future. Features
are
deprecated -- rather than being removed -- in order to
provide
backward compatibility and give programmers using the
feature
time to bring their code into compliance with the new
standard.
http://en.wikipedia.org/wiki/Deprecation
Actually, while this disagreement over the use of the word
"deprecated" may seem academic, I think it cuts to the very heart of
the X-Y versus Y controversy. People on this list -- even the same person
at different times; I'll dig up quotes if asked -- have said that (1)
deprecated subtags are perfectly fine to use, because they'll just get
normalized away, AND that (2) deprecated subtags are something to be avoided at
all costs.
We can't have it both ways, and expect those on the opposite side of this
battle to accept their preferred forms being "deprecated" on the
basis of argument 1 ("it's still OK to use them") when we still have
draft text, and arguments on the list, that their use will be considered
non-conformant.
As I've said before, we can get so caught up in our own terminology that we
forget that the general tagging populace may not understand these terms the way
we understand them -- and without a glossary, we can't fault them for devising
their own definitions. I agree with John that the use of
"deprecated" in the programming world is different from the
mainstream dictionary definition, which evokes visions of burning at the stake,
but we don't even agree among ourselves exactly what it does mean.
Until we do that, and unless we decide formally that "deprecated" has
the gentler meaning of "OK to use, but will be normalized away," the
battle lines between the "zh-cmn" crowd and the "cmn" crows
will continue to be drawn.
--
Doug Ewell * Arvada, Colorado, USA * RFC 4645 *
UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages
ˆ
|