Subject: [Ltru] Description field ordering

From: "Mark Davis" <[email-masked]>
Date: Thu, 14 Dec 2006 09:17:35 -0800

I recommend we add the following language:

http://www.ietf.org/internet-drafts/draft-ietf-ltru-4646bis-01.txt

[after the paragraph starting "For records taken from a source standard
(such as ISO 639 or ISO ...]

Where the source standard has a Reference Name, that name SHOULD be the
first description listed. In the special case of language subtags taken from
ISO 639-1 or ISO 639-2, the Reference Name is considered to be the
corresponding value from ISO 639-3. When there is no corresponding Reference
Name, the first Description SHOULD be the clearest and most common
description for the entity.

Mark
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 14 Dec 2006 18:22:28 +0100

Mark Davis wrote:
 
> [after the paragraph starting "For records taken from a source
> standard (such as ISO 639 or ISO ...]
 
> Where the source standard has a Reference Name, that name SHOULD be
> the first description listed. In the special case of language subtags
> taken from ISO 639-1 or ISO 639-2, the Reference Name is considered to
> be the corresponding value from ISO 639-3. When there is no
> corresponding Reference Name, the first Description SHOULD be the
> clearest and most common description for the entity.

I like it.  The second "SHOULD" could be also an ordinary "should".

---

From: Addison Phillips <[email-masked]>
Date: Thu, 14 Dec 2006 10:33:50 -0800

-0.5

This text should go in RFC 4645bis (registry-update), not 4646bis. I 
don't see a really good reason to make our non-normative descriptions 
have all sorts of arcane requirements about ordering, etc. It would be 
nice if they were in a pleasing order, but the 'key' value is actually 
the subtag. The description is there to make the darned thing clear. If 
you want to know what ISO 639 calls something, refer to it in the source 
standard.

Addison

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

Internationalization is an architecture.
It is not a feature.

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 14 Dec 2006 10:46:30 -0800

I disagree. For localization purposes, having a good, single reference
description is very important.

I see the alternatives as either adding a "Reference Name" field, or just
using the first description. I'm proposing the latter, since it involves the
fewest changes overall -- this is really a minor change overall. And adding
these three lines is not increasing the arcanity of the specification to an
appreciable degree ;-)

It should not just go into the registry update because as the source
standards are updated, this needs to be an ongoing process. Moreover, the
users of the registry should know that this is the policy.

Mark

---

From: Addison Phillips <[email-masked]>
Date: Thu, 14 Dec 2006 11:31:20 -0800

I agree that localizers would prefer a single good reference. But the 
ILSR probably isn't going to be that reference, even with this change. 
Localizers will need to look at various external resources to create a 
translation. This will necessarily include looking at the source 
standard (where information, such as the official names of countries for 
ISO 3166 values, are included in the standard).

Since we permit editing and addition of descriptions, making 
requirements to track particular names would consume a certain amount of 
time/effort on the part of the Official Doug. The normative bits of the 
registry include an unambiguous identifier (the subtag). The description 
is non-normative to avoid having to do annoying things such as tracking 
the official names of countries or various edits of language names (and 
the associated argument about whether "Swiss German" or "Almanisch" or 
"Almannisch" is the "correct" item). Granted we can pick a particular 
"Reference Name", but why not just stick with our current position, 
which is that the names are NOT intended to be more than merely 
descriptive? Especially given the SHOULD in the proposed text.....

Addison

---

From: John Cowan <[email-masked]>
Date: Thu, 14 Dec 2006 14:34:01 -0500

Addison Phillips scripsit:

> but why not just stick with our current position, 

+1

-- 
Not to perambulate                 John Cowan <[email-masked]>
    the corridors                  http://www.ccil.org/~cowan
during the hours of repose
    in the boots of ascension.       --Sign in Austrian ski-resort hotel

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 14 Dec 2006 13:38:38 -0800

> > descriptive? Especially given the SHOULD in the proposed text.....

The 'should' is a pretty easy requirement. Doug has to get the Reference
Name from ISO 639-3 anyway, so it might as well be first, unless someone has
the desire to be deliberately perverse and randomize the position. And if
Doug can't do it, I could.

So why do it? Because it makes some of the consumers of the registry's lives
much easier, and doesn't cost anything appreciable, and I think, increases
the value of the registry overall.

Mark

---

From: Peter Constable <[email-masked]>
Date: Thu, 14 Dec 2006 15:26:36 -0800

> For localization purposes, having a good, single reference description is very important.

I’m not sure what you have in mind wrt to purpose of the description. If the intent is to have a single reference that aids localizers in knowing what the concept is, that’s one thing. But I don’t think users should assume that that description can be treated as a display string appropriate for English UI that localizers will then translate. 

Peter

________________________________

From: Mark Davis [mailto:[email-masked]] 
Sent: Thursday, December 14, 2006 10:47 AM
To: Addison Phillips
Cc: Frank Ellermann; [email-masked]
Subject: Re: [Ltru] Re: Description field ordering

I disagree. For localization purposes, having a good, single reference description is very important.

I see the alternatives as either adding a "Reference Name" field, or just using the first description. I'm proposing the latter, since it involves the fewest changes overall -- this is really a minor change overall. And adding these three lines is not increasing the arcanity of the specification to an appreciable degree ;-) 

It should not just go into the registry update because as the source standards are updated, this needs to be an ongoing process. Moreover, the users of the registry should know that this is the policy.

Mark 

-0.5

Addison

---

From: Martin Duerst <[email-masked]>
Date: Fri, 15 Dec 2006 17:33:34 +0900

>I like it.  The second "SHOULD" could be also an ordinary "should".

We have gone to great lengths in earlier rounds to avoid any
'ordinary' should/may/must/... I wouldn't want to deviate
from this practice.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Martin Duerst <[email-masked]>
Date: Fri, 15 Dec 2006 17:33:34 +0900

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 15 Dec 2006 17:30:21 +0900

At 06:38 06/12/15, Mark Davis wrote:

>On 12/14/06, John Cowan <<mailto:[email-masked]>[email-masked]> wrote:
>The 'should' is a pretty easy requirement. Doug has to get the Reference Name from ISO 639-3 anyway, so it might as well be first, unless someone has the desire to be deliberately perverse and randomize the position. And if Doug can't do it, I could. 
>
>So why do it? Because it makes some of the consumers of the registry's lives much easier, and doesn't cost anything appreciable, and I think, increases the value of the registry overall.

Hello Mark,

I think doing it for the bulk update should work.
But guaranteeing it for future additions is a different
issue. It would be up to interested individuals to watch
upcomming proposals on the ietf-language list and propose
changes if necessary, and there wouldn't be a guarantee that
every registration follows the SHOULD (after all, it's just
a SHOULD).

Would that be okay with you?     Regards,    Martin.

a.ac.jp (scmse1 [133.2.253.16])
	by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id
	kBF8a9cI022631
	for <[email-masked]>; Fri, 15 Dec 2006 17:36:09 +0900 (JST)
Date: Fri, 15 Dec 2006 17:30:21 +0900
To: "Mark Davis" <[email-masked]>, "John Cowan" <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: Re: [Ltru] Re: Description field ordering
Cc: Frank Ellermann <[email-masked]>, [email-masked]

At 06:38 06/12/15, Mark Davis wrote:

>On 12/14/06, John Cowan <<mailto:[email-masked]>[email-masked]> wrote:
>The 'should' is a pretty easy requirement. Doug has to get the Reference Name from ISO 639-3 anyway, so it might as well be first, unless someone has the desire to be deliberately perverse and randomize the position. And if Doug can't do it, I could. 
>
>So why do it? Because it makes some of the consumers of the registry's lives much easier, and doesn't cost anything appreciable, and I think, increases the value of the registry overall.

Hello Mark,

I think doing it for the bulk update should work.
But guaranteeing it for future additions is a different
issue. It would be up to interested individuals to watch
upcomming proposals on the ietf-language list and propose
changes if necessary, and there wouldn't be a guarantee that
every registration follows the SHOULD (after all, it's just
a SHOULD).

Would that be okay with you?     Regards,    Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 15 Dec 2006 16:35:46 +0100

Martin Duerst wrote:

>> The second "SHOULD" could be also an ordinary "should".
 
> We have gone to great lengths in earlier rounds to avoid
> any 'ordinary' should/may/must/... I wouldn't want to
> deviate from this practice.

What I really meant is that I don't see the point in using
a SHOULD keyword in this case, a similar statement without
2119-keyword is good enough.

I don't like inflationary uses of the 2119-keywords, they
should be reserved for critical cases.

Frank