Subject: Re: [Ltru] Ltru Digest, Vol 48, Issue 2

From: Lang Gérard <[email-masked]>
Date: Tue, 3 Feb 2009 15:20:41 +0100

Dear All,

Concerning the discussed point E, I would like to remark that the proposed text is not so clearly evident, because:
(i)- Channel Islands is not, and never was, an entry inside ISO 3166-1;
(ii)- Isle of Man, that is also concerned by section 4 of [RFC4645], cannot be considered as part of Channel Islands.

Ilet me also add that, inside 9.1. Normative References dates given for parts 1,2 and 3 of ISO 639-1 should be precised, as is the case for ISO 639-5, as:
(i)- July 2002 for ISO 639-1;
(ii)- October 1998 for ISO 639-2;
(iii)- February 2007 for ISO 639-3;
.

Bien cordialement.
Gérard LANG

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 2 février 2009 11:18
À : [email-masked]
Objet : Ltru Digest, Vol 48, Issue 2

Send Ltru mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/ltru
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ltru digest..."

Today's Topics:

   1. Re: Editor's copy of draft-4646bis updated... (Martin Duerst)
   2. Re: Editor's copy of draft-4646bis updated... (Phillips, Addison)
   3. Re: Ltru Digest, Vol 48, Issue 1 (Lang G?rard)
   4. Re: Preferred-Value for YU? (Debbie Garside)
   5. Re: Lowercase language names and the Registry (Debbie Garside)

----------------------------------------------------------------------

Message: 1
Date: Mon, 02 Feb 2009 12:51:41 +0900
From: Martin Duerst <[email-masked]>
Subject: Re: [Ltru] Editor's copy of draft-4646bis updated...
To: "Phillips, Addison" <[email-masked]>,	Randy
	Presuhn<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Message-ID: <6.0.0.20.2.20090202101632.06cd6a48@localhost>
Content-Type: text/plain; charset="us-ascii"

Hello Addison,

Many thanks for your work. I have looked at the changes, see below for comments.

At 03:59 09/01/31, Phillips, Addison wrote:
>All,
>
>I have just posted a draft-21 editor's copy on Inter-Locale. This has 
>NOT been submitted to the IETF yet, per the co-chair's instructions. 
>This version incorporates a few errata but not yet the reference to the 
>Awfully New IPR RFC.
>
>   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-21.html
>   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-21.txt
>   http://www.inter-locale.com/ID/draft-ietf-ltru-4646bis-21.xml

I have looked at this and at the diff, and have run the idnits tool.

However, we now have an informative reference in a normative sentence:

       E.  UN numeric codes and ISO 3166-1 alpha-2 codes for countries
           or areas listed as eligible for registration in Section 4 of
           [RFC4645] but not presently registered MAY be entered into
           the IANA registry via the process described in Section 3.5.
           Once registered, these codes MAY be used to form language
           tags.

My understanding from previous discussions (both Randy and I had the same idea) was that for this instance of referencing [RFC4645], we would replace it inline with the only instance left, resulting in something like:

       E.  The UN numeric code or ISO 3166-1 alpha-2 code (once assigned)
           for the Channel Islands MAY be entered into the IANA registry
           via the process described in Section 3.5 (for historic
           details, see [RFC4645]).

Can you please make such an update to your staging draft, so that we are ready to move forward when the copyright issues are solved.

[there won't be any need to include a reference to a new RFC, you will just have to choose the right boilerplate]

BTW, the "local diff" link in your popup (the one going to
http://www.inter-locale.com/ID/rfcdiff.pyht.htm) still shows the diff between -19 and -20.

Regards,   Martin.

>Regards (for the editors)
>
>Addison
>
>Addison Phillips
>Globalization Architect -- Lab126
>
>Internationalization is not a feature.
>It is an architecture.

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

------------------------------

Message: 2
Date: Sun, 1 Feb 2009 20:39:49 -0800
From: "Phillips, Addison" <[email-masked]>
Subject: Re: [Ltru] Editor's copy of draft-4646bis updated...
To: Martin Duerst <[email-masked]>, Randy Presuhn
	<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain; charset="utf-8"

Hello Martin,

Thanks for the note.

> However, we now have an informative reference in a normative
> sentence:
> 
>        E.  UN numeric codes and ISO 3166-1 alpha-2 codes for countries
>            or areas listed as eligible for registration in Section
> 4 of
>            [RFC4645] but not presently registered MAY be entered into
>            the IANA registry via the process described in Section 3.5.
>            Once registered, these codes MAY be used to form language
>            tags.

This is why the reference *was* normative, nu? 

> 
> My understanding from previous discussions (both Randy and I had the 
> same idea) was that for this instance of referencing [RFC4645], we 
> would replace it inline with the only instance left, resulting in 
> something like:
> 
>        E.  The UN numeric code or ISO 3166-1 alpha-2 code (once
> assigned)
>            for the Channel Islands MAY be entered into the IANA 
> registry
>            via the process described in Section 3.5 (for historic
>            details, see [RFC4645]).

I will make this change and post it in the morning.

> 
> [there won't be any need to include a reference to a new RFC, you will 
> just have to choose the right boilerplate]
> 
> 
> BTW, the "local diff" link in your popup (the one going to
> http://www.inter-locale.com/ID/rfcdiff.pyht.htm) still shows the diff 
> between -19 and -20.

Yes. I need to fix it.

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

------------------------------

Message: 3
Date: Mon, 2 Feb 2009 08:44:59 +0100
From: Lang G?rard <[email-masked]>
Subject: Re: [Ltru] Ltru Digest, Vol 48, Issue 1
To: <[email-masked]>
Cc: Lang G?rard <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="iso-8859-1"

I agree with the proposition of John Cowan and Doug Ewell.
Cordialement.
G?rard LANG 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked] Envoy? : dimanche 1 f?vrier 2009 21:00 ? : [email-masked] Objet : Ltru Digest, Vol 48, Issue 1

Send Ltru mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/ltru
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Ltru digest..."

Today's Topics:

   1. Re: Preferred-Value for YU? (John Cowan)
   2. Re: Preferred-Value for YU? (Doug Ewell)

----------------------------------------------------------------------

Message: 1
Date: Sat, 31 Jan 2009 15:31:41 -0500
From: John Cowan <[email-masked]>
Subject: Re: [Ltru] Preferred-Value for YU?
To: Doug Ewell <[email-masked]>
Cc: LTRU Working Group <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Doug Ewell scripsit:

> In draft-4645bis, should we modify the record for subtag YU by 
> removing the P-V of CS, since CS is itself deprecated with no P-V?

+1 for removing CS.

I'd propose adding a comment something like "See BA, HR, ME, MK, RS, or SI."

-- 
John Cowan    [email-masked]    http://ccil.org/~cowan
This great college [Trinity], of this ancient university [Cambridge], has seen some strange sights. It has seen Wordsworth drunk and Porson sober. And here am I, a better poet than Porson, and a better scholar than Wordsworth, somewhere betwixt and between.  --A.E. Housman

------------------------------

Message: 2
Date: Sat, 31 Jan 2009 14:19:42 -0700
From: "Doug Ewell" <[email-masked]>
Subject: Re: [Ltru] Preferred-Value for YU?
To: "LTRU Working Group" <[email-masked]>
Message-ID: <06ADC800716A4308B24580EA88C2B992@DGBP7M81>
Content-Type: text/plain; format=flowed; charset="utf-8";
	reply-type=original

John Cowan <cowan at ccil dot org> wrote:

> +1 for removing CS.

Two assenting voices on a Saturday afternoon and no dissenting voices is enough to make this minor change to the draft.  There will presumably be lots of time for dissenters to make themselves heard.

> I'd propose adding a comment something like "See BA, HR, ME, MK, RS, 
> or SI."

I can do this.  I suppose the precedent of having to provide informative mappings every time ISO 3166 countries split or merge has already been set by the CS and GB comments.  I imagine when as the Netherlands Antilles continue to get their own 3166 codes, the Registry will be expected to provide this sort of mapping back to AN, and we may need to retrofit comments onto BL and MF as well.

--
Doug Ewell  *  Thornton, 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  ?

------------------------------

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

End of Ltru Digest, Vol 48, Issue 1
***********************************

------------------------------

Message: 4
Date: Mon, 2 Feb 2009 10:05:55 -0000
From: "Debbie Garside" <[email-masked]>
Subject: Re: [Ltru] Preferred-Value for YU?
To: "'Doug Ewell'" <[email-masked]>, "'LTRU Working Group'"
	<[email-masked]>
Message-ID: <07b401c9851d$da86e870$0300a8c0@Vickynew>
Content-Type: text/plain;	charset="windows-1250"

Hi Doug

I am not sure that I like the thought of deleting historical information.  I do see where you are coming from but, nevertheless, are we going to be missing a link in the chain by deleting "CS" from "YU"?

I hate deleting information from databases! :-)

What I would like to see is information added to the PV field for "YU" ( such as ":2006-10-05") to indicate when "CS" became invalid as the PV.
However, I am, assuming that this would entail an update to 4646bis and is, therefore, unlikely to be incorporated at this time.

I would ask that you be careful to not inadvertently delete some of the dots that join the Registry.  However, I cannot, on this fine, cold, soon to be snowy, Monday morning, think of a valid reason why other than on principle - I'll try another coffee and maybe write again. :-)

+1 to adding John's comment though.

Best

Debbie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug Ewell
Sent: 31 January 2009 21:20
To: LTRU Working Group
Subject: Re: [Ltru] Preferred-Value for YU?

John Cowan <cowan at ccil dot org> wrote:

> +1 for removing CS.

Two assenting voices on a Saturday afternoon and no dissenting voices is enough to make this minor change to the draft.  There will presumably be lots of time for dissenters to make themselves heard.

> I'd propose adding a comment something like "See BA, HR, ME, MK, RS, 
> or SI."

I can do this.  I suppose the precedent of having to provide informative mappings every time ISO 3166 countries split or merge has already been set by the CS and GB comments.  I imagine when as the Netherlands Antilles continue to get their own 3166 codes, the Registry will be expected to provide this sort of mapping back to AN, and we may need to retrofit comments onto BL and MF as well.

--
Doug Ewell  *  Thornton, 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  ?

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

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.10.16/1926 - Release Date: 30/01/2009
17:31

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.10.16/1929 - Release Date: 01/02/2009
18:02

------------------------------

Message: 5
Date: Mon, 2 Feb 2009 10:10:24 -0000
From: "Debbie Garside" <[email-masked]>
Subject: Re: [Ltru] Lowercase language names and the Registry
To: "'Phillips, Addison'" <[email-masked]>,	"'LTRU Working Group'"
	<[email-masked]>
Message-ID: <07ba01c9851e$77e94860$0300a8c0@Vickynew>
Content-Type: text/plain; charset="iso-8859-1"

Addison wrote:

>> So? to be clear, I favor putting *exactly* what ISO 639 has into the
initial registry unless it conflicts with a specific provision of 4646bis

+1

Debbie

   _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillips, Addison
Sent: 30 January 2009 18:15
To: Gerard Meijssen; CE Whitehead
Cc: [email-masked]
Subject: Re: [Ltru] Lowercase language names and the Registry

The RFC says quite clearly that the ?Description? fields in the registry exist only to provide for unambiguous identification of subtag meaning. They should not be taken to be the localized name or in any particular language.
Mainly the registry mirrors whatever one of the ISO groups has put into their standards. 4646bis allows for some cleanup/editing by the LSR in cases where the name has some sort of formatting problem (hence Doug?s inquiry).
This is different from the goals of CLDR. People can and should rely on CLDR to be correct in presentation. But we have already warned users NOT to rely on the description fields in the registry.

Note that the registration process exists to allow users of the registry to correct or add additional descriptive material. My tendency is to favor mirroring exactly what ISO 639 has in the ?initial? registry. If someone feels strongly about it, they can petition ietf-languages@ to change it.
That?s what the process is for and I would tend to support corrections that native language speakers feel strongly about.

So? to be clear, I favor putting *exactly* what ISO 639 has into the initial registry unless it conflicts with a specific provision of 4646bis.

Addison Phillips

Globalization Architect -- Lab126

Internationalization is not a feature.

It is an architecture.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gerard Meijssen
Sent: Friday, January 30, 2009 10:07 AM
To: CE Whitehead
Cc: [email-masked]
Subject: Re: [Ltru] Lowercase language names and the Registry

Hoi,
If the list is ony to be used as a list with a local application, I agree.
When people want to use lists like this or the CLDR language list, they depend on the information to be right. It is not and people do.
Thanks,
       Gerard

2009/1/30 CE Whitehead <HYPERLINK
"mailto:[email-masked]"[email-masked]>

Hi.  I think Leif and Doug get my vote here.

In a list I'd feel comfortable 'title-casing' the first word in French (a language in which language names are also normally 'lower-cased').
But I'm not a native speaker.  
 
(NOTE:  I found different conventions regarding titles online:
HYPERLINK
"http://www.google.com/search?hl=en&q=histoire+du+francais&btnG=Search"
\nhttp://www.google.com/search?hl=en&q=histoire+du+francais&btnG=Search
HYPERLINK "http://www.google.com/search?hl=en&q=francais&btnG=Search"
\nhttp://www.google.com/search?hl=en&q=francais&btnG=Search [these are not lists however, just titles].
when a French title appears on a book in the U.S. market, every word on the book may be title-cased:
HYPERLINK
"http://shopping.msn.com/prices/allons-y-le-francais-par-etapes-with-audio-c
d/itemid25043275/?itemtext=itemname:allons-y-le-francais-par-etapes-with-aud
io-cd"
\nhttp://shopping.msn.com/prices/allons-y-le-francais-par-etapes-with-audio-
cd/itemid25043275/?itemtext=itemname:allons-y-le-francais-par-etapes-with-au
dio-cd
Wikipedia has two conventions for lists in French it seems?:
HYPERLINK
"http://fr.wikipedia.org/wiki/Liste_de_langues_par_ordre_alphab%C3%A9tique"
\nhttp://fr.wikipedia.org/wiki/Liste_de_langues_par_ordre_alphab%C3%A9tique
HYPERLINK "http://fr.wikipedia.org/wiki/Liste_des_langues_officielles"
\nhttp://fr.wikipedia.org/wiki/Liste_des_langues_officielles
 
in one the first word, whether the language name or a definite article preceding the name, is 'upper cased'; in the other list the names are almost all 'lower cased')

Thanks.
 
--C. E. Whitehead
HYPERLINK "mailto:[email-masked]" \[email-masked] 

 

From: Leif Halvard Silli <HYPERLINK "mailto:[email-masked]" \nlhs at malform.no>
To: Doug Ewell <HYPERLINK "mailto:[email-masked]" \ndoug at ewellic.org>

Doug Ewell 2009-01-30 07.08:

So far so good, but then the January 26 revision came along and lowercased
the Finnish and Swedish names, as the requestor originally suggested (see
HYPERLINK "http://www.sil.org/iso639-3/cr_files/2008-028.pdf"
\nhttp://www.sil.org/iso639-3/cr_files/2008-028.pdf): 

   Finland-Swedish Sign Language
   finlandssvenskt teckenspr?k
   suomenruotsalainen viittomakieli

   [...]

I propose that for draft-4645bis and the Language Subtag Registry generally,
we introduce a rule that Description fields for language subtags be modified
from the ISO-provided name if necessary to ensure they begin with a capital
letter, unless the lowercase letter is considered necessary to spell the
name correctly (as it is in "tlhIngan-Hol"). This is consistent with
draft-4646bis, Section 3.1.5, which allows Description fields to be "edited
or modified" from the ISO rendering. 

Unless someone objects on-list to this rather pedantic suggestion, it will
be added to the next draft-4645bis. 

In my view it is defendable to let language names begin with upper-case
letter even in Scandinavian languages, as long as the names appears in a
list -aka "menu" - as opposed to in a comma separated line of words. Hence,
I'm ok with it. 

--
leif halvard silli

_______________________________________________
Ltru mailing list
HYPERLINK "mailto:[email-masked]"[email-masked]
HYPERLINK "https://www.ietf.org/mailman/listinfo/ltru"
\nhttps://www.ietf.org/mailman/listinfo/ltru

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.552 / Virus Database: 270.10.15/1924 - Release Date: 29/01/2009
17:57

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.10.16/1929 - Release Date: 01/02/2009
18:02
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/pipermail/ltru/attachments/20090202/ac2d0dff/attachment.htm>

------------------------------

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

End of Ltru Digest, Vol 48, Issue 2
***********************************
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Mon, 09 Feb 2009 11:05:06 +0900

>(i)- Channel Islands is not, and never was, an entry inside ISO 3166-1;

That's exactyl why there is this special provision.

>(ii)- Isle of Man, that is also concerned by section 4 of [RFC4645], cannot 
>be considered as part of Channel Islands.

That's irrelevant. In RFC 4645, and potentially in the registry,
these are just four codes, for four regions, which could be anywhere
in the world.

Regards,    Martin.

>Ilet me also add that, inside 9.1. Normative References dates given for 
>parts 1,2 and 3 of ISO 639-1 should be precised, as is the case for ISO 
>639-5, as:
>G駻ard LANG