Subject: [Ltru] Re: updated editor's copy to deal with 'mis', etc.

From: "Doug Ewell" <[email-masked]>
Date: Sun, 22 Apr 2007 10:56:27 -0700

Addison Phillips <addison at yahoo dash inc dot com> wrote:

>      4.  The 'mis' (Miscellaneous) primary language subtag is used to
>          identify linguistic content whose language is known but
>          cannot otherwise be identified.  It is commonly used when the
>          range of language tags is constrained (for example, to the
>          set defined for use in the [MARC21] standard, for example) or
>          for languages not otherwise categorized.  It SHOULD NOT be
>          used unless a language tag is required and no other means of
>          identifying the language is available.

Good.  I hope this is satisfactory to everyone.

>      5.  The grandfathered tag "i-default" (Default Language) was
>          originally registered according to [RFC1766] to meet the
>          needs of [RFC2277].  It is used to indicate not a specific
>          language, but rather, it identifies the condition or content
>          used where the language preferences of the user cannot be
>          established.

The copy editor in me is having trouble with this sentence.  How about:

"It is used to identify the condition or content used where the language 
preferences of the user cannot be established, in accordance with 
[RFC2277], not to indicate a specific language."

In addition to the grammatical changes, note the additional 
hammer-the-point-home reference to RFC 2277.

>          It SHOULD NOT be used except as a means of
>          labeling the default content for applications or protocols
>          that require default language content to be labeled with that
>          specific tag.  It MAY also be used by an application or
>          protocol to identify when the default language content is
>          being returned.

Good.

> Comments?

One general question:  Are all of the basic premises of RFC 4646bis 
(e.g. extlangs as they were originally understood) stabilized to the 
point where I can submit another draft of RFC 4645bis, possibly even for 
WG Last Call?

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~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: "Kent Karlsson" <[email-masked]>
Date: Sun, 22 Apr 2007 22:24:02 +0200

Doug Ewell wrote:
> Addison Phillips wrote:

1) I don't see a particular need to reference the MARC set of codes here.

2) Please generalise the formulation to apply to ALL of the collection
   codes. 'mis' is not and should not be a special case. I really don't
   want to see any principled difference among the collection codes.
   639 does not do any such principled difference among the collection
   codes, and I see no need to depart from that.

	/kent k

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 22 Apr 2007 14:35:22 -0700

>   codes, and I see no need to depart from that.

I fundamentally disagree with Kent on this point, and will say no more 
about it, on either this list or ietf-languages.  Let the WG do what it 
will.

---

From: "Kent Karlsson" <[email-masked]>
Date: Mon, 23 Apr 2007 00:29:48 +0200

Doug Ewell wrote:
> Kent Karlsson wrote:

There is no support in ISO 639 for making any kind of principled
difference between any of the collection codes, and 'mis' is
most definitely an ordinary collection code (I see absolutely
no reason to change that). If you want to replace the 'mis'
code by another one meaning the same as 'mis', then do so
in one way or another, though I don't see that as meaningful.

RFC 4646 and predecessors have made no principled difference
between the collection code (or even mentioned them at all).
I see no problem in mentioning or recommending something about
collection codes, as long as the mentioning and recommending
is in principle (at the meta-level, if you like) the same for
all of the collection code.

But singling out one (or some) collection code(s) and treat
that (those) in any way differently from the others would be
a new and bad thing. And whatever the recommendation is, it must
not be in direct conflict with the recommendation in 639-2
w.r.t. collection codes.

As long as that is fulfilled, I happy to go along with anything
from deprecating all of the collection codes (with no replacements)
for 4646bis as all (known, modern or nearly modern, natural)
languages will have their own code, to allowing them for some
purpose (e.g. partial information) also for "new" use. "Old"
documents may of course be using collection codes, even if
they are deprecated in 4646bis.

		/kent k

---

From: Addison Phillips <[email-masked]>
Date: Mon, 23 Apr 2007 09:31:39 +0100

> [RFC2277], not to indicate a specific language."

The copy editor in me doesn't like that sentence either: I lifted it 
nearly intact from RFC 2277. Your version is superior.

> point where I can submit another draft of RFC 4645bis, possibly even for 

AFAICT, they are, although I note that what has happened, essentially, 
is that the discussion on extlangs has been on hiatus and has not 
reached a conclusion. Mark still believes (I think) that we should 
promote the enclosed languages to primary language subtags and basically 
forget extlangs for now. I still believe that his reasons for wanting to 
do this can be overcome (and I've done so primarily by modifying the 
behavior of my lookup implementation).

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.