From verdy_p@wanadoo.fr Sun Apr 1 01:39:43 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Sun, 01 Apr 2007 01:39:43 -0600 (CST) Received: from smtp21.orange.fr (smtp21.orange.fr [80.12.242.47]) by unicode.org (8.13.4/8.12.11) with ESMTP id l317dgLE022327 for ; Sun, 1 Apr 2007 01:39:43 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2108.orange.fr (SMTP Server) with ESMTP id 46A371C00093 for ; Sun, 1 Apr 2007 09:39:37 +0200 (CEST) Received: from HARNON (APoitiers-156-1-127-124.w90-5.abo.wanadoo.fr [90.5.142.124]) by mwinf2108.orange.fr (SMTP Server) with ESMTP id 4498D1C0008D for ; Sun, 1 Apr 2007 09:39:36 +0200 (CEST) X-ME-UUID: 20070401073936281.4498D1C0008D@mwinf2108.orange.fr From: "Philippe Verdy" To: References: <460EA5BA.5070706@gmx.net> Subject: RE: Question on Exemplar Characters Date: Sun, 1 Apr 2007 09:39:31 +0200 Organization: Ordinateur Personnel Message-ID: <002e01c77430$e3dd6ca0$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <460EA5BA.5070706@gmx.net> Thread-Index: AcdzwhlhqryCUANXRq2Aj6X23tYt+wAbesaw Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l317dgLE022327 X-archive-position: 71 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users That's a good question, and it is comparable to the case of apostrophes and hyphens which also have orthographic use and are necessary in many locales using Latin, Greek or Cyrillic scripts. But their choice and proper encoding is locale-dependant (more really, script-dependant). For now I assume that the purpose is to check first the letters (gc=L*), and their composed sequences, to create subsets of them for validation. But a problem with the current syntax is that it is defined as a set of characters, instead of a set of strings; if there are letters that can be presented only as a sequence (base letter plus diacritics), should they be represented in the examplar or auxiliary characters? > -----Message d'origine----- > De: cldr-users-bounce@unicode.org [mailto:cldr-users-bounce@unicode.org] > De la part de Christopher Fynn > Envoy: samedi 31 mars 2007 20:18 > : cldr-users@unicode.org > Objet: Question on Exemplar Characters > > When punctuation characters are necessary within locale data should > these punctuation characters be included in exemplar characters? > > Tibetan requires the characters U+0F0B, U+0F0C and U+0F0D within > territory names and other strings. > > - Chris > > > -------------------------------------------------------------------------- > ------------- > Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > From mark.edward.davis@gmail.com Sun Apr 1 18:17:13 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Sun, 01 Apr 2007 18:17:13 -0600 (CST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by unicode.org (8.13.4/8.12.11) with ESMTP id l320HDrV026324 for ; Sun, 1 Apr 2007 18:17:13 -0600 Received: by wr-out-0506.google.com with SMTP id i28so1306963wra for ; Sun, 01 Apr 2007 17:17:12 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=eUPN9LQLjtUemcIBEao6gm2KwcffBOaStfKtsI0AQPRcgv6FgEAbkrMPSn78gHABj4yTfOZLLPNsW8DPf/CALhFYwPvI+ycDHZxvSa1cLdSv+pve8uJUC6kR6XgAoQPjOW89N1VL3Qvskvn69QCpTBWY052o4trBIXf3SFgYafg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=gOW+gYnFlH5f/twsqpBxxGzZ1atEI1Ucc8sbLkUvjPkidWNVtAQMCfUzUaIEkf32fhxCUtXX/8wehpxG2MhLuNV7zTjGlJ9TiLTdOoKuGkuNoKXUcZVYA515XjGlD7Vlqk1vmO3hJOleD1iU68YrKtSuJL9DLHghYGnXOe2cRg0= Received: by 10.115.17.1 with SMTP id u1mr1575723wai.1175473031953; Sun, 01 Apr 2007 17:17:11 -0700 (PDT) Received: by 10.114.196.2 with HTTP; Sun, 1 Apr 2007 17:17:11 -0700 (PDT) Message-ID: <30b660a20704011717x44d3e62k5fdaadce774abf1c@mail.gmail.com> Date: Sun, 1 Apr 2007 17:17:11 -0700 From: "Mark Davis" To: cldr-users@unicode.org, "CLDR list" Subject: Re: Question on Exemplar Characters In-Reply-To: <460EA5BA.5070706@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_117471_33021650.1175473031914" References: <460EA5BA.5070706@gmx.net> X-Google-Sender-Auth: 44c21888df7f487e X-archive-position: 72 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: mark.davis@icu-project.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users ------=_Part_117471_33021650.1175473031914 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline UmlnaHQgbm93LCB3ZSBhcmUgb25seSBpbmNsdWRpbmcgbGV0dGVycyBhbmQgbWFya3MgaW4gdGhl IGV4ZW1wbGFyIHNldC4gVGhlCnNldCBpcyB1c2VkIGZvciBhIGNvdXBsZSBvZiBwdXJwb3Nlcywg bm90YWJseSBjaGVja2luZyB0aGUgQ0xEUiBkYXRhIGl0c2VsZiwKYnV0IGFsc28gZGV0ZXJtaW5p bmcgd2hldGhlciBsZWdhY3kgY2hhcnNldHMgYXJlIGFibGUgdG8gaGFuZGxlIHRoZQpjaGFyYWN0 ZXJzIGluIGEgbGFuZ3VhZ2UgKGltcGxlbWVudGF0aW9ucyBtYXkgYWxzbyBiZSB1c2luZyB0aGVt IGZvciBvdGhlcgpwdXJwb3NlcykuIEZvciB0aGUgZm9ybWVyIHB1cnBvc2UsIHdlIGFsbG93IGFu eSBub24tIGxldHRlci9tYXJrIGNoYXJhY3RlcnMKaW4gdGhlIGRhdGEsIHNvIHRoZXkgZG9uJ3Qg bmVlZCB0byBiZSBpbiB0aGUgZXhlbXBsYXIgc2V0cy4gRm9yIHRoZSBsYXR0ZXIsCmlmIGEgY2hh cnNldCBoYXMgdGhlIGJhc2ljIFRpYmV0YW4gbGV0dGVycywgYnV0IGRvZXNuJ3QgaGF2ZSBzYXkg VSswRjBCIGl0CmlzIHVuY2xlYXIgd2hldGhlciB5b3Ugd291bGQgbWFrZSB0aGUgY2hvaWNlIHRv IHVzZSBvciBub3QgdXNlIHRoZSBjaGFyc2V0Cm9uIHRoYXQgYmFzaXMuCgpPdXIgb3JpZ2luYWwg cHVycG9zZSBpbiBmb2N1c2luZyBvbiBsZXR0ZXJzIGFuZCBtYXJrcyB3YXMgdG8gdHJ5IHRvIG1h a2UgaXQKZWFzaWVyIGZvciBwZW9wbGUgdG8gc3VwcGx5IGEgZGVmaW5pdGl2ZSBsaXN0LCBzaW5j ZSBwdW5jdHVhdGlvbiBhbmQgc3ltYm9sCnVzYWdlIGlzIGV2ZW4gdHJpY2tpZXIgdG8gZGVjaWRl IHRoYW4gbGV0dGVyIHVzYWdlLiAoQSBxdWVzdGlvbiBtYXJrICg/KSBpcwpjZXJ0YWlubHkgcmVx dWlyZWQgZm9yIEVuZ2xpc2guIEJ1dCBob3cgYWJvdXQgY3VybHkgcXVvdGVzICgnICcgIiAiKT8g SXMgdGhlCmRhZ2dlciAo4oCgKSByZXF1aXJlZD8gRG91YmxlIGRhZ2dlciAo4oChKT8gUGlsY3Jv dyAowrYpPy4uLi4pCgpIb3dldmVyLCBpZiBhIGdvb2QgY2FzZSBjYW4gYmUgbWFkZSBmb3IgY2hh bmdpbmcgdGhhdCBwb2xpY3ksIHdlIGNhbgpjZXJ0YWlubHkgZGlzY3VzcyBhbWVuZGluZyBpdC4K Ck1hcmsKCk9uIDMvMzEvMDcsIENocmlzdG9waGVyIEZ5bm4gPGNmeW5uQGdteC5uZXQ+IHdyb3Rl Ogo+Cj4gV2hlbiBwdW5jdHVhdGlvbiBjaGFyYWN0ZXJzIGFyZSBuZWNlc3Nhcnkgd2l0aGluIGxv Y2FsZSBkYXRhIHNob3VsZAo+IHRoZXNlIHB1bmN0dWF0aW9uIGNoYXJhY3RlcnMgYmUgaW5jbHVk ZWQgaW4gZXhlbXBsYXIgY2hhcmFjdGVycz8KPgo+IFRpYmV0YW4gcmVxdWlyZXMgdGhlIGNoYXJh Y3RlcnMgVSswRjBCLCBVKzBGMEMgYW5kIFUrMEYwRCB3aXRoaW4KPiB0ZXJyaXRvcnkgbmFtZXMg YW5kIG90aGVyIHN0cmluZ3MuCj4KPiAtIENocmlzCj4KPgoKCi0tIApNYXJrCg== ------=_Part_117471_33021650.1175473031914 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline UmlnaHQgbm93LCB3ZSBhcmUgb25seSBpbmNsdWRpbmcgbGV0dGVycyBhbmQgbWFya3MgaW4gdGhl IGV4ZW1wbGFyIHNldC4gVGhlIHNldCBpcyB1c2VkIGZvciBhIGNvdXBsZSBvZiBwdXJwb3Nlcywg bm90YWJseSBjaGVja2luZyB0aGUgQ0xEUiBkYXRhIGl0c2VsZiwgYnV0IGFsc28gZGV0ZXJtaW5p bmcgd2hldGhlciBsZWdhY3kgY2hhcnNldHMgYXJlIGFibGUgdG8gaGFuZGxlIHRoZSBjaGFyYWN0 ZXJzIGluIGEgbGFuZ3VhZ2UgKGltcGxlbWVudGF0aW9ucyBtYXkgYWxzbyBiZSB1c2luZyB0aGVt IGZvciBvdGhlciBwdXJwb3NlcykuIEZvciB0aGUgZm9ybWVyIHB1cnBvc2UsIHdlIGFsbG93IGFu eSBub24tIGxldHRlci9tYXJrIGNoYXJhY3RlcnMKaW4gdGhlIGRhdGEsIHNvIHRoZXkgZG9uJiMz OTt0IG5lZWQgdG8gYmUgaW4gdGhlIGV4ZW1wbGFyIHNldHMuIEZvciB0aGUgbGF0dGVyLCBpZiBh IGNoYXJzZXQgaGFzIHRoZSBiYXNpYyBUaWJldGFuIGxldHRlcnMsIGJ1dCBkb2VzbiYjMzk7dCBo YXZlIHNheSBVKzBGMEIgaXQgaXMgdW5jbGVhciB3aGV0aGVyIHlvdSB3b3VsZCBtYWtlIHRoZSBj aG9pY2UgdG8gdXNlIG9yIG5vdCB1c2UgdGhlIGNoYXJzZXQgb24gdGhhdCBiYXNpcy4KPGJyPjxi cj5PdXIgb3JpZ2luYWwgcHVycG9zZSBpbiBmb2N1c2luZyBvbiBsZXR0ZXJzIGFuZCBtYXJrcyB3 YXMgdG8gdHJ5IHRvIG1ha2UgaXQgZWFzaWVyIGZvciBwZW9wbGUgdG8gc3VwcGx5IGEgZGVmaW5p dGl2ZSBsaXN0LCBzaW5jZSBwdW5jdHVhdGlvbiBhbmQgc3ltYm9sIHVzYWdlIGlzIGV2ZW4gdHJp Y2tpZXIgdG8gZGVjaWRlIHRoYW4gbGV0dGVyIHVzYWdlLiAoQSBxdWVzdGlvbiBtYXJrICg/KSBp cyBjZXJ0YWlubHkgcmVxdWlyZWQgZm9yIEVuZ2xpc2guIEJ1dCBob3cgYWJvdXQgY3VybHkgcXVv dGVzICgKPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sc2VyaWY7Ij4n ICcgIiAiPC9zcGFuPik/IElzIHRoZSBkYWdnZXIgKOKAoCkgcmVxdWlyZWQ/IERvdWJsZSBkYWdn ZXIgKOKAoSk/IFBpbGNyb3cgKMK2KT8uLi4uKTxicj48YnI+SG93ZXZlciwgaWYgYSBnb29kIGNh c2UgY2FuIGJlIG1hZGUgZm9yIGNoYW5naW5nIHRoYXQgcG9saWN5LCB3ZSBjYW4gY2VydGFpbmx5 IGRpc2N1c3MgYW1lbmRpbmcgaXQuCjxicj48YnI+TWFyazxicj48YnI+PGRpdj48c3BhbiBjbGFz cz0iZ21haWxfcXVvdGUiPk9uIDMvMzEvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5D aHJpc3RvcGhlciBGeW5uPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNmeW5uQGdteC5uZXQiIHRh cmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSI+Y2Z5bm5AZ214Lm5ldAo8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2Io MjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDog MWV4OyI+CldoZW4gcHVuY3R1YXRpb24gY2hhcmFjdGVycyBhcmUgbmVjZXNzYXJ5IHdpdGhpbiBs b2NhbGUgZGF0YSBzaG91bGQ8YnI+dGhlc2UgcHVuY3R1YXRpb24gY2hhcmFjdGVycyBiZSBpbmNs dWRlZCBpbiBleGVtcGxhciBjaGFyYWN0ZXJzPzxicj48YnI+VGliZXRhbiByZXF1aXJlcyB0aGUg Y2hhcmFjdGVycyBVKzBGMEIsIFUrMEYwQyBhbmQgVSswRjBEIHdpdGhpbjxicj50ZXJyaXRvcnkg bmFtZXMgYW5kIG90aGVyIHN0cmluZ3MuCjxicj48YnI+LSBDaHJpczxicj48YnI+PC9ibG9ja3F1 b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5NYXJrCg== ------=_Part_117471_33021650.1175473031914-- From mark.edward.davis@gmail.com Wed Apr 11 10:53:45 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 11 Apr 2007 10:53:46 -0600 (CST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3BGrjUs004414 for ; Wed, 11 Apr 2007 10:53:45 -0600 Received: by wr-out-0506.google.com with SMTP id 68so198824wri for ; Wed, 11 Apr 2007 09:53:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=hUIbL7m5lOk5rmN8kjL1oEsoEKK+c+MGlalT/+raH6RWs5kogpXSDyzZlFz16yp2o9k42jmoT8FvVY/5AzoOkjz5QCxcd2BG+7FDYC0kiRqL0uS5aUyJjtdtZ45a57qUwPYgQe5eAmHpfTTzDv+xpFHTejsqhXDQeWnlLp5iKC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=NULhWXcn/IfbUtlwwyEBXisLO/V9RlJHWCwRHWfQAeHfLPA4sof8fvSuiB/0bXjDIw3WbxUPX4+bkbrDTZImVlyMm23ZO7t6Qvvr0tDy/Yx77+IT5GqEJE1A56BjgFoeMZuWt7QhSVECoDZZ5yeRUG4gFjqh/IaLmHH7fzGEc7c= Received: by 10.114.158.1 with SMTP id g1mr348601wae.1176310423569; Wed, 11 Apr 2007 09:53:43 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Wed, 11 Apr 2007 09:53:43 -0700 (PDT) Message-ID: <30b660a20704110953n27ffbe62x4524b46f336fa9b1@mail.gmail.com> Date: Wed, 11 Apr 2007 09:53:43 -0700 From: "Mark Davis" To: Balasankar Subject: Re: auxiliary exemplar characters Cc: unicode@unicode.org, cldr-users@unicode.org In-Reply-To: <000801c77bf4$30d99130$d71110ac@Lts215> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15461_4482349.1176310423482" References: <000801c77bf4$30d99130$d71110ac@Lts215> X-Google-Sender-Auth: 4732ba5e809349e0 X-archive-position: 73 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: mark.davis@icu-project.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users ------=_Part_15461_4482349.1176310423482 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline WW91IHNob3VsZCBwb3N0IHF1ZXN0aW9ucyBsaWtlIHRoaXMgdG8gY2xkci11c2Vyc0B1bmljb2Rl Lm9yZy4KCkknbGwgZ28gYWhlYWQgYW5kIGFuc3dlciBoZXJlIGZvciBzaW1wbGljaXR5LiBUaGUg bWlzdGFrZSB0aGF0IHJlc3VsdGVkIHdhcwpub3QgY29ubmVjdGVkIHdpdGggdGhlIFx1IG5vdGF0 aW9uOyBpdCB3YXMgYSBtaXNzaW5nICJbIi4gQSBzZXQgb2YKY2hhcmFjdGVycyBuZWVkcyB0byBi ZSBvZiB0aGUgZm9ybSAiW2EtYiBtLXBdIiwgbm90IGp1c3QgImEtYiBtLXAiLiBXZSBkbwp1c2Ug XHUgbm90YXRpb24gZm9yIHRob3NlIGNoYXJhY3RlcnMgdGhhdCBhcmUgbm90IG5vcm1hbGx5IHZp c2libGUKKHdoaXRlc3BhY2UgYW5kIGRlZmF1bHQgaWdub3JhYmxlIGNoYXJhY3RlcnMpLiBFeGVt cGxhciBjaGFyYWN0ZXJzIGluIENMRFIKbm9ybWFsbHkgb25seSBpbmNsdWRlIGxldHRlcnMsIGFu ZCB0aHVzIGRvbid0IG5lZWQgdGhlIGpvaW5lciBjaGFyYWN0ZXJzCjIwMEMgPGh0dHA6Ly91bmlj b2RlLm9yZy9jbGRyL3V0aWxpdHkvY2hhcmFjdGVyLmpzcD9hPTIwMEM+ICgg4pagICkgWkVSTyBX SURUSApOT04tSk9JTkVSCjIwMEQgPGh0dHA6Ly91bmljb2RlLm9yZy9jbGRyL3V0aWxpdHkvY2hh cmFjdGVyLmpzcD9hPTIwMEQ+ICgg4pagICkgWkVSTyBXSURUSApKT0lORVIKV2UgbWF5LCBob3dl dmVyLCB0aWdodGVuIHRoYXQgdXAgaW4gY29uanVuY3Rpb24gd2l0aApodHRwOi8vd3d3LnVuaWNv ZGUub3JnL3Jldmlldy8jcHJpOTYuCgpNYXJrCgpPbiA0LzEwLzA3LCBCYWxhc2Fua2FyIDxiYWxh c2Fua2FyQGNkYWN0dm0uaW4+IHdyb3RlOgo+Cj4gIElzIGl0IHBvc3NpYmxlIHRvIGFkZCAgYSBj aGFyYWN0ZXIgYXMgXHUrdW5vY29kZSB2YWx1ZSBleDogXHUyMDBkICBpbgo+IGF1eGlsaWFyeSBl eGVtcGxhciBsaXN0PyBUaGUgZm9sbG93aW5nICBlcnJvciBvY2N1cnJlZCB3aGVuIEkgdHJpZWQg dG8gZG8KPiB0aGUgYWJvdmUuCj4KPiBqYXZhLmxhbmcuSWxsZWdhbEFyZ3VtZW50RXhjZXB0aW9u OiBFcnJvcjogTWlzc2luZyAnWycgYXQgIlxcdTIwMGR8IFxcdTIwMGMiCj4gamF2YS5sYW5nLkls bGVnYWxBcmd1bWVudEV4Y2VwdGlvbjogRXJyb3I6IE1pc3NpbmcgJ1snIGF0ICJcXHUyMDBkfCBc XHUyMDBjIgo+IAlhdCBjb20uaWJtLmljdS50ZXh0LlVuaWNvZGVTZXQuc3ludGF4RXJyb3IoVW5p Y29kZVNldC5qYXZhOjI2NTApCj4gCWF0IGNvbS5pYm0uaWN1LnRleHQuVW5pY29kZVNldC5hcHBs eVBhdHRlcm4oVW5pY29kZVNldC5qYXZhOjI0NjYpCj4gCWF0IGNvbS5pYm0uaWN1LnRleHQuVW5p Y29kZVNldC5hcHBseVBhdHRlcm4oVW5pY29kZVNldC5qYXZhOjIyNjMpCj4gCWF0IGNvbS5pYm0u aWN1LnRleHQuVW5pY29kZVNldC4oVW5pY29kZVNldC5qYXZhOjM2NykKPiAJYXQgb3JnLnVuaWNv ZGUuY2xkci50ZXN0LkV4YW1wbGVHZW5lcmF0b3IuZ2V0RXhhbXBsZUh0bWwoRXhhbXBsZUdlbmVy YXRvci5qYXZhOjI1OCkKPiAJYXQgb3JnLnVuaWNvZGUuY2xkci53ZWIuU3VydmV5TWFpbi5wcmlu dENlbGxzKFN1cnZleU1haW4uamF2YTo1ODMyKQo+IAlhdCBvcmcudW5pY29kZS5jbGRyLndlYi5T dXJ2ZXlNYWluLnNob3dQZWEoU3VydmV5TWFpbi5qYXZhOjU1OTgpCj4gCWF0IG9yZy51bmljb2Rl LmNsZHIud2ViLlN1cnZleU1haW4uc2hvd1BlYXMoU3VydmV5TWFpbi5qYXZhOjQ2MjkpCj4gCWF0 IG9yZy51bmljb2RlLmNsZHIud2ViLlN1cnZleU1haW4uc2hvd1BlYXMoU3VydmV5TWFpbi5qYXZh OjQ0NDMpCj4gCWF0IG9yZy51bmljb2RlLmNsZHIud2ViLlN1cnZleUZvcnVtLnNob3dYcGF0aChT dXJ2ZXlGb3J1bS5qYXZhOjQ1MCkKPiAJYXQgb3JnLnVuaWNvZGUuY2xkci53ZWIuU3VydmV5Rm9y dW0uZG9YcGF0aFBvc3QoU3VydmV5Rm9ydW0uamF2YTo0MTgpCj4gCWF0IG9yZy51bmljb2RlLmNs ZHIud2ViLlN1cnZleUZvcnVtLmRvRm9ydW0oU3VydmV5Rm9ydW0uamF2YToxOTMpCj4gCWF0IG9y Zy51bmljb2RlLmNsZHIud2ViLlN1cnZleU1haW4uZG9TZXNzaW9uKFN1cnZleU1haW4uamF2YToy Njk0KQo+IAlhdCBvcmcudW5pY29kZS5jbGRyLndlYi5TdXJ2ZXlNYWluLmRvR2V0KFN1cnZleU1h aW4uamF2YTo0MDgpCj4gCWF0IGphdmF4LnNlcnZsZXQuaHR0cC5IdHRwU2VydmxldC5zZXJ2aWNl KEh0dHBTZXJ2bGV0LmphdmE6Njg5KQo+IAlhdCBqYXZheC5zZXJ2bGV0Lmh0dHAuSHR0cFNlcnZs ZXQuc2VydmljZShIdHRwU2VydmxldC5qYXZhOjgwMikKPiAJYXQgb3JnLmFwYWNoZS5jYXRhbGlu YS5jb3JlLkFwcGxpY2F0aW9uRmlsdGVyQ2hhaW4uaW50ZXJuYWxEb0ZpbHRlcihBcHBsaWNhdGlv bkZpbHRlckNoYWluLmphdmE6MjUyKQo+IAlhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuQXBw bGljYXRpb25GaWx0ZXJDaGFpbi5kb0ZpbHRlcihBcHBsaWNhdGlvbkZpbHRlckNoYWluLmphdmE6 MTczKQo+IAlhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuU3RhbmRhcmRXcmFwcGVyVmFsdmUu aW52b2tlKFN0YW5kYXJkV3JhcHBlclZhbHZlLi5qYXZhOjIxMykKPiAJYXQgb3JnLmFwYWNoZS5j YXRhbGluYS5jb3JlLlN0YW5kYXJkQ29udGV4dFZhbHZlLmludm9rZShTdGFuZGFyZENvbnRleHRW YWx2ZS4uamF2YToxNzgpCj4gCWF0IG9yZy5hcGFjaGUuY2F0YWxpbmEuY29yZS5TdGFuZGFyZEhv c3RWYWx2ZS5pbnZva2UoU3RhbmRhcmRIb3N0VmFsdmUuamF2YToxMjYpCj4gCWF0IG9yZy5hcGFj aGUuY2F0YWxpbmEudmFsdmVzLkVycm9yUmVwb3J0VmFsdmUuaW52b2tlKEVycm9yUmVwb3J0VmFs dmUuamF2YToxMDUpCj4gCWF0IG9yZy5hcGFjaGUuY2F0YWxpbmEuY29yZS5TdGFuZGFyZEVuZ2lu ZVZhbHZlLmludm9rZShTdGFuZGFyZEVuZ2luZVZhbHZlLmphdmE6MTA3KQo+IAlhdCBvcmcuYXBh Y2hlLmNhdGFsaW5hLmNvbm5lY3Rvci5Db3lvdGVBZGFwdGVyLnNlcnZpY2UoQ295b3RlQWRhcHRl ci5qYXZhOjE0OCkKPiAJYXQgb3JnLmFwYWNoZS5jb3lvdGUuYWpwLkFqcEFwclByb2Nlc3Nvci5w cm9jZXNzKEFqcEFwclByb2Nlc3Nvci5qYXZhOjQyNSkKPiAJYXQgb3JnLmFwYWNoZS5jb3lvdGUu YWpwLkFqcEFwclByb3RvY29sJEFqcENvbm5lY3Rpb25IYW5kbGVyLnByb2Nlc3MoQWpwQXByUHJv dG9jb2wuamF2YTo0NTIpCj4gCWF0IG9yZy5hcGFjaGUudG9tY2F0LnV0aWwubmV0LkFwckVuZHBv aW50JFdvcmtlci5ydW4oQXByRW5kcG9pbnQuamF2YToxMjg1KQo+IAlhdCBqYXZhLmxhbmcuVGhy ZWFkLnJ1bihUaHJlYWQuamF2YTo1OTUpCj4KPiBTZWNvbmRseSwgaXMgaXQgcG9zc2libGUgdG8g b3ZlcnJpZGUgYSBwcm9wb3NlZCBlbnRyeSAgdGhhdCBpICBtYWRlICBpbgo+IGF1eGlsaWFyeSBl eGVtcGxhciBsaXN0IGFuZCBob3c/Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwo+IFNjYW5uZWQgYW5kIHByb3RlY3RlZCBieSBFbWFpbCBzY2FubmVyCj4KPgo+CgoK LS0gCk1hcmsK ------=_Part_15461_4482349.1176310423482 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WW91IHNob3VsZCBwb3N0IHF1ZXN0aW9ucyBsaWtlIHRoaXMgdG8gPGEgaHJlZj0ibWFpbHRvOmNs ZHItdXNlcnNAdW5pY29kZS5vcmciPmNsZHItdXNlcnNAdW5pY29kZS5vcmc8L2E+LiA8YnI+PGJy PkkmIzM5O2xsIGdvIGFoZWFkIGFuZCBhbnN3ZXIgaGVyZSBmb3Igc2ltcGxpY2l0eS4gVGhlIG1p c3Rha2UgdGhhdCByZXN1bHRlZCB3YXMgbm90IGNvbm5lY3RlZCB3aXRoIHRoZSBcdSBub3RhdGlv bjsgaXQgd2FzIGEgbWlzc2luZyAmcXVvdDtbJnF1b3Q7LiBBIHNldCBvZiBjaGFyYWN0ZXJzIG5l ZWRzIHRvIGJlIG9mIHRoZSBmb3JtICZxdW90O1thLWIgbS1wXSZxdW90Oywgbm90IGp1c3QgJnF1 b3Q7YS1iIG0tcCZxdW90Oy4gV2UgZG8gdXNlIFx1IG5vdGF0aW9uIGZvciB0aG9zZSBjaGFyYWN0 ZXJzIHRoYXQgYXJlIG5vdCBub3JtYWxseSB2aXNpYmxlICh3aGl0ZXNwYWNlIGFuZCBkZWZhdWx0 IGlnbm9yYWJsZSBjaGFyYWN0ZXJzKS4gRXhlbXBsYXIgY2hhcmFjdGVycyBpbiBDTERSIG5vcm1h bGx5IG9ubHkgaW5jbHVkZSBsZXR0ZXJzLCBhbmQgdGh1cyBkb24mIzM5O3QgbmVlZCB0aGUgam9p bmVyIGNoYXJhY3RlcnMKPGJyPjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OiA0MHB4OyI+PGNvZGU+ PGEgdGFyZ2V0PSJjIiBocmVmPSJodHRwOi8vdW5pY29kZS5vcmcvY2xkci91dGlsaXR5L2NoYXJh Y3Rlci5qc3A/YT0yMDBDIj4yMDBDPC9hPjwvY29kZT4gKCDilqAgKSBaRVJPIFdJRFRIIE5PTi1K T0lORVI8YnI+PGNvZGU+PGEgdGFyZ2V0PSJjIiBocmVmPSJodHRwOi8vdW5pY29kZS5vcmcvY2xk ci91dGlsaXR5L2NoYXJhY3Rlci5qc3A/YT0yMDBEIj4KMjAwRDwvYT48L2NvZGU+ICgg4pagICkg WkVSTyBXSURUSCBKT0lORVI8YnI+PC9kaXY+CldlIG1heSwgaG93ZXZlciwgdGlnaHRlbiB0aGF0 IHVwIGluIGNvbmp1bmN0aW9uIHdpdGggPGEgaHJlZj0iaHR0cDovL3d3dy51bmljb2RlLm9yZy9y ZXZpZXcvI3ByaTk2Ij5odHRwOi8vd3d3LnVuaWNvZGUub3JnL3Jldmlldy8jcHJpOTY8L2E+Ljxi cj48YnI+TWFyazxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDQvMTAv MDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj4KQmFsYXNhbmthcjwvYj4gJmx0OzxhIGhy ZWY9Im1haWx0bzpiYWxhc2Fua2FyQGNkYWN0dm0uaW4iPmJhbGFzYW5rYXJAY2RhY3R2bS5pbjwv YT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQg MHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KCgoKCgoKPGRpdiBiZ2NvbG9yPSIj ZmZmZmZmIj4KPGRpdj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+SXMgaXQgcG9zc2libGUg dG8gYWRkJm5ic3A7Jm5ic3A7YSBjaGFyYWN0ZXIgYXMgClx1K3Vub2NvZGUgdmFsdWUgZXg6IFx1 MjAwZCZuYnNwOyBpbiBhdXhpbGlhcnkgZXhlbXBsYXIgbGlzdD8gVGhlIApmb2xsb3dpbmcmbmJz cDsgZXJyb3Igb2NjdXJyZWQgd2hlbiZuYnNwO0kgdHJpZWQgdG8gZG8gdGhlIGFib3ZlLjwvZm9u dD48L2Rpdj4KPGRpdj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PC9mb250PjxwcmUgc3R5 bGU9ImJvcmRlcjogMnB4IGRhc2hlZCByZWQ7IG1hcmdpbjogMWVtOyI+PGZvbnQgZmFjZT0iQXJp YWwiIHNpemU9IjIiPmphdmEubGFuZy5JbGxlZ2FsQXJndW1lbnRFeGNlcHRpb246IEVycm9yOiBN aXNzaW5nICYjMzk7WyYjMzk7IGF0ICZxdW90O1xcdTIwMGR8IFxcdTIwMGMmcXVvdDs8YnI+amF2 YS5sYW5nLklsbGVnYWxBcmd1bWVudEV4Y2VwdGlvbgo6IEVycm9yOiBNaXNzaW5nICYjMzk7WyYj Mzk7IGF0ICZxdW90O1xcdTIwMGR8IFxcdTIwMGMmcXVvdDs8YnI+CWF0IGNvbS5pYm0uaWN1LnRl eHQuVW5pY29kZVNldC5zeW50YXhFcnJvcihVbmljb2RlU2V0LmphdmE6MjY1MCk8YnI+CWF0IGNv bS5pYm0uaWN1LnRleHQuVW5pY29kZVNldC5hcHBseVBhdHRlcm4oVW5pY29kZVNldC5qYXZhOjI0 NjYpPGJyPglhdCBjb20uaWJtLmljdS50ZXh0LlVuaWNvZGVTZXQuYXBwbHlQYXR0ZXJuCihVbmlj b2RlU2V0LmphdmE6MjI2Myk8YnI+CWF0IGNvbS5pYm0uaWN1LnRleHQuVW5pY29kZVNldC4oVW5p Y29kZVNldC5qYXZhOjM2Nyk8YnI+CWF0IG9yZy51bmljb2RlLmNsZHIudGVzdC5FeGFtcGxlR2Vu ZXJhdG9yLmdldEV4YW1wbGVIdG1sKEV4YW1wbGVHZW5lcmF0b3IuamF2YToyNTgpPGJyPglhdCBv cmcudW5pY29kZS5jbGRyLndlYi5TdXJ2ZXlNYWluLnByaW50Q2VsbHMoU3VydmV5TWFpbi5qYXZh Cjo1ODMyKTxicj4JYXQgb3JnLnVuaWNvZGUuY2xkci53ZWIuU3VydmV5TWFpbi5zaG93UGVhKFN1 cnZleU1haW4uamF2YTo1NTk4KTxicj4JYXQgb3JnLnVuaWNvZGUuY2xkci53ZWIuU3VydmV5TWFp bi5zaG93UGVhcyhTdXJ2ZXlNYWluLmphdmE6NDYyOSk8YnI+CWF0IG9yZy51bmljb2RlLmNsZHIu d2ViLlN1cnZleU1haW4uc2hvd1BlYXMoU3VydmV5TWFpbi5qYXZhOjQ0NDMpPGJyPglhdCAKb3Jn LnVuaWNvZGUuY2xkci53ZWIuU3VydmV5Rm9ydW0uc2hvd1hwYXRoKFN1cnZleUZvcnVtLmphdmE6 NDUwKTxicj4JYXQgb3JnLnVuaWNvZGUuY2xkci53ZWIuU3VydmV5Rm9ydW0uZG9YcGF0aFBvc3Qo U3VydmV5Rm9ydW0uamF2YTo0MTgpPGJyPglhdCBvcmcudW5pY29kZS5jbGRyLndlYi5TdXJ2ZXlG b3J1bS5kb0ZvcnVtKFN1cnZleUZvcnVtLmphdmE6MTkzKTxicj4JYXQgb3JnLnVuaWNvZGUuY2xk ci53ZWIuU3VydmV5TWFpbi5kb1Nlc3Npb24KKFN1cnZleU1haW4uamF2YToyNjk0KTxicj4JYXQg b3JnLnVuaWNvZGUuY2xkci53ZWIuU3VydmV5TWFpbi5kb0dldChTdXJ2ZXlNYWluLmphdmE6NDA4 KTxicj4JYXQgamF2YXguc2VydmxldC5odHRwLkh0dHBTZXJ2bGV0LnNlcnZpY2UoSHR0cFNlcnZs ZXQuamF2YTo2ODkpPGJyPglhdCBqYXZheC5zZXJ2bGV0Lmh0dHAuSHR0cFNlcnZsZXQuc2Vydmlj ZShIdHRwU2VydmxldC5qYXZhOjgwMikKPGJyPglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUu QXBwbGljYXRpb25GaWx0ZXJDaGFpbi5pbnRlcm5hbERvRmlsdGVyKEFwcGxpY2F0aW9uRmlsdGVy Q2hhaW4uamF2YToyNTIpPGJyPglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuQXBwbGljYXRp b25GaWx0ZXJDaGFpbi5kb0ZpbHRlcihBcHBsaWNhdGlvbkZpbHRlckNoYWluLmphdmE6MTczKTxi cj4JYXQgb3JnLmFwYWNoZS5jYXRhbGluYS5jb3JlLlN0YW5kYXJkV3JhcHBlclZhbHZlLmludm9r ZQooU3RhbmRhcmRXcmFwcGVyVmFsdmUuLmphdmE6MjEzKTxicj4JYXQgb3JnLmFwYWNoZS5jYXRh bGluYS5jb3JlLlN0YW5kYXJkQ29udGV4dFZhbHZlLmludm9rZShTdGFuZGFyZENvbnRleHRWYWx2 ZS4uamF2YToxNzgpPGJyPglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuU3RhbmRhcmRIb3N0 VmFsdmUuaW52b2tlKFN0YW5kYXJkSG9zdFZhbHZlLmphdmE6MTI2KTxicj4JYXQgb3JnLmFwYWNo ZS5jYXRhbGluYS52YWx2ZXMuRXJyb3JSZXBvcnRWYWx2ZS5pbnZva2UKKEVycm9yUmVwb3J0VmFs dmUuamF2YToxMDUpPGJyPglhdCBvcmcuYXBhY2hlLmNhdGFsaW5hLmNvcmUuU3RhbmRhcmRFbmdp bmVWYWx2ZS5pbnZva2UoU3RhbmRhcmRFbmdpbmVWYWx2ZS5qYXZhOjEwNyk8YnI+CWF0IG9yZy5h cGFjaGUuY2F0YWxpbmEuY29ubmVjdG9yLkNveW90ZUFkYXB0ZXIuc2VydmljZShDb3lvdGVBZGFw dGVyLmphdmE6MTQ4KTxicj4JYXQgb3JnLmFwYWNoZS5jb3lvdGUuYWpwLkFqcEFwclByb2Nlc3Nv ci5wcm9jZXNzCihBanBBcHJQcm9jZXNzb3IuamF2YTo0MjUpPGJyPglhdCBvcmcuYXBhY2hlLmNv eW90ZS5hanAuQWpwQXByUHJvdG9jb2wkQWpwQ29ubmVjdGlvbkhhbmRsZXIucHJvY2VzcyhBanBB cHJQcm90b2NvbC5qYXZhOjQ1Mik8YnI+CWF0IG9yZy5hcGFjaGUudG9tY2F0LnV0aWwubmV0LkFw ckVuZHBvaW50JFdvcmtlci5ydW4oQXByRW5kcG9pbnQuamF2YToxMjg1KTxicj4JYXQgamF2YS5s YW5nLlRocmVhZC5ydW4KKFRocmVhZC5qYXZhOjU5NSk8YnI+PC9mb250PjwvcHJlPjwvZGl2Pgo8 ZGl2Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIj5TZWNvbmRseSwmbmJzcDtpcyBpdCBwb3Nz aWJsZSB0byBvdmVycmlkZSBhIApwcm9wb3NlZCZuYnNwO2VudHJ5ICZuYnNwO3RoYXQgaSZuYnNw OyBtYWRlJm5ic3A7IGluIGF1eGlsaWFyeSBleGVtcGxhciBsaXN0IGFuZCAKaG93PzwvZm9udD48 L2Rpdj48YnI+PHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5T Y2FubmVkIGFuZCBwcm90ZWN0ZWQgYnkgRW1haWwgc2Nhbm5lcjxicj48L3ByZT48YnI+CjwvZGl2 Pgo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPk1hcmsK ------=_Part_15461_4482349.1176310423482-- From laurentiu.iancu@gmail.com Sat Apr 14 18:09:33 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Sat, 14 Apr 2007 20:22:47 -0600 (CST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3F09WGA007606 for ; Sat, 14 Apr 2007 18:09:32 -0600 Received: by an-out-0708.google.com with SMTP id d18so1547731and for ; Sat, 14 Apr 2007 17:09:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=RWyqce0IQafBiTgKBIiTfEljpkL3twnMlk3qYDZciOk+PGGzFocr2HPqcYbA4OF7GWns+syDa5jBt2rEEC5v0fkjwU43Y2f/LvrhlltBqVfVrsgesNjUGHWEpILu1l3SaObhqUveLLdLSAc5A+aqp+Bi8gp1WNND62NLoma8bBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=s5ILXucIV4hB9ywxJasNYMRpHcolQK6q9MVTqcDeaOB4G8xzPlGihZaAbj58+gAehFuiCm4MweXNGkr4eu6RU9NqOHfh6WYq/XCK5ohn00Ap6EBlzPfBzeqS4PJcikfUefrmt1+jAovRoytnRnvp4v36n7iSk9hci3OEUKTSJ+s= Received: by 10.100.32.1 with SMTP id f1mr3498442anf.1176595772386; Sat, 14 Apr 2007 17:09:32 -0700 (PDT) Received: by 10.100.132.4 with HTTP; Sat, 14 Apr 2007 17:09:32 -0700 (PDT) Message-ID: <73b935100704141709y371b53d3u216e535a510aae1@mail.gmail.com> Date: Sat, 14 Apr 2007 17:09:32 -0700 From: "Laurentiu Iancu" To: cldr-users@unicode.org Subject: Deleting incorrect entries MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_27811_30114298.1176595772343" X-Google-Sender-Auth: 890244c179697b0b X-archive-position: 74 X-Approved-By: root@unicode.org X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: iancu@quickref.info Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users ------=_Part_27811_30114298.1176595772343 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, While entering data in the Romanian locale, I came across an incorrect entry, viz. Sundanese (0-names|language|su), translated as "sudaneza," which is disturbingly wrong. Although a name for the language may be formed, which would sound like the natural translation, I was not able to confirm it in any bibliographical source I have. I would much rather leave an entry blank than have it populated with an incorrect translation or with an unconfirmed one. There might be other such instances, hence the question whether it is possible to delete entries. I posted a comment on the forum, but I am not sure if that suffices. Thank you, L. ------=_Part_27811_30114298.1176595772343 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello,
 
While entering data in the Romanian locale, I came across an incorrect entry, viz. Sundanese (0-names|language|su), translated as "sudaneza," which is disturbingly wrong.  Although a name for the language may be formed, which would sound like the natural translation, I was not able to confirm it in any bibliographical source I have.
 
I would much rather leave an entry blank than have it populated with an incorrect translation or with an unconfirmed one.  There might be other such instances, hence the question whether it is possible to delete entries.  I posted a comment on the forum, but I am not sure if that suffices.
 
Thank you,
L.
------=_Part_27811_30114298.1176595772343-- From srl@icu-project.org Sat Apr 14 20:31:27 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Sat, 14 Apr 2007 20:31:27 -0600 (CST) Received: from v.icu-project.org (v.icu-project.org [161.58.210.87]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3F2VNeW012683 for ; Sat, 14 Apr 2007 20:31:27 -0600 Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.112]) by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HcuWQ-000FRi-NB for cldr-users@unicode.org; Sun, 15 Apr 2007 02:31:22 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <73b935100704141709y371b53d3u216e535a510aae1@mail.gmail.com> References: <73b935100704141709y371b53d3u216e535a510aae1@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E59DE46-2BA7-44E4-A36C-5142325DBE7A@icu-project.org> Content-Transfer-Encoding: 7bit From: "Steven R. Loomis" Subject: Re: Deleting incorrect entries Date: Sat, 14 Apr 2007 19:31:09 -0700 To: cldr-users@unicode.org X-Mailer: Apple Mail (2.752.3) X-archive-position: 75 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: srl@icu-project.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users If it is disturbingly wrong, and you don't have a replacement, vote for "su" as a code, then. (click on the button next to "su") That's the equivalent of not having any translation at all. No, posting to the forum is only for discussion amongst the language experts of that forum. It's better to use the feedback form at the bottom of the page. -s On 14 Apr 2007, at 17:09, Laurentiu Iancu wrote: > Hello, > > While entering data in the Romanian locale, I came across an > incorrect entry, viz. Sundanese (0-names|language|su), translated > as "sudaneza," which is disturbingly wrong. Although a name for > the language may be formed, which would sound like the natural > translation, I was not able to confirm it in any bibliographical > source I have. > > I would much rather leave an entry blank than have it populated > with an incorrect translation or with an unconfirmed one. There > might be other such instances, hence the question whether it is > possible to delete entries. I posted a comment on the forum, but I > am not sure if that suffices. > > Thank you, > L. From mnita@adobe.com Mon Apr 16 10:34:34 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 16 Apr 2007 10:34:34 -0600 (CST) Received: from exprod6og54.obsmtp.com (exprod6og54.obsmtp.com [64.18.1.189]) by unicode.org (8.13.4/8.12.11) with SMTP id l3GGYPD2025417 for ; Mon, 16 Apr 2007 10:34:25 -0600 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 16 Apr 2007 09:34:24 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3GGYMSd008111 for ; Mon, 16 Apr 2007 09:34:22 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3GGYJ0g024423 for ; Mon, 16 Apr 2007 09:34:22 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 09:34:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78045.1539534E" Subject: RE: Deleting incorrect entries Date: Mon, 16 Apr 2007 09:34:17 -0700 Message-ID: <7C02371BEF08D3489AA6EAD7C0E25CCB01775A9B@namail1.corp.adobe.com> In-reply-to: <73b935100704141709y371b53d3u216e535a510aae1@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Deleting incorrect entries Thread-Index: Acd/BQe59hV8f73KRXGACYhxoh9CLwBP3Tlw References: <73b935100704141709y371b53d3u216e535a510aae1@mail.gmail.com> From: "Mihai Nita" To: X-OriginalArrivalTime: 16 Apr 2007 16:34:19.0954 (UTC) FILETIME=[152A4920:01C78045] X-archive-position: 76 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: mnita@adobe.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users This is a multi-part message in MIME format. ------_=_NextPart_001_01C78045.1539534E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, I post here, but I only got this message from the list, I don't = have the email of Laurentiu Iancu: =20 I was able to find this is DEX (the equivalent of Webster for = Romanian). And I was able to find a lot of references on the web, including a = company offering translation from Romanian to "sudaneza" (I would assume = they know what they are talking about) =20 How is that "disturbingly wrong"? =20 What kind of bibliographical source are you looking for? =20 Regards, Mihai =20 PS. To continue the discussion outside this list, my address is = mnita@adobe.com ________________________________ From: cldr-users-bounce@unicode.org = [mailto:cldr-users-bounce@unicode.org] On Behalf Of Laurentiu Iancu Sent: Saturday, April 14, 2007 5:10 PM To: cldr-users@unicode.org Subject: Deleting incorrect entries =09 =09 Hello, =20 While entering data in the Romanian locale, I came across an incorrect = entry, viz. Sundanese (0-names|language|su), translated as "sudaneza," = which is disturbingly wrong. Although a name for the language may be = formed, which would sound like the natural translation, I was not able = to confirm it in any bibliographical source I have.=20 =20 I would much rather leave an entry blank than have it populated with an = incorrect translation or with an unconfirmed one. There might be other = such instances, hence the question whether it is possible to delete = entries. I posted a comment on the forum, but I am not sure if that = suffices.=20 =20 Thank you, L. ------_=_NextPart_001_01C78045.1539534E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sorry, I post here, but I only got this message from the list, = I don't=20 have the email of Laurentiu Iancu:
 
 I was able to find this is DEX (the equivalent of Webster = for=20 Romanian).
And I was able to find a lot of references on the web, = including a=20 company offering translation from Romanian to "sudaneză" (I would = assume they=20 know what they are talking about)
 
How is that "disturbingly wrong"?
 
What kind of bibliographical source are you looking=20 for?
 
Regards,
Mihai
 
PS. To continue the discussion outside this list, my address is = mnita@adobe.com
From: = cldr-users-bounce@unicode.org=20 [mailto:cldr-users-bounce@unicode.org] On Behalf Of Laurentiu=20 Iancu
Sent: Saturday, April 14, 2007 5:10 PM
To:=20 cldr-users@unicode.org
Subject: Deleting incorrect=20 entries

Hello,
 
While entering data in the Romanian locale, I came across an = incorrect=20 entry, viz. Sundanese (0-names|language|su), translated as "sudaneza," = which=20 is disturbingly wrong.  Although a name for the language may be = formed,=20 which would sound like the natural translation, I was not able to = confirm it=20 in any bibliographical source I have.
 
I would much rather leave an entry blank than have it populated = with an=20 incorrect translation or with an unconfirmed one.  There might be = other=20 such instances, hence the question whether it is possible to delete=20 entries.  I posted a comment on the forum, but I am not sure if = that=20 suffices.
 
Thank you,
L.
------_=_NextPart_001_01C78045.1539534E-- From rick@unicode.org Mon Apr 16 14:23:17 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 16 Apr 2007 14:26:58 -0600 (CST) Received: from izanami (c-67-188-204-169.hsd1.ca.comcast.net [67.188.204.169]) by unicode.org (8.13.4/8.12.11) with SMTP id l3GKN4nQ030743; Mon, 16 Apr 2007 14:23:07 -0600 Message-Id: <200704162023.l3GKN4nQ030743@unicode.org> To: unicode@unicode.org Subject: New Public Review Issue: UAX #11 update Date: Mon, 16 Apr 2007 13:23:09 -0700 From: Rick McGowan received: by Apple.Mailer (2.95.2) X-archive-position: 77 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: rick@unicode.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users The Unicode Technical Committee has posted a new issue for public review and comment. Details are on the following web page: http://www.unicode.org/review/ Review periods for the new item closes on May 8, 2007. Please see the page for links to discussion and relevant documents. Briefly, the new issue is: 106 Proposed Update to UAX #11: East Asian Width http://www.unicode.org/reports/tr11/tr11-16.html This proposed update adds a note on the lack of canonical equivalence for the assignment of the EAW=ambiguous property to characters, and clarifies the status of such characters at several points in the text. If you have comments for official UTC consideration, please post them by submitting your comments through our feedback & reporting page: http://www.unicode.org/reporting.html If you wish to discuss issues on the Unicode mail list, then please use the following link to subscribe (if necessary). Please be aware that discussion comments on the Unicode mail list are not automatically recorded as input to the UTC. You must use the reporting link above to generate comments for UTC consideration. http://www.unicode.org/consortium/distlist.html Regards, Rick McGowan Unicode, Inc. From richard.wordingham@ntlworld.com Mon Apr 16 16:02:23 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 16 Apr 2007 16:52:01 -0600 (CST) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3GM2Mhm026506 for ; Mon, 16 Apr 2007 16:02:22 -0600 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20070416220230.MINO19810.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Mon, 16 Apr 2007 23:02:30 +0100 Received: from JRWXP1 ([82.18.16.213]) by aamtaout02-winn.ispmail.ntl.com with SMTP id <20070416220225.LLET17393.aamtaout02-winn.ispmail.ntl.com@JRWXP1> for ; Mon, 16 Apr 2007 23:02:25 +0100 Message-ID: <003901c78067$5d2a7980$d5101252@JRWXP1> From: "Richard Wordingham" To: Subject: LDML Collation Semantics Date: Mon, 16 Apr 2007 21:39:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-archive-position: 78 X-Approved-By: v-magdad@microsoft.com X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: richard.wordingham@ntlworld.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users I'm having a little trouble understanding one of the Locale Data Markup Language (LDML) collation definitions. To clarify my uncertainty, I have considered a modification of one of the examples from UTS 35, but with a combining macron instead of a hyphen. The hypothetical collation uses default settings and has a single tailoring: oo (This sort of rule would make sense in collating transliterated material written with varying degrees of ASCIIfication.) What then is the relative ordering of the three strings ǭd , oǫd , and ǫod ? I can argue for all three possible outcomes! The answer depends on the second level weights, which I will designate as 'std' (the element for 'o' and 'd'), 'og' (the element for ogonek), and 'alt', the second level weight in the collation elements implicitly defined by the locale definitions. The definitions (e.g UTS #35 Version 1.4.1 Section 5.13.7) are such that std < alt. If the well-formedness condition 2 from UTS #10 'Unicode Collation Algorithm' Version 5.0 holds, in particular 'Given collation elements [C, D, E] and [0, A, B], where C ≠ 0 and A ≠ 0, then D must be less than A', we will furthermore have std < alt < og. Answer A: The tailoring defines a contraction for ō but not ǫ, and the second level weights of ō are , so the sort order and second level weights are: oǫd ǭd ǫod . Answer B: The example in UTS 35, reads: "For example, suppose that "-" is sorted like the previous vowel. Then one could have rules that take "a-", "e-", and so on. However, that means that every time a very common character (a, e, ...) is encountered, a system will slow down as it looks for possible contractions. An alternative is to indicate that when "-" is encountered, and it comes after an 'a', it sorts like an 'a', etc." That suggests that a contraction is not employed, so that in deriving the sort key from ǭd, when the sequence <'o', combining ogonek, combining macron> is processed to yield a sort key, it is processed as <'o', combining ogonek, character with secondary difference from 'o'>, and thus the collating order and second order weights is oǫd ǫod ǭd I don't believe the behaviour I am assuming can be achieved with a finite collation element table - but does the UCA require that the collation element table be finite? Answer C: The argument proceeds as for B, but then says that as the combining macron does not immediately follow 'o', there is no special treatment. This is consistent with the UCA - one 'merely' defines an otherwise redundant contraction in the collation element table for 'o' and all the other characters with non-zero combining class. The collation order is then ǭd, oǫd, ǫod, and is determined by the primary weights! Answer A seems the most plausible - however, it does not seem to be equivalent to a definition by 'contractions and expansions'. I presume the alternative method referred to is: ooō The primary weights for ō and 'oo' would be the same; the secondary weights would be and . But then the collating order and weights would be: oǫd ǫod ǭd . - same order as Answer B above! I'm confused. What is the meaning of oo - or is the construct meaningless for a character of non-zero combining class? Richard. From mark.edward.davis@gmail.com Mon Apr 16 19:09:18 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 16 Apr 2007 19:09:18 -0600 (CST) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.227]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3H19INf031235 for ; Mon, 16 Apr 2007 19:09:18 -0600 Received: by nz-out-0506.google.com with SMTP id s18so1671330nze for ; Mon, 16 Apr 2007 18:09:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=UTbzmYzAHWgVYlzmVUBodxoKOd4j0FBbzs4wz7LMPNYJ9rD/1vWKkaKLnEUVzoX7eo9Fve7VlbzkcMDpdtgKSfJGp+dVnASxyIZ0xpUh+1IlLGJk6PDecCByYXThXSee15qKI0JlrCk2BZY9Aw3rZtt9AnepClVOaLevGxR/8rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=auXdrD9fY1Lca2hzTB1F0mRNry4ZBceXPeuWquCADXyIN5UwrObj79/MWfG07ZBr1R1h9DQIbuvCWddKgKsFlu2LxoS4gI3iqByXLVXiOnCS2J0MkwHNL7U42Yl2lReRd//IKeGjlUKAFyXsdzB3HE+efwbnmeNVu0c3R4gQiRU= Received: by 10.114.113.1 with SMTP id l1mr2165243wac.1176772157705; Mon, 16 Apr 2007 18:09:17 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 16 Apr 2007 18:09:17 -0700 (PDT) Message-ID: <30b660a20704161809k249f3997k89522e63c87acd16@mail.gmail.com> Date: Mon, 16 Apr 2007 18:09:17 -0700 From: "Mark Davis" To: cldr-users@unicode.org, "Kenneth Whistler" Subject: Re: LDML Collation Semantics In-Reply-To: <003901c78067$5d2a7980$d5101252@JRWXP1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_64513_24250038.1176772157633" References: <003901c78067$5d2a7980$d5101252@JRWXP1> X-Google-Sender-Auth: 00c3ad03212858d2 X-archive-position: 79 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: mark.davis@icu-project.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users ------=_Part_64513_24250038.1176772157633 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline V2hhdCA8cmVzZXQ+bzwvcmVzZXQ+PHg+PGNvbnRleHQ+bzwvY29udGV4dD48cz48Y3AgaGV4PSIw MzA0Ij48L3M+PC94PiBtZWFucwppczoKCmlmIHlvdSBlbmNvdW50ZXIgYSBVKzAzMDQgYWZ0ZXIg YW4gIm8iLCB0cmVhdCBpdCBhcyBhZnRlciBhbiAibyIgYXQgdGhlCnNlY29uZCBsZXZlbC4KClRo ZSBleGFtcGxlIHdvdWxkIGJlIGNsZWFyZXIgaWYgd2UgZGlkbid0IGhhdmUgdHdvIGluc3RhbmNl cyBvZiAibyIsIGFuZCBpZgp3ZSBoYWQgYW5vdGhlciBsZXR0ZXIgaW5zdGVhZCBvZiB0aGUgXHUw MzA0LiBJbXBvcnRhbnQgbm90ZTogaWYgd2UgdXNlZCBhClx1MDMwNCBpbiB0aGUgcnVsZSwgaXQg d291bGQgYmVoYXZlIHRoZSBzYW1lIHdheSBhcyB0aGUgImIiIGJlbG93IC0tIHRoZQpmYWN0IHRo YXQgaXQgaXMgYSBjb21iaW5pbmcgbWFyayBpcyBpbW1hdGVyaWFsIGluIHRoZSBydWxlcy4KCjxy ZXNldD5vPC9yZXNldD48eD48Y29udGV4dD5hPC9jb250ZXh0PjxzPmI8L3M+PC94PgoKU28gdGhp cyBzYXlzLCBpZiB5b3UgZW5jb3VudGVyIGEgImIiIGFmdGVyIGFuICJhIiwgdHJlYXQgaXQgYXMg YWZ0ZXIgYW4gIm8iCmF0IHRoZSBzZWNvbmQgbGV2ZWwuCgpTbyB3aGVuIHNvcnRpbmcsIHlvdSB3 aWxsIGdldDoKCmFvCmFPCmHDtAphYgphcAoKWW91IGNhbiBzZWUgdGhlIGVmZmVjdCBvZiB0aGUg c3RyZW5ndGggYnkgZ29pbmcgdG8KaHR0cDovL2RlbW8uaWN1LXByb2plY3Qub3JnL2ljdS1iaW4v bG9jZXhwP189ZW4mZF89ZW4meD1jb2wKClBhc3RlIHRoZSBhYm92ZSBpbnRvIFNvdXJjZSwgYW5k IHBhc3RlIHRoZSBydWxlCgomIG8gPDwgYSB8IGIKCmludG8gQ3VzdG9tIFJ1bGVzLiAodGhpcyBj b3JyZXNwb25kcyB0byB0aGUgc2Vjb25kIG9mIHRoZSBYTUwgcnVsZXMgYWJvdmUpLgpXaGVuIHlv dSBoaXQgU29ydCwgeW91IHdpbGwgc2VlOgoKMDE6IGFvCiAwMjogYU8KIDA0OiBhw7QKIDAzOiBh YgogMDU6IGFwCgoKU28gd2hhdCBpcyBnb2luZyBvbj8gVGhlIMO0IGlzIGludGVybmFsbHkgYmVp bmcgKGxvZ2ljYWxseSkgdHJlYXRlZCBhcyBvICsKY2lyY3VtZmxleCwgd2hlcmUgdGhlIGNpcmN1 bWZsZXggaXMgc29ydGVkIGF0IHRoZSBzZWNvbmRhcnkgbGV2ZWwuIFNvIHdoZW4KY29tcGFyaW5n IGxldHRlcnMgYXMgd2Ugd2FsayB0aHJvdWdoIGVhY2ggb2YgdGhlc2Ugc3RyaW5ncywgYXQgbGV0 dGVyICMyIHRoZQpiIGlzIGJlaW5nIGNvbXBhcmVkIHRvIGFuICJvIiwgYW5kIGl0IGNvbWVzIGFm dGVyd2FyZHMuCgpJZiB3ZSBjaGFuZ2UgdGhlIHN0cmVuZ3RoIG9mIHRoZSByZWxhdGlvbnNoaXAg dG8gdGVydGlhcnkKCiYgbyA8PDwgYSB8IGIKCndlIGdldAoKMDE6IGFvCiAwMzogYWIKIDAyOiBh TwogMDQ6IGHDtAogMDU6IGFwCgpXaXRob3V0IGtub3dpbmcgbW9yZSBhYm91dCB3aGF0IHlvdXIg aW50ZW5kZWQgcmVzdWx0IGlzLCBJIGNhbid0IGFkdmlzZSB5b3UKYW55IGZ1cnRoZXIgb24gaG93 IHRvIGdldCBpdC4KCk1hcmsKCk9uIDQvMTYvMDcsIFJpY2hhcmQgV29yZGluZ2hhbSA8cmljaGFy ZC53b3JkaW5naGFtQG50bHdvcmxkLmNvbT4gd3JvdGU6Cj4KPiBJJ20gaGF2aW5nIGEgbGl0dGxl IHRyb3VibGUgdW5kZXJzdGFuZGluZyBvbmUgb2YgdGhlIExvY2FsZSBEYXRhIE1hcmt1cAo+IExh bmd1YWdlIChMRE1MKSBjb2xsYXRpb24gZGVmaW5pdGlvbnMuIFRvIGNsYXJpZnkgbXkgdW5jZXJ0 YWludHksIEkgaGF2ZQo+IGNvbnNpZGVyZWQgYSBtb2RpZmljYXRpb24gb2Ygb25lIG9mIHRoZSBl eGFtcGxlcyBmcm9tIFVUUyAzNSwgYnV0IHdpdGggYQo+IGNvbWJpbmluZyBtYWNyb24gaW5zdGVh ZCBvZiBhIGh5cGhlbi4KPgo+IFRoZSBoeXBvdGhldGljYWwgY29sbGF0aW9uIHVzZXMgZGVmYXVs dCBzZXR0aW5ncyBhbmQgaGFzIGEgc2luZ2xlCj4gdGFpbG9yaW5nOgo+Cj4gPHJlc2V0Pm88L3Jl c2V0Pjx4Pjxjb250ZXh0Pm88L2NvbnRleHQ+PHM+PGNwIGhleD0iMDMwNCI+PC9zPjwveD4KPgo+ IChUaGlzIHNvcnQgb2YgcnVsZSB3b3VsZCBtYWtlIHNlbnNlIGluIGNvbGxhdGluZyB0cmFuc2xp dGVyYXRlZCBtYXRlcmlhbAo+IHdyaXR0ZW4gd2l0aCB2YXJ5aW5nIGRlZ3JlZXMgb2YgQVNDSUlm aWNhdGlvbi4pCj4KPiBXaGF0IHRoZW4gaXMgdGhlIHJlbGF0aXZlIG9yZGVyaW5nIG9mIHRoZSB0 aHJlZSBzdHJpbmdzICDHrWQgPFUrMDFFRCBMQVRJTgo+IFNNQUxMIExFVFRFUiBPIFdJVEggT0dP TkVLIEFORCBNQUNST04sIFUrMDA2NSBMQVRJTiBTTUFMTCBMRVRURVIgRD4sIG/Hq2QKPiA8VSsw MDZGIExBVElOIFNNQUxMIExFVFRFUiBPLCBVKzAxRUIgTEFUSU4gU01BTEwgTEVUVEVSIE8gV0lU SCBPR09ORUssCj4gVSswMDY1PiwgYW5kIMerb2QgPFUrMDFFQiwgVSswMDZGLCBVKzAwNjU+PyAg SSBjYW4gYXJndWUgZm9yIGFsbCB0aHJlZQo+IHBvc3NpYmxlIG91dGNvbWVzIQo+Cj4gVGhlIGFu c3dlciBkZXBlbmRzIG9uIHRoZSBzZWNvbmQgbGV2ZWwgd2VpZ2h0cywgd2hpY2ggSSB3aWxsIGRl c2lnbmF0ZSBhcwo+ICdzdGQnICh0aGUgZWxlbWVudCBmb3IgJ28nIGFuZCAnZCcpLCAnb2cnICh0 aGUgZWxlbWVudCBmb3Igb2dvbmVrKSwgYW5kCj4gJ2FsdCcsIHRoZSBzZWNvbmQgbGV2ZWwgd2Vp Z2h0IGluIHRoZSBjb2xsYXRpb24gZWxlbWVudHMgaW1wbGljaXRseQo+IGRlZmluZWQKPiBieSB0 aGUgbG9jYWxlIGRlZmluaXRpb25zLiAgVGhlIGRlZmluaXRpb25zIChlLmcgVVRTICMzNSBWZXJz aW9uIDEuNC4xCj4gU2VjdGlvbiA1LjEzLjcpIGFyZSBzdWNoIHRoYXQgc3RkIDwgYWx0LiAgSWYg dGhlIHdlbGwtZm9ybWVkbmVzcyBjb25kaXRpb24KPiAyCj4gZnJvbSBVVFMgIzEwICdVbmljb2Rl IENvbGxhdGlvbiBBbGdvcml0aG0nIFZlcnNpb24gNS4wIGhvbGRzLCBpbgo+IHBhcnRpY3VsYXIK PiAnR2l2ZW4gY29sbGF0aW9uIGVsZW1lbnRzIFtDLCBELCBFXSBhbmQgWzAsIEEsIEJdLCB3aGVy ZSBDIOKJoCAwIGFuZCBBIOKJoCAwLAo+IHRoZW4gRCBtdXN0IGJlIGxlc3MgdGhhbiBBJywgd2Ug d2lsbCBmdXJ0aGVybW9yZSBoYXZlIHN0ZCA8IGFsdCA8IG9nLgo+Cj4gQW5zd2VyIEE6Cj4KPiBU aGUgdGFpbG9yaW5nIGRlZmluZXMgYSBjb250cmFjdGlvbiBmb3IgxY0gYnV0IG5vdCDHqywgYW5k IHRoZSBzZWNvbmQgbGV2ZWwKPiB3ZWlnaHRzIG9mIMWNIGFyZSA8c3RkLCBhbHQ+LCBzbyB0aGUg c29ydCBvcmRlciBhbmQgc2Vjb25kIGxldmVsIHdlaWdodHMKPiBhcmU6Cj4KPiBvx6tkIDxzdGQs IHN0ZCwgb2csIHN0ZD4KPiDHrWQgICA8c3RkLCBhbHQsIG9nLCBzdGQ+Cj4gx6tvZCA8c3RkLCBv Zywgc3RkLCBzdGQ+Lgo+Cj4gQW5zd2VyIEI6Cj4KPiBUaGUgZXhhbXBsZSBpbiBVVFMgMzUsIHJl YWRzOgo+Cj4gIkZvciBleGFtcGxlLCBzdXBwb3NlIHRoYXQgIi0iIGlzIHNvcnRlZCBsaWtlIHRo ZSBwcmV2aW91cyB2b3dlbC4gVGhlbiBvbmUKPiBjb3VsZCBoYXZlIHJ1bGVzIHRoYXQgdGFrZSAi YS0iLCAiZS0iLCBhbmQgc28gb24uIEhvd2V2ZXIsIHRoYXQgbWVhbnMgdGhhdAo+IGV2ZXJ5IHRp bWUgYSB2ZXJ5IGNvbW1vbiBjaGFyYWN0ZXIgKGEsIGUsIC4uLikgaXMgZW5jb3VudGVyZWQsIGEg c3lzdGVtCj4gd2lsbAo+IHNsb3cgZG93biBhcyBpdCBsb29rcyBmb3IgcG9zc2libGUgY29udHJh Y3Rpb25zLiBBbiBhbHRlcm5hdGl2ZSBpcyB0bwo+IGluZGljYXRlIHRoYXQgd2hlbiAiLSIgaXMg ZW5jb3VudGVyZWQsIGFuZCBpdCBjb21lcyBhZnRlciBhbiAnYScsIGl0IHNvcnRzCj4gbGlrZSBh biAnYScsIGV0Yy4iCj4KPiBUaGF0IHN1Z2dlc3RzIHRoYXQgYSBjb250cmFjdGlvbiBpcyBub3Qg ZW1wbG95ZWQsIHNvIHRoYXQgaW4gZGVyaXZpbmcgdGhlCj4gc29ydCBrZXkgZnJvbSDHrWQsIHdo ZW4gdGhlIHNlcXVlbmNlIDwnbycsIGNvbWJpbmluZyBvZ29uZWssIGNvbWJpbmluZwo+IG1hY3Jv bj4gaXMgcHJvY2Vzc2VkIHRvIHlpZWxkIGEgc29ydCBrZXksIGl0IGlzIHByb2Nlc3NlZCBhcyA8 J28nLAo+IGNvbWJpbmluZwo+IG9nb25laywgY2hhcmFjdGVyIHdpdGggc2Vjb25kYXJ5IGRpZmZl cmVuY2UgZnJvbSAnbyc+LCBhbmQgdGh1cyB0aGUKPiBjb2xsYXRpbmcgb3JkZXIgYW5kIHNlY29u ZCBvcmRlciB3ZWlnaHRzIGlzCj4KPiBvx6tkIDxzdGQsIHN0ZCwgb2csIHN0ZD4KPiDHq29kIDxz dGQsIG9nLCBzdGQsIHN0ZD4KPiDHrWQgICA8c3RkLCBvZywgYWx0LCBzdGQ+Cj4KPiBJIGRvbid0 IGJlbGlldmUgdGhlIGJlaGF2aW91ciBJIGFtIGFzc3VtaW5nIGNhbiBiZSBhY2hpZXZlZCB3aXRo IGEgZmluaXRlCj4gY29sbGF0aW9uIGVsZW1lbnQgdGFibGUgLSBidXQgZG9lcyB0aGUgVUNBIHJl cXVpcmUgdGhhdCB0aGUgY29sbGF0aW9uCj4gZWxlbWVudCB0YWJsZSBiZSBmaW5pdGU/Cj4KPiBB bnN3ZXIgQzoKPgo+IFRoZSBhcmd1bWVudCBwcm9jZWVkcyBhcyBmb3IgQiwgYnV0IHRoZW4gc2F5 cyB0aGF0IGFzIHRoZSBjb21iaW5pbmcgbWFjcm9uCj4gZG9lcyBub3QgaW1tZWRpYXRlbHkgZm9s bG93ICdvJywgdGhlcmUgaXMgbm8gc3BlY2lhbCB0cmVhdG1lbnQuIFRoaXMgaXMKPiBjb25zaXN0 ZW50IHdpdGggdGhlIFVDQSAtIG9uZSAnbWVyZWx5JyBkZWZpbmVzIGFuIG90aGVyd2lzZSByZWR1 bmRhbnQKPiBjb250cmFjdGlvbiBpbiB0aGUgY29sbGF0aW9uIGVsZW1lbnQgdGFibGUgZm9yICdv JyBhbmQgYWxsIHRoZSBvdGhlcgo+IGNoYXJhY3RlcnMgd2l0aCBub24temVybyBjb21iaW5pbmcg Y2xhc3MuIFRoZSBjb2xsYXRpb24gb3JkZXIgaXMgdGhlbiDHrWQsCj4gb8erZCwgx6tvZCwgYW5k IGlzIGRldGVybWluZWQgYnkgdGhlIHByaW1hcnkgd2VpZ2h0cyEKPgo+IEFuc3dlciBBIHNlZW1z IHRoZSBtb3N0IHBsYXVzaWJsZSAtIGhvd2V2ZXIsIGl0IGRvZXMgbm90IHNlZW0gdG8gYmUKPiBl cXVpdmFsZW50IHRvIGEgZGVmaW5pdGlvbiBieSAnY29udHJhY3Rpb25zIGFuZCBleHBhbnNpb25z Jy4gSSBwcmVzdW1lIHRoZQo+IGFsdGVybmF0aXZlIG1ldGhvZCByZWZlcnJlZCB0byBpczoKPgo+ IDxyZXNldD5vbzwvcmVzZXQ+PHM+xY08L3M+Cj4KPiBUaGUgcHJpbWFyeSB3ZWlnaHRzIGZvciDF jSBhbmQgJ29vJyB3b3VsZCBiZSB0aGUgc2FtZTsgdGhlIHNlY29uZGFyeQo+IHdlaWdodHMKPiB3 b3VsZCBiZSA8YWx0LCBzdGQ+IGFuZCA8c3RkLCBzdGQ+LiAgQnV0IHRoZW4gdGhlIGNvbGxhdGlu ZyBvcmRlciBhbmQKPiB3ZWlnaHRzIHdvdWxkIGJlOgo+Cj4gb8erZCA8c3RkLCBzdGQsIG9nLCBz dGQ+Cj4gx6tvZCA8c3RkLCBvZywgc3RkLCBzdGQ+Cj4gx61kICAgPGFsdCwgc3RkLCBvZywgc3Rk Pi4KPgo+IC0gc2FtZSBvcmRlciBhcyBBbnN3ZXIgQiBhYm92ZSEKPgo+IEknbSBjb25mdXNlZC4g IFdoYXQgaXMgdGhlIG1lYW5pbmcgb2YKPgo+IDxyZXNldD5vPC9yZXNldD48eD48Y29udGV4dD5v PC9jb250ZXh0PjxzPjxjcCBoZXg9IjAzMDQiPjwvcz48L3g+Cj4KPiAtIG9yIGlzIHRoZSBjb25z dHJ1Y3QgbWVhbmluZ2xlc3MgZm9yIGEgY2hhcmFjdGVyIG9mIG5vbi16ZXJvIGNvbWJpbmluZwo+ IGNsYXNzPwo+Cj4gUmljaGFyZC4KPgo+Cj4KCgotLSAKTWFyawo= ------=_Part_64513_24250038.1176772157633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2hhdCAmbHQ7cmVzZXQmZ3Q7byZsdDsvcmVzZXQmZ3Q7Jmx0O3gmZ3Q7Jmx0O2NvbnRleHQmZ3Q7 byZsdDsvY29udGV4dCZndDsmbHQ7cyZndDsmbHQ7Y3AgaGV4PSZxdW90OzAzMDQmcXVvdDsmZ3Q7 Jmx0Oy9zJmd0OyZsdDsveCZndDsgbWVhbnMgaXM6PGJyPjxicj5pZiB5b3UgZW5jb3VudGVyIGEg VSswMzA0IGFmdGVyIGFuICZxdW90O28mcXVvdDssIHRyZWF0IGl0IGFzIGFmdGVyIGFuICZxdW90 O28mcXVvdDsgYXQgdGhlIHNlY29uZCBsZXZlbC4KPGJyPjxicj5UaGUgZXhhbXBsZSB3b3VsZCBi ZSBjbGVhcmVyIGlmIHdlIGRpZG4mIzM5O3QgaGF2ZSB0d28gaW5zdGFuY2VzIG9mICZxdW90O28m cXVvdDssIGFuZCBpZiB3ZSBoYWQgYW5vdGhlciBsZXR0ZXIgaW5zdGVhZCBvZiB0aGUgXHUwMzA0 LiA8c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogaXRhbGljOyI+SW1wb3J0YW50IG5vdGU6IGlmIHdl IHVzZWQgYSBcdTAzMDQgaW4gdGhlIHJ1bGUsIGl0IHdvdWxkIGJlaGF2ZSB0aGUgc2FtZSB3YXkg YXMgdGhlICZxdW90O2ImcXVvdDsgYmVsb3cgLS0gdGhlIGZhY3QgdGhhdCBpdCBpcyBhIGNvbWJp bmluZyBtYXJrIGlzIGltbWF0ZXJpYWwgaW4gdGhlIHJ1bGVzLgo8L3NwYW4+PGJyPjxicj4mbHQ7 cmVzZXQmZ3Q7byZsdDsvcmVzZXQmZ3Q7Jmx0O3gmZ3Q7Jmx0O2NvbnRleHQmZ3Q7YSZsdDsvY29u dGV4dCZndDsmbHQ7cyZndDtiJmx0Oy9zJmd0OyZsdDsveCZndDs8YnI+PGJyPlNvIHRoaXMgc2F5 cywgaWYgeW91IGVuY291bnRlciBhICZxdW90O2ImcXVvdDsgYWZ0ZXIgYW4gJnF1b3Q7YSZxdW90 OywgdHJlYXQgaXQgYXMgYWZ0ZXIgYW4gJnF1b3Q7byZxdW90OyBhdCB0aGUgc2Vjb25kIGxldmVs LiAKPGJyPjxicj5TbyB3aGVuIHNvcnRpbmcsIHlvdSB3aWxsIGdldDo8YnI+PGJyPmFvPGJyPmFP PGJyPmHDtDxicj5hYjxicj5hcDxicj48YnI+WW91IGNhbiBzZWUgdGhlIGVmZmVjdCBvZiB0aGUg c3RyZW5ndGggYnkgZ29pbmcgdG8gPGEgaHJlZj0iaHR0cDovL2RlbW8uaWN1LXByb2plY3Qub3Jn L2ljdS1iaW4vbG9jZXhwP189ZW4mYW1wO2RfPWVuJmFtcDt4PWNvbCI+aHR0cDovL2RlbW8uaWN1 LXByb2plY3Qub3JnL2ljdS1iaW4vbG9jZXhwP189ZW4mYW1wO2RfPWVuJmFtcDt4PWNvbAo8L2E+ PGJyPjxicj5QYXN0ZSB0aGUgYWJvdmUgaW50byBTb3VyY2UsIGFuZCBwYXN0ZSB0aGUgcnVsZSA8 YnI+PGJyPiZhbXA7IG8gJmx0OyZsdDsgYSB8IGI8YnI+PGJyPmludG8gQ3VzdG9tIFJ1bGVzLiAo dGhpcyBjb3JyZXNwb25kcyB0byB0aGUgc2Vjb25kIG9mIHRoZSBYTUwgcnVsZXMgYWJvdmUpLiBX aGVuIHlvdSBoaXQgU29ydCwgeW91IHdpbGwgc2VlOjxicj48YnI+PGRpdiBjbGFzcz0iYm94MCI+ Cgo8dHQgY2xhc3M9ImNvdW50Ij4wMTo8L3R0PiZuYnNwO2FvCjwvZGl2Pgo8ZGl2IGNsYXNzPSJi b3gxIj4KPHR0IGNsYXNzPSJjb3VudCI+MDI6PC90dD4mbmJzcDthTwo8L2Rpdj4KPGRpdiBjbGFz cz0iYm94MCI+Cjx0dCBjbGFzcz0iY291bnQiPjA0OjwvdHQ+Jm5ic3A7YcO0CjwvZGl2Pgo8ZGl2 IGNsYXNzPSJib3gxIj4KPHR0IGNsYXNzPSJjb3VudCI+MDM6PC90dD4mbmJzcDthYgo8L2Rpdj4K PGRpdiBjbGFzcz0iYm94MCI+Cjx0dCBjbGFzcz0iY291bnQiPjA1OjwvdHQ+Jm5ic3A7YXAKPC9k aXY+PGRpdiBjbGFzcz0iYm94MCI+PGJyPjxicj5TbyB3aGF0IGlzIGdvaW5nIG9uPyBUaGUgw7Qg aXMgaW50ZXJuYWxseSBiZWluZyAobG9naWNhbGx5KSB0cmVhdGVkIGFzIG8gKyBjaXJjdW1mbGV4 LCB3aGVyZSB0aGUgY2lyY3VtZmxleCBpcyBzb3J0ZWQgYXQgdGhlIHNlY29uZGFyeSBsZXZlbC4g U28gd2hlbiBjb21wYXJpbmcgbGV0dGVycyBhcyB3ZSB3YWxrIHRocm91Z2ggZWFjaCBvZiB0aGVz ZSBzdHJpbmdzLCBhdCBsZXR0ZXIgIzIgdGhlIGIgaXMgYmVpbmcgY29tcGFyZWQgdG8gYW4gJnF1 b3Q7byZxdW90OywgYW5kIGl0IGNvbWVzIGFmdGVyd2FyZHMuCjxicj48YnI+SWYgd2UgY2hhbmdl IHRoZSBzdHJlbmd0aCBvZiB0aGUgcmVsYXRpb25zaGlwIHRvIHRlcnRpYXJ5PGJyPjxicj4mYW1w OyBvICZsdDsmbHQ7Jmx0OyBhIHwgYjxicj48YnI+d2UgZ2V0PGJyPjxicj48ZGl2IGNsYXNzPSJi b3gwIj4KPHR0IGNsYXNzPSJjb3VudCI+MDE6PC90dD4mbmJzcDthbwo8L2Rpdj4KPGRpdiBjbGFz cz0iYm94MSI+Cjx0dCBjbGFzcz0iY291bnQiPjAzOjwvdHQ+Jm5ic3A7YWIKPC9kaXY+CjxkaXYg Y2xhc3M9ImJveDAiPgo8dHQgY2xhc3M9ImNvdW50Ij4wMjo8L3R0PiZuYnNwO2FPCjwvZGl2Pgo8 ZGl2IGNsYXNzPSJib3gxIj4KPHR0IGNsYXNzPSJjb3VudCI+MDQ6PC90dD4mbmJzcDthw7QKPC9k aXY+CjxkaXYgY2xhc3M9ImJveDAiPgo8dHQgY2xhc3M9ImNvdW50Ij4wNTo8L3R0PiZuYnNwO2Fw CjwvZGl2Pjxicj5XaXRob3V0IGtub3dpbmcgbW9yZSBhYm91dCB3aGF0IHlvdXIgaW50ZW5kZWQg cmVzdWx0IGlzLCBJIGNhbiYjMzk7dCBhZHZpc2UgeW91IGFueSBmdXJ0aGVyIG9uIGhvdyB0byBn ZXQgaXQuPGJyPjxicj5NYXJrPGJyPjwvZGl2Pjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gNC8xNi8wNywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPlJpY2hhcmQgV29y ZGluZ2hhbQo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFyZC53b3JkaW5naGFtQG50bHdv cmxkLmNvbSI+cmljaGFyZC53b3JkaW5naGFtQG50bHdvcmxkLmNvbTwvYT4mZ3Q7IHdyb3RlOjwv c3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDog MXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsg cGFkZGluZy1sZWZ0OiAxZXg7Ij4KSSYjMzk7bSBoYXZpbmcgYSBsaXR0bGUgdHJvdWJsZSB1bmRl cnN0YW5kaW5nIG9uZSBvZiB0aGUgTG9jYWxlIERhdGEgTWFya3VwPGJyPkxhbmd1YWdlIChMRE1M KSBjb2xsYXRpb24gZGVmaW5pdGlvbnMuIFRvIGNsYXJpZnkgbXkgdW5jZXJ0YWludHksIEkgaGF2 ZTxicj5jb25zaWRlcmVkIGEgbW9kaWZpY2F0aW9uIG9mIG9uZSBvZiB0aGUgZXhhbXBsZXMgZnJv bSBVVFMgMzUsIGJ1dCB3aXRoIGEKPGJyPmNvbWJpbmluZyBtYWNyb24gaW5zdGVhZCBvZiBhIGh5 cGhlbi48YnI+PGJyPlRoZSBoeXBvdGhldGljYWwgY29sbGF0aW9uIHVzZXMgZGVmYXVsdCBzZXR0 aW5ncyBhbmQgaGFzIGEgc2luZ2xlIHRhaWxvcmluZzo8YnI+PGJyPiZsdDtyZXNldCZndDtvJmx0 Oy9yZXNldCZndDsmbHQ7eCZndDsmbHQ7Y29udGV4dCZndDtvJmx0Oy9jb250ZXh0Jmd0OyZsdDtz Jmd0OyZsdDtjcCBoZXg9JnF1b3Q7MDMwNCZxdW90OyZndDsmbHQ7L3MmZ3Q7Jmx0Oy94Jmd0Owo8 YnI+PGJyPihUaGlzIHNvcnQgb2YgcnVsZSB3b3VsZCBtYWtlIHNlbnNlIGluIGNvbGxhdGluZyB0 cmFuc2xpdGVyYXRlZCBtYXRlcmlhbDxicj53cml0dGVuIHdpdGggdmFyeWluZyBkZWdyZWVzIG9m IEFTQ0lJZmljYXRpb24uKTxicj48YnI+V2hhdCB0aGVuIGlzIHRoZSByZWxhdGl2ZSBvcmRlcmlu ZyBvZiB0aGUgdGhyZWUgc3RyaW5ncyZuYnNwOyZuYnNwO8etZCAmbHQ7VSswMUVEIExBVElOPGJy PlNNQUxMIExFVFRFUiBPIFdJVEggT0dPTkVLIEFORCBNQUNST04sIFUrMDA2NSBMQVRJTiBTTUFM TCBMRVRURVIgRCZndDssIG/Hq2QKPGJyPiZsdDtVKzAwNkYgTEFUSU4gU01BTEwgTEVUVEVSIE8s IFUrMDFFQiBMQVRJTiBTTUFMTCBMRVRURVIgTyBXSVRIIE9HT05FSyw8YnI+VSswMDY1Jmd0Oywg YW5kIMerb2QgJmx0O1UrMDFFQiwgVSswMDZGLCBVKzAwNjUmZ3Q7PyZuYnNwOyZuYnNwO0kgY2Fu IGFyZ3VlIGZvciBhbGwgdGhyZWU8YnI+cG9zc2libGUgb3V0Y29tZXMhPGJyPjxicj5UaGUgYW5z d2VyIGRlcGVuZHMgb24gdGhlIHNlY29uZCBsZXZlbCB3ZWlnaHRzLCB3aGljaCBJIHdpbGwgZGVz aWduYXRlIGFzCjxicj4mIzM5O3N0ZCYjMzk7ICh0aGUgZWxlbWVudCBmb3IgJiMzOTtvJiMzOTsg YW5kICYjMzk7ZCYjMzk7KSwgJiMzOTtvZyYjMzk7ICh0aGUgZWxlbWVudCBmb3Igb2dvbmVrKSwg YW5kPGJyPiYjMzk7YWx0JiMzOTssIHRoZSBzZWNvbmQgbGV2ZWwgd2VpZ2h0IGluIHRoZSBjb2xs YXRpb24gZWxlbWVudHMgaW1wbGljaXRseSBkZWZpbmVkPGJyPmJ5IHRoZSBsb2NhbGUgZGVmaW5p dGlvbnMuJm5ic3A7Jm5ic3A7VGhlIGRlZmluaXRpb25zICgKZS5nIFVUUyAjMzUgVmVyc2lvbiAx LjQuMTxicj5TZWN0aW9uIDUuMTMuNykgYXJlIHN1Y2ggdGhhdCBzdGQgJmx0OyBhbHQuJm5ic3A7 Jm5ic3A7SWYgdGhlIHdlbGwtZm9ybWVkbmVzcyBjb25kaXRpb24gMjxicj5mcm9tIFVUUyAjMTAg JiMzOTtVbmljb2RlIENvbGxhdGlvbiBBbGdvcml0aG0mIzM5OyBWZXJzaW9uIDUuMCBob2xkcywg aW4gcGFydGljdWxhcjxicj4mIzM5O0dpdmVuIGNvbGxhdGlvbiBlbGVtZW50cyBbQywgRCwgRV0g YW5kIFswLCBBLCBCXSwgd2hlcmUgQyDiiaAgMCBhbmQgQSDiiaAgMCwKPGJyPnRoZW4gRCBtdXN0 IGJlIGxlc3MgdGhhbiBBJiMzOTssIHdlIHdpbGwgZnVydGhlcm1vcmUgaGF2ZSBzdGQgJmx0OyBh bHQgJmx0OyBvZy48YnI+PGJyPkFuc3dlciBBOjxicj48YnI+VGhlIHRhaWxvcmluZyBkZWZpbmVz IGEgY29udHJhY3Rpb24gZm9yIMWNIGJ1dCBub3Qgx6ssIGFuZCB0aGUgc2Vjb25kIGxldmVsPGJy PndlaWdodHMgb2YgxY0gYXJlICZsdDtzdGQsIGFsdCZndDssIHNvIHRoZSBzb3J0IG9yZGVyIGFu ZCBzZWNvbmQgbGV2ZWwgd2VpZ2h0cyBhcmU6Cjxicj48YnI+b8erZCAmbHQ7c3RkLCBzdGQsIG9n LCBzdGQmZ3Q7PGJyPsetZCZuYnNwOyZuYnNwOyAmbHQ7c3RkLCBhbHQsIG9nLCBzdGQmZ3Q7PGJy Pserb2QgJmx0O3N0ZCwgb2csIHN0ZCwgc3RkJmd0Oy48YnI+PGJyPkFuc3dlciBCOjxicj48YnI+ VGhlIGV4YW1wbGUgaW4gVVRTIDM1LCByZWFkczo8YnI+PGJyPiZxdW90O0ZvciBleGFtcGxlLCBz dXBwb3NlIHRoYXQgJnF1b3Q7LSZxdW90OyBpcyBzb3J0ZWQgbGlrZSB0aGUgcHJldmlvdXMgdm93 ZWwuIFRoZW4gb25lCjxicj5jb3VsZCBoYXZlIHJ1bGVzIHRoYXQgdGFrZSAmcXVvdDthLSZxdW90 OywgJnF1b3Q7ZS0mcXVvdDssIGFuZCBzbyBvbi4gSG93ZXZlciwgdGhhdCBtZWFucyB0aGF0PGJy PmV2ZXJ5IHRpbWUgYSB2ZXJ5IGNvbW1vbiBjaGFyYWN0ZXIgKGEsIGUsIC4uLikgaXMgZW5jb3Vu dGVyZWQsIGEgc3lzdGVtIHdpbGw8YnI+c2xvdyBkb3duIGFzIGl0IGxvb2tzIGZvciBwb3NzaWJs ZSBjb250cmFjdGlvbnMuIEFuIGFsdGVybmF0aXZlIGlzIHRvCjxicj5pbmRpY2F0ZSB0aGF0IHdo ZW4gJnF1b3Q7LSZxdW90OyBpcyBlbmNvdW50ZXJlZCwgYW5kIGl0IGNvbWVzIGFmdGVyIGFuICYj Mzk7YSYjMzk7LCBpdCBzb3J0czxicj5saWtlIGFuICYjMzk7YSYjMzk7LCBldGMuJnF1b3Q7PGJy Pjxicj5UaGF0IHN1Z2dlc3RzIHRoYXQgYSBjb250cmFjdGlvbiBpcyBub3QgZW1wbG95ZWQsIHNv IHRoYXQgaW4gZGVyaXZpbmcgdGhlPGJyPnNvcnQga2V5IGZyb20gx61kLCB3aGVuIHRoZSBzZXF1 ZW5jZSAmbHQ7JiMzOTtvJiMzOTssIGNvbWJpbmluZyBvZ29uZWssIGNvbWJpbmluZwo8YnI+bWFj cm9uJmd0OyBpcyBwcm9jZXNzZWQgdG8geWllbGQgYSBzb3J0IGtleSwgaXQgaXMgcHJvY2Vzc2Vk IGFzICZsdDsmIzM5O28mIzM5OywgY29tYmluaW5nPGJyPm9nb25laywgY2hhcmFjdGVyIHdpdGgg c2Vjb25kYXJ5IGRpZmZlcmVuY2UgZnJvbSAmIzM5O28mIzM5OyZndDssIGFuZCB0aHVzIHRoZTxi cj5jb2xsYXRpbmcgb3JkZXIgYW5kIHNlY29uZCBvcmRlciB3ZWlnaHRzIGlzCjxicj48YnI+b8er ZCAmbHQ7c3RkLCBzdGQsIG9nLCBzdGQmZ3Q7PGJyPserb2QgJmx0O3N0ZCwgb2csIHN0ZCwgc3Rk Jmd0Ozxicj7HrWQmbmJzcDsmbmJzcDsgJmx0O3N0ZCwgb2csIGFsdCwgc3RkJmd0Ozxicj48YnI+ SSBkb24mIzM5O3QgYmVsaWV2ZSB0aGUgYmVoYXZpb3VyIEkgYW0gYXNzdW1pbmcgY2FuIGJlIGFj aGlldmVkIHdpdGggYSBmaW5pdGU8YnI+Y29sbGF0aW9uIGVsZW1lbnQgdGFibGUgLSBidXQgZG9l cyB0aGUgVUNBIHJlcXVpcmUgdGhhdCB0aGUgY29sbGF0aW9uCjxicj5lbGVtZW50IHRhYmxlIGJl IGZpbml0ZT88YnI+PGJyPkFuc3dlciBDOjxicj48YnI+VGhlIGFyZ3VtZW50IHByb2NlZWRzIGFz IGZvciBCLCBidXQgdGhlbiBzYXlzIHRoYXQgYXMgdGhlIGNvbWJpbmluZyBtYWNyb248YnI+ZG9l cyBub3QgaW1tZWRpYXRlbHkgZm9sbG93ICYjMzk7byYjMzk7LCB0aGVyZSBpcyBubyBzcGVjaWFs IHRyZWF0bWVudC4gVGhpcyBpczxicj5jb25zaXN0ZW50IHdpdGggdGhlIFVDQSAtIG9uZSAmIzM5 O21lcmVseSYjMzk7IGRlZmluZXMgYW4gb3RoZXJ3aXNlIHJlZHVuZGFudAo8YnI+Y29udHJhY3Rp b24gaW4gdGhlIGNvbGxhdGlvbiBlbGVtZW50IHRhYmxlIGZvciAmIzM5O28mIzM5OyBhbmQgYWxs IHRoZSBvdGhlcjxicj5jaGFyYWN0ZXJzIHdpdGggbm9uLXplcm8gY29tYmluaW5nIGNsYXNzLiBU aGUgY29sbGF0aW9uIG9yZGVyIGlzIHRoZW4gx61kLDxicj5vx6tkLCDHq29kLCBhbmQgaXMgZGV0 ZXJtaW5lZCBieSB0aGUgcHJpbWFyeSB3ZWlnaHRzITxicj48YnI+QW5zd2VyIEEgc2VlbXMgdGhl IG1vc3QgcGxhdXNpYmxlIC0gaG93ZXZlciwgaXQgZG9lcyBub3Qgc2VlbSB0byBiZQo8YnI+ZXF1 aXZhbGVudCB0byBhIGRlZmluaXRpb24gYnkgJiMzOTtjb250cmFjdGlvbnMgYW5kIGV4cGFuc2lv bnMmIzM5Oy4gSSBwcmVzdW1lIHRoZTxicj5hbHRlcm5hdGl2ZSBtZXRob2QgcmVmZXJyZWQgdG8g aXM6PGJyPjxicj4mbHQ7cmVzZXQmZ3Q7b28mbHQ7L3Jlc2V0Jmd0OyZsdDtzJmd0O8WNJmx0Oy9z Jmd0Ozxicj48YnI+VGhlIHByaW1hcnkgd2VpZ2h0cyBmb3IgxY0gYW5kICYjMzk7b28mIzM5OyB3 b3VsZCBiZSB0aGUgc2FtZTsgdGhlIHNlY29uZGFyeSB3ZWlnaHRzCjxicj53b3VsZCBiZSAmbHQ7 YWx0LCBzdGQmZ3Q7IGFuZCAmbHQ7c3RkLCBzdGQmZ3Q7LiZuYnNwOyZuYnNwO0J1dCB0aGVuIHRo ZSBjb2xsYXRpbmcgb3JkZXIgYW5kPGJyPndlaWdodHMgd291bGQgYmU6PGJyPjxicj5vx6tkICZs dDtzdGQsIHN0ZCwgb2csIHN0ZCZndDs8YnI+x6tvZCAmbHQ7c3RkLCBvZywgc3RkLCBzdGQmZ3Q7 PGJyPsetZCZuYnNwOyZuYnNwOyAmbHQ7YWx0LCBzdGQsIG9nLCBzdGQmZ3Q7Ljxicj48YnI+LSBz YW1lIG9yZGVyIGFzIEFuc3dlciBCIGFib3ZlIQo8YnI+PGJyPkkmIzM5O20gY29uZnVzZWQuJm5i c3A7Jm5ic3A7V2hhdCBpcyB0aGUgbWVhbmluZyBvZjxicj48YnI+Jmx0O3Jlc2V0Jmd0O28mbHQ7 L3Jlc2V0Jmd0OyZsdDt4Jmd0OyZsdDtjb250ZXh0Jmd0O28mbHQ7L2NvbnRleHQmZ3Q7Jmx0O3Mm Z3Q7Jmx0O2NwIGhleD0mcXVvdDswMzA0JnF1b3Q7Jmd0OyZsdDsvcyZndDsmbHQ7L3gmZ3Q7PGJy Pjxicj4tIG9yIGlzIHRoZSBjb25zdHJ1Y3QgbWVhbmluZ2xlc3MgZm9yIGEgY2hhcmFjdGVyIG9m IG5vbi16ZXJvIGNvbWJpbmluZwo8YnI+Y2xhc3M/PGJyPjxicj5SaWNoYXJkLjxicj48YnI+PGJy PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+TWFyawo= ------=_Part_64513_24250038.1176772157633-- From richard.wordingham@ntlworld.com Mon Apr 16 22:35:13 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 17 Apr 2007 10:56:48 -0600 (CST) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3H4ZC1G015170 for ; Mon, 16 Apr 2007 22:35:13 -0600 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20070417043520.OZEC19810.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Tue, 17 Apr 2007 05:35:20 +0100 Received: from JRWXP1 ([82.18.16.213]) by aamtaout01-winn.ispmail.ntl.com with SMTP id <20070417043526.LTQR219.aamtaout01-winn.ispmail.ntl.com@JRWXP1> for ; Tue, 17 Apr 2007 05:35:26 +0100 Message-ID: <002401c780a9$8527b9b0$d5101252@JRWXP1> From: "Richard Wordingham" To: References: <003901c78067$5d2a7980$d5101252@JRWXP1> <30b660a20704161809k249f3997k89522e63c87acd16@mail.gmail.com> Subject: Re: LDML Collation Semantics Date: Tue, 17 Apr 2007 05:33:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-archive-position: 80 X-Approved-By: v-magdad@microsoft.com X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: richard.wordingham@ntlworld.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Mark Davis wrote on Tuesday, April 17, 2007 2:09 AM Subject: Re: LDML Collation Semantics > What oo > means > is: > if you encounter a U+0304 after an "o", treat it as after an "o" at the > second level. > Important note: if we used a \u0304 in the rule, it would behave the same > way as the "b" below -- the fact that it is a combining mark is immaterial > in the rules. Now confirmed after playing with the demonstration - my Answer C (ǭd, oǫd, ǫod). However, when I used ǭd encoded as , and with 'full normalisation' off (so not the true UCA) I got Answer A (oǫd, ǭd, ǫod), demonstrating that the rule, expressed as & o << o | \u0304, was being understood. The striking thing is that in the collation element model of the UCA, '& o << o | \u0304' not only defines a collation element for , but also for and all other combinations of U+006F and characters with non-zero combining class less than 230 that do not already have a collation element. I also tried '& oo << ō', and got the other conceivable ordering (oǫd, ǫod, ǭd), as I had expected. > Without knowing more about what your intended result is, I can't advise > you > any further on how to get it. My primary aim was to ensure that I understand the meaning of the collation rules. It is now clear to me that a single rule can have a dramatic effect in terms of what collation elements are defined. For example, generating collating elements for '& a <<< a | \u0304' and '& am <<< ã' could be quite complex. One would need to generate a collation element for . In practice, I think a context rule would not be appropriate for combining marks if there were a significant chance of multiple combining marks being applied. Richard. From fsasaki@w3.org Wed Apr 18 00:17:35 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 00:17:35 -0600 (CST) Received: from toro.w3.mag.keio.ac.jp (toro.w3.mag.keio.ac.jp [133.27.228.201]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3I6HY0m031758 for ; Wed, 18 Apr 2007 00:17:35 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 0AFA54AB8 for ; Wed, 18 Apr 2007 15:17:24 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro.w3.mag.keio.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg-9-v5H9xEi for ; Wed, 18 Apr 2007 15:17:23 +0900 (JST) Received: from [127.0.0.1] (p6058-ipad52marunouchi.tokyo.ocn.ne.jp [219.160.130.58]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id D40B34A93 for ; Wed, 18 Apr 2007 15:17:23 +0900 (JST) Message-ID: <4625B7E4.6000305@w3.org> Date: Wed, 18 Apr 2007 15:17:08 +0900 From: Felix Sasaki User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: cldr-users@unicode.org Subject: Relating calendar eras in CLDR Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 81 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: fsasaki@w3.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users While looking at CLDR data for Japanese, I had a question. For Japanese, there are two calendars: and . The Japanese calendar has 235 areas described like this: 大化 白雉 白鳯 朱鳥 ... 平成 the areas don't overlap and there is no break in between. Hence, it would be no problem to convert a Japanese date like "HEISEI19NEN" (平成 １９年 in Japanese script） to an ISO 8601 date "2007". For such a conversion, you would need era alignment information like in the "start attribute below: 平成(HEISEI) (this reads as: the first year of the HEISEI era maps to the ISO 8601 year "1988") my question is: why is such alignment of calendar information not realized in CLDR? Or to put it differently: How are processors of localized dates are expected to be able to compare "HEISEI19NEN" with "2007" - or is this just not possible with CLDR data? Regards, Felix From mark.edward.davis@gmail.com Wed Apr 18 00:57:06 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 00:57:06 -0600 (CST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3I6v6Nj027658 for ; Wed, 18 Apr 2007 00:57:06 -0600 Received: by an-out-0708.google.com with SMTP id d18so88296and for ; Tue, 17 Apr 2007 23:57:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=CTQe6/4i6E5ktfB6snRp+RQZLYdzVXhDHE5Vd8uNlQAjoLdyyPxPolXGcH2mKjQycyTKSb6qBtL7NA+Z6oMCL/BfiySU3r6AdWXIHc7cZ89N2YKcyMuUxxZKEeC/DNuC7il86jG9A4tr/an78RbQbynerU5PMe9d528PWxBcm7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=UUwbVf64nlP082IPigGZJpQT07AMxzZfzjD0TiwB75jglIs3m/5QLukSa4iJQa6/ApXbpLGKBZG5prkw75cOodarHwqbpSxaVCej3wmY1aYKTNbl5HXkvR5fHkaHORkmBZWPmgiIxBevwpsb40jBI2sCRQnKuXi+ctIBFBdFjf4= Received: by 10.114.166.1 with SMTP id o1mr63356wae.1176879425130; Tue, 17 Apr 2007 23:57:05 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 17 Apr 2007 23:57:05 -0700 (PDT) Message-ID: <30b660a20704172357ve8bca8did328b399e1e244f8@mail.gmail.com> Date: Tue, 17 Apr 2007 23:57:05 -0700 From: "Mark Davis" To: cldr-users@unicode.org Subject: Re: Relating calendar eras in CLDR In-Reply-To: <4625B7E4.6000305@w3.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_93719_15936857.1176879425070" References: <4625B7E4.6000305@w3.org> X-Google-Sender-Auth: 94c326367e3b8854 X-archive-position: 82 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: mark.davis@icu-project.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users ------=_Part_93719_15936857.1176879425070 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline Q0xEUiBkb2Vzbid0IHNwZWNpZnkgdGhlIGFsZ29yaXRobXMgdXNlZCBpbiBjYWxlbmRhcnMgKG9y IHRoZSBkYXRhIHVzZWQgdG8KZGV0ZXJtaW5lIHRpbWV6b25lcywgZXRjLiksIGl0IGZvY3VzZXMg b24gdGhlIGxvY2FsaXplZCBkYXRhIG5lZWRlZCB0bwpmb3JtYXQgZGF0ZXMgdXNpbmcgdGhvc2Ug YWxnb3JpdGhtcyAob3IgdGltZXpvbmVzLCBldGMpLiBTbyBpdCBkb2Vzbid0CmNvbnRhaW4sIGZv ciBleGFtcGxlLCB0aGUgYWxnb3JpdGhtIGZvciBkZXRlcm1pbmluZyBsZWFwIHllYXJzIGZvciB0 aGUKR3JlZ29yaWFuIGNhbGVuZGFyLCBvciB0aGUgbWFwcGluZyBmcm9tIHllYXJzIHRvIGVyYXMg Zm9yIEphcGFuZXNlOyB0aG9zZQphcmUgcHJlc3VtZWQgdG8gYmUgaW4gdGhlIGNvZGUgdGhhdCB1 c2VzIHRoZSBDTERSIGRhdGEgZm9yIGZvcm1hdHRpbmcgYW5kCnBhcnNpbmcuCgpUaGF0IGJlaW5n IHNhaWQsIGNvbW1pdHRlZSBjYW4gZGVjaWRlIHRvIGFkZCBzdWNoICJzdXBwbGVtZW50YWwiCmlu Zm9ybWF0aW9uLCBmb3IgZXhhbXBsZSwgaWYgaXQgaXMgZGlmZmljdWx0IHRvIGZpbmQgZWxzZXdo ZXJlLiBTbyB5b3UgY2FuCm1ha2Ugc3VjaCBhIHByb3Bvc2FsIGlmIHlvdSB0aGluayBpdCBpcyBu ZWNlc3NhcnkuCgpNYXJrCgpPbiA0LzE3LzA3LCBGZWxpeCBTYXNha2kgPGZzYXNha2lAdzMub3Jn PiB3cm90ZToKPgo+IFdoaWxlIGxvb2tpbmcgYXQgQ0xEUiBkYXRhIGZvciBKYXBhbmVzZSwgSSBo YWQgYSBxdWVzdGlvbi4KPgo+IEZvciBKYXBhbmVzZSwgdGhlcmUgYXJlIHR3byBjYWxlbmRhcnM6 IDxjYWxlbmRhciB0eXBlPSJncmVnb3JpYW4iPiBhbmQKPiA8Y2FsZW5kYXIgdHlwZT0iamFwYW5l c2UiPi4gVGhlIEphcGFuZXNlIGNhbGVuZGFyCj4gaGFzIDIzNSBhcmVhcyBkZXNjcmliZWQgbGlr ZSB0aGlzOgo+IDxlcmEgdHlwZT0iMCI+5aSn5YyWPC9lcmE+Cj4gPGVyYSB0eXBlPSIxIj7nmb3p m4k8L2VyYT4KPiA8ZXJhIHR5cGU9IjIiPueZvemzrzwvZXJhPgo+IDxlcmEgdHlwZT0iMyI+5pyx 6bOlPC9lcmE+Cj4gLi4uCj4gPGVyYSB0eXBlPSIyMzUiPuW5s+aIkDwvZXJhPgo+IHRoZSBhcmVh cyBkb24ndCBvdmVybGFwIGFuZCB0aGVyZSBpcyBubyBicmVhayBpbiBiZXR3ZWVuLiBIZW5jZSwg aXQKPiB3b3VsZCBiZSBubyBwcm9ibGVtIHRvIGNvbnZlcnQgYSBKYXBhbmVzZSBkYXRlIGxpa2Ug IkhFSVNFSTE5TkVOIiAo5bmz5oiQCj4g77yR77yZ5bm0IGluIEphcGFuZXNlIHNjcmlwdO+8iSB0 byBhbiBJU08gODYwMSBkYXRlICIyMDA3Ii4gRm9yIHN1Y2ggYQo+IGNvbnZlcnNpb24sIHlvdSB3 b3VsZCBuZWVkIGVyYSBhbGlnbm1lbnQgaW5mb3JtYXRpb24gbGlrZSBpbiB0aGUgInN0YXJ0Cj4g YXR0cmlidXRlIGJlbG93Ogo+IDxlcmEgdHlwZT0iMjM1IiBzdGFydD0iMTk4OCI+5bmz5oiQKEhF SVNFSSk8L2VyYT4gKHRoaXMgcmVhZHMgYXM6IHRoZQo+IGZpcnN0IHllYXIgb2YgdGhlIEhFSVNF SSBlcmEgbWFwcyB0byB0aGUgSVNPIDg2MDEgeWVhciAiMTk4OCIpCj4gbXkgcXVlc3Rpb24gaXM6 IHdoeSBpcyBzdWNoIGFsaWdubWVudCBvZiBjYWxlbmRhciBpbmZvcm1hdGlvbiBub3QKPiByZWFs aXplZCBpbiBDTERSPyBPciB0byBwdXQgaXQgZGlmZmVyZW50bHk6IEhvdyBhcmUgcHJvY2Vzc29y cyBvZgo+IGxvY2FsaXplZCBkYXRlcyBhcmUgZXhwZWN0ZWQgdG8gYmUgYWJsZSB0byBjb21wYXJl ICJIRUlTRUkxOU5FTiIgd2l0aAo+ICIyMDA3IiAtIG9yIGlzIHRoaXMganVzdCBub3QgcG9zc2li bGUgd2l0aCBDTERSIGRhdGE/Cj4KPiBSZWdhcmRzLCBGZWxpeAo+Cj4KPgoKCi0tIApNYXJrCg== ------=_Part_93719_15936857.1176879425070 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Q0xEUiBkb2VzbiYjMzk7dCBzcGVjaWZ5IHRoZSBhbGdvcml0aG1zIHVzZWQgaW4gY2FsZW5kYXJz IChvciB0aGUgZGF0YSB1c2VkIHRvIGRldGVybWluZSB0aW1lem9uZXMsIGV0Yy4pLCBpdCBmb2N1 c2VzIG9uIHRoZSBsb2NhbGl6ZWQgZGF0YSBuZWVkZWQgdG8gZm9ybWF0IGRhdGVzIHVzaW5nIHRo b3NlIGFsZ29yaXRobXMgKG9yIHRpbWV6b25lcywgZXRjKS4gU28gaXQgZG9lc24mIzM5O3QgY29u dGFpbiwgZm9yIGV4YW1wbGUsIHRoZSBhbGdvcml0aG0gZm9yIGRldGVybWluaW5nIGxlYXAgeWVh cnMgZm9yIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIsIG9yIHRoZSBtYXBwaW5nIGZyb20geWVhcnMg dG8gZXJhcyBmb3IgSmFwYW5lc2U7IHRob3NlIGFyZSBwcmVzdW1lZCB0byBiZSBpbiB0aGUgY29k ZSB0aGF0IHVzZXMgdGhlIENMRFIgZGF0YSBmb3IgZm9ybWF0dGluZyBhbmQgcGFyc2luZy4KPGJy Pjxicj5UaGF0IGJlaW5nIHNhaWQsIGNvbW1pdHRlZSBjYW4gZGVjaWRlIHRvIGFkZCBzdWNoICZx dW90O3N1cHBsZW1lbnRhbCZxdW90OyBpbmZvcm1hdGlvbiwgZm9yIGV4YW1wbGUsIGlmIGl0IGlz IGRpZmZpY3VsdCB0byBmaW5kIGVsc2V3aGVyZS4gU28geW91IGNhbiBtYWtlIHN1Y2ggYSBwcm9w b3NhbCBpZiB5b3UgdGhpbmsgaXQgaXMgbmVjZXNzYXJ5Ljxicj48YnI+TWFyazxicj4KPGJyPjxk aXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA0LzE3LzA3LCA8YiBjbGFzcz0iZ21haWxf c2VuZGVybmFtZSI+RmVsaXggU2FzYWtpPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZzYXNha2lA dzMub3JnIj5mc2FzYWtpQHczLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQs IDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7 Ij4KV2hpbGUgbG9va2luZyBhdCBDTERSIGRhdGEgZm9yIEphcGFuZXNlLCBJIGhhZCBhIHF1ZXN0 aW9uLjxicj48YnI+Rm9yIEphcGFuZXNlLCB0aGVyZSBhcmUgdHdvIGNhbGVuZGFyczogJmx0O2Nh bGVuZGFyIHR5cGU9JnF1b3Q7Z3JlZ29yaWFuJnF1b3Q7Jmd0OyBhbmQ8YnI+Jmx0O2NhbGVuZGFy IHR5cGU9JnF1b3Q7amFwYW5lc2UmcXVvdDsmZ3Q7LiBUaGUgSmFwYW5lc2UgY2FsZW5kYXIKPGJy PmhhcyAyMzUgYXJlYXMgZGVzY3JpYmVkIGxpa2UgdGhpczo8YnI+Jmx0O2VyYSB0eXBlPSZxdW90 OzAmcXVvdDsmZ3Q75aSn5YyWJmx0Oy9lcmEmZ3Q7PGJyPiZsdDtlcmEgdHlwZT0mcXVvdDsxJnF1 b3Q7Jmd0O+eZvembiSZsdDsvZXJhJmd0Ozxicj4mbHQ7ZXJhIHR5cGU9JnF1b3Q7MiZxdW90OyZn dDvnmb3ps68mbHQ7L2VyYSZndDs8YnI+Jmx0O2VyYSB0eXBlPSZxdW90OzMmcXVvdDsmZ3Q75pyx 6bOlJmx0Oy9lcmEmZ3Q7Cjxicj4uLi48YnI+Jmx0O2VyYSB0eXBlPSZxdW90OzIzNSZxdW90OyZn dDvlubPmiJAmbHQ7L2VyYSZndDs8YnI+dGhlIGFyZWFzIGRvbiYjMzk7dCBvdmVybGFwIGFuZCB0 aGVyZSBpcyBubyBicmVhayBpbiBiZXR3ZWVuLiBIZW5jZSwgaXQ8YnI+d291bGQgYmUgbm8gcHJv YmxlbSB0byBjb252ZXJ0IGEgSmFwYW5lc2UgZGF0ZSBsaWtlICZxdW90O0hFSVNFSTE5TkVOJnF1 b3Q7ICjlubPmiJA8YnI+77yR77yZ5bm0IGluIEphcGFuZXNlIHNjcmlwdO+8iSB0byBhbiBJU08g ODYwMSBkYXRlICZxdW90OzIwMDcmcXVvdDsuIEZvciBzdWNoIGEKPGJyPmNvbnZlcnNpb24sIHlv dSB3b3VsZCBuZWVkIGVyYSBhbGlnbm1lbnQgaW5mb3JtYXRpb24gbGlrZSBpbiB0aGUgJnF1b3Q7 c3RhcnQ8YnI+YXR0cmlidXRlIGJlbG93Ojxicj4mbHQ7ZXJhIHR5cGU9JnF1b3Q7MjM1JnF1b3Q7 IHN0YXJ0PSZxdW90OzE5ODgmcXVvdDsmZ3Q75bmz5oiQKEhFSVNFSSkmbHQ7L2VyYSZndDsgKHRo aXMgcmVhZHMgYXM6IHRoZTxicj5maXJzdCB5ZWFyIG9mIHRoZSBIRUlTRUkgZXJhIG1hcHMgdG8g dGhlIElTTyA4NjAxIHllYXIgJnF1b3Q7MTk4OCZxdW90OykKPGJyPm15IHF1ZXN0aW9uIGlzOiB3 aHkgaXMgc3VjaCBhbGlnbm1lbnQgb2YgY2FsZW5kYXIgaW5mb3JtYXRpb24gbm90PGJyPnJlYWxp emVkIGluIENMRFI/IE9yIHRvIHB1dCBpdCBkaWZmZXJlbnRseTogSG93IGFyZSBwcm9jZXNzb3Jz IG9mPGJyPmxvY2FsaXplZCBkYXRlcyBhcmUgZXhwZWN0ZWQgdG8gYmUgYWJsZSB0byBjb21wYXJl ICZxdW90O0hFSVNFSTE5TkVOJnF1b3Q7IHdpdGgKPGJyPiZxdW90OzIwMDcmcXVvdDsgLSBvciBp cyB0aGlzIGp1c3Qgbm90IHBvc3NpYmxlIHdpdGggQ0xEUiBkYXRhPzxicj48YnI+UmVnYXJkcywg RmVsaXg8YnI+PGJyPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48 YnI+LS0gPGJyPk1hcmsK ------=_Part_93719_15936857.1176879425070-- From srl@icu-project.org Wed Apr 18 04:16:03 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 04:16:03 -0600 (CST) Received: from v.icu-project.org (v.icu-project.org [161.58.210.87]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3IAG2H2017233 for ; Wed, 18 Apr 2007 04:16:03 -0600 Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.112]) by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1He7Cj-000NQp-7B for cldr-users@unicode.org; Wed, 18 Apr 2007 10:16:01 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4625B7E4.6000305@w3.org> References: <4625B7E4.6000305@w3.org> Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: From: "Steven R. Loomis" Subject: Re: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 03:15:58 -0700 To: cldr-users@unicode.org X-Mailer: Apple Mail (2.752.3) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l3IAG2H2017233 X-archive-position: 83 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: srl@icu-project.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users The eras map to the offset information found here: http://source.icu-project.org/repos/icu/icu/trunk/source/i18n/ japancal.cpp there's a request filed to add this data to CLDR supplemental proper. it's not done yet. with this information you should be able to map any way you need to. -s On 17 Apr 2007, at 23:17, Felix Sasaki wrote: > While looking at CLDR data for Japanese, I had a question. > > For Japanese, there are two calendars: > and . The Japanese calendar > has 235 areas described like this: > 大化 > 白雉 > 白鳯 > 朱鳥 > ... > 平成 > the areas don't overlap and there is no break in between. Hence, it > would be no problem to convert a Japanese date like > "HEISEI19NEN" (平成 １９年 in Japanese script） to an ISO 8601 > date "2007". For such a conversion, you would need era alignment > information like in the "start attribute below: > 平成(HEISEI) (this reads as: > the first year of the HEISEI era maps to the ISO 8601 year "1988") > my question is: why is such alignment of calendar information not > realized in CLDR? Or to put it differently: How are processors of > localized dates are expected to be able to compare "HEISEI19NEN" > with "2007" - or is this just not possible with CLDR data? > > Regards, Felix > > From verdy_p@wanadoo.fr Wed Apr 18 05:03:08 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 05:03:08 -0600 (CST) Received: from smtp20.orange.fr (smtp20.orange.fr [193.252.22.31]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3IB37N6010937 for ; Wed, 18 Apr 2007 05:03:07 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2022.orange.fr (SMTP Server) with ESMTP id 1DAC51C000AB for ; Wed, 18 Apr 2007 13:03:02 +0200 (CEST) Received: from HARNON (APoitiers-156-1-42-104.w86-213.abo.wanadoo.fr [86.213.89.104]) by mwinf2022.orange.fr (SMTP Server) with ESMTP id D54AA1C000A2 for ; Wed, 18 Apr 2007 13:03:01 +0200 (CEST) X-ME-UUID: 20070418110301873.D54AA1C000A2@mwinf2022.orange.fr From: "Philippe Verdy" To: References: <4625B7E4.6000305@w3.org> Subject: RE: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 13:02:52 +0200 Organization: Ordinateur Personnel Message-ID: <00b001c781a9$1c9e9700$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceBo21+dxCqOlVCQ027OMss7Qrl6AAA6bFw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l3IB37N6010937 X-archive-position: 84 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users I do agree that calendar era start dates are not localizable (or more precisely are locale-neutral, otherwise they are not the same eras or referring to the same calendar system), that's a good reason to not include them in the locale data, but only as supplemental data for general use. A related problem is the name of eras within Gregorian, Julian and Pre-Julian Roman calendars. They have parts were they cover each other, but other parts were they are distinct, even if they are named identically in many locales, but in fact there's the additional distinction by the explicit name of the calendar system in use for a formatted data. So eras are specific to a calendar system, but not to the locale used to translate them,as this affects the computing of the values of each date element (including the era selection) For now with the calendar data in CLDR, I am more concerned by the inaccuracy of the localizable data for the Chinese calendar(s), notably the designation of months, and missing elements for naming or qualifying intercalary months, or designating the Chinese months (which are not aligned to gregorian months, and not even with Gregorian year start dates), or other units like "Jeiqis" (which are approximately half-months, except that they are not aligned to Chinese months). Translating these Chinese months as "January".."December" or even simple numbers like "1".."12" is completely wrong without the indication of the intercalary month qualifier (the same issue is true for Pre-Julian Roman calendars, notably during the Roman Republic), or within other lunar or lunisolar calendars. > -----Message d'origine----- > De : cldr-users-bounce@unicode.org [mailto:cldr-users-bounce@unicode.org] > De la part de Steven R. Loomis > Envoyé : mercredi 18 avril 2007 12:16 > À : cldr-users@unicode.org > Objet : Re: Relating calendar eras in CLDR > > The eras map to the offset information found here: > > http://source.icu-project.org/repos/icu/icu/trunk/source/i18n/ > japancal.cpp > > there's a request filed to add this data to CLDR supplemental > proper. it's not done yet. > > with this information you should be able to map any way you need to. > > -s > > On 17 Apr 2007, at 23:17, Felix Sasaki wrote: > > While looking at CLDR data for Japanese, I had a question. > > > > For Japanese, there are two calendars: > > and . The Japanese calendar > > has 235 areas described like this: > > 大化 > > 白雉 > > 白鳯 > > 朱鳥 > > ... > > 平成 > > the areas don't overlap and there is no break in between. Hence, it > > would be no problem to convert a Japanese date like > > "HEISEI19NEN" (平成 １９年 in Japanese script） to an ISO 8601 > > date "2007". For such a conversion, you would need era alignment > > information like in the "start attribute below: > > 平成(HEISEI) (this reads as: > > the first year of the HEISEI era maps to the ISO 8601 year "1988") > > my question is: why is such alignment of calendar information not > > realized in CLDR? Or to put it differently: How are processors of > > localized dates are expected to be able to compare "HEISEI19NEN" > > with "2007" - or is this just not possible with CLDR data? > > > > Regards, Felix > > > > > > > > > -------------------------------------------------------------------------- > ------------- > Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > From verdy_p@wanadoo.fr Wed Apr 18 05:14:57 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 05:14:57 -0600 (CST) Received: from smtp20.orange.fr (smtp20.orange.fr [193.252.22.31]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3IBEvng002445 for ; Wed, 18 Apr 2007 05:14:57 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2022.orange.fr (SMTP Server) with ESMTP id 849641C00051 for ; Wed, 18 Apr 2007 13:14:51 +0200 (CEST) Received: from HARNON (APoitiers-156-1-42-104.w86-213.abo.wanadoo.fr [86.213.89.104]) by mwinf2022.orange.fr (SMTP Server) with ESMTP id 5CC8B1C0004F for ; Wed, 18 Apr 2007 13:14:51 +0200 (CEST) X-ME-UUID: 20070418111451380.5CC8B1C0004F@mwinf2022.orange.fr From: "Philippe Verdy" To: References: <4625B7E4.6000305@w3.org> Subject: RE: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 13:14:42 +0200 Organization: Ordinateur Personnel Message-ID: <00b101c781aa$c377cbe0$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceBo21+dxCqOlVCQ027OMss7Qrl6AABqNaQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l3IBEvng002445 X-archive-position: 85 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Another related issue: how do we translate the astrological months (i.e. roughly the moves of the Sun or planets within constellations over the ecliptic)? I don't mean that the CLDR should indicate how to compute the astrological positions (because they are quite complex, and often based on traditions that have lots of difference with the actual astronomical moves, and this is also related to the Chinese calendars, and many historical and religious calendars where tradition plays an important role). > -----Message d'origine----- > De: cldr-users-bounce@unicode.org [mailto:cldr-users-bounce@unicode.org] > De la part de Steven R. Loomis > Envoy: mercredi 18 avril 2007 12:16 > : cldr-users@unicode.org > Objet: Re: Relating calendar eras in CLDR > > The eras map to the offset information found here: > > http://source.icu-project.org/repos/icu/icu/trunk/source/i18n/ > japancal.cpp > > there's a request filed to add this data to CLDR supplemental > proper. it's not done yet. > > with this information you should be able to map any way you need to. From srl@icu-project.org Wed Apr 18 05:19:26 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 05:19:26 -0600 (CST) Received: from v.icu-project.org (v.icu-project.org [161.58.210.87]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3IBJMEh023386 for ; Wed, 18 Apr 2007 05:19:26 -0600 Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.112]) by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1He8C1-0004Xn-UN for cldr-users@unicode.org; Wed, 18 Apr 2007 11:19:22 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <00b001c781a9$1c9e9700$0a01a8c0@rodage.dyndns.org> References: <4625B7E4.6000305@w3.org> <00b001c781a9$1c9e9700$0a01a8c0@rodage.dyndns.org> Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <4BCE37FF-8567-4D86-80CB-D12ED15EB77A@icu-project.org> From: "Steven R. Loomis" Subject: Re: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 04:19:19 -0700 To: cldr-users@unicode.org X-Mailer: Apple Mail (2.752.3) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l3IBJMEh023386 X-archive-position: 86 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: srl@icu-project.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users On 18 Apr 2007, at 04:02, Philippe Verdy wrote: > I do agree that calendar era start dates are not localizable (or > more precisely are locale-neutral, otherwise they are not the same > eras or referring to the same calendar system), that's a good > reason to not include them in the locale data, but only as > supplemental data for general use. Right, that is the intent. > A related problem is the name of eras within Gregorian, Julian and > Pre-Julian Roman calendars. They have parts were they cover each > other, but other parts were they are distinct, even if they are > named identically in many locales, but in fact there's the > additional distinction by the explicit name of the calendar system > in use for a formatted data. So eras are specific to a calendar > system, but not to the locale used to translate them,as this > affects the computing of the values of each date element (including > the era selection) For example, the Thai Buddhist calendar, Gregorian, Japanese etc. differ only by era delineations. All of this is already covered in CLDR, although the supplemental data is not there - that is why there is a 'gregorian', 'buddhist', 'japanese' calendar type defined in CLDR. > For now with the calendar data in CLDR, I am more concerned by the > inaccuracy of the localizable data for the Chinese calendar(s), > notably the designation of months, and missing elements for naming > or qualifying intercalary months, or designating the Chinese months > (which are not aligned to gregorian months, and not even with > Gregorian year start dates), or other units like "Jeiqis" (which > are approximately half-months, except that they are not aligned to > Chinese months). You are referring to what CLDR refers to as "chinese" calendar, correct? > Translating these Chinese months as "January".."December" or even > simple numbers like "1".."12" is completely wrong without the > indication of the intercalary month qualifier The intercalary month qualifer is in ICU's data but is not currently in CLDR for chinese calendar. The original author of the Chinese calendar calculation code and data used an asterisk (*) for the qualifier. http://source.icu-project.org/repos/icu/icu/trunk/source/data/xml/ main/root.xml * ... CLDR refers to months as NUMERICAL only, within a system. If you saw somewhere "January", "February", etc associated with a chinese (non-gregorian) calendar, it may have only been for reference in the absence of fallback data. For example there are Islamic, Hebrew, Coptic, and other months which aren't related to Gregorian (if i recall correctly). So do not worry about "January". As to the translation, I don't think that it is incorrect to say that the translation can't be done, just that localized output is not possible unless the leap months are indicated. So unless I am misunderstanding, the data is 'insufficient' without the marker, not 'inaccurate'. Correct? > (the same issue is true for Pre-Julian Roman calendars, notably > during the Roman Republic), or within other lunar or lunisolar > calendars. Please give an example of this, I'm not following. In any event, it sounds like a different calendar type which could be proposed. -s >> -----Message d'origine----- >> De : cldr-users-bounce@unicode.org [mailto:cldr-users- >> bounce@unicode.org] >> De la part de Steven R. Loomis >> Envoyé : mercredi 18 avril 2007 12:16 >> À : cldr-users@unicode.org >> Objet : Re: Relating calendar eras in CLDR >> >> The eras map to the offset information found here: >> >> http://source.icu-project.org/repos/icu/icu/trunk/source/i18n/ >> japancal.cpp >> >> there's a request filed to add this data to CLDR supplemental >> proper. it's not done yet. >> >> with this information you should be able to map any way you need to. >> >> -s >> >> On 17 Apr 2007, at 23:17, Felix Sasaki wrote: >>> While looking at CLDR data for Japanese, I had a question. >>> >>> For Japanese, there are two calendars: >>> and . The Japanese calendar >>> has 235 areas described like this: >>> 大化 >>> 白雉 >>> 白鳯 >>> 朱鳥 From srl@icu-project.org Wed Apr 18 05:28:24 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 05:28:24 -0600 (CST) Received: from v.icu-project.org (v.icu-project.org [161.58.210.87]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3IBSOFJ001896 for ; Wed, 18 Apr 2007 05:28:24 -0600 Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.112]) by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1He8Km-0005kk-0N for cldr-users@unicode.org; Wed, 18 Apr 2007 11:28:24 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <00b101c781aa$c377cbe0$0a01a8c0@rodage.dyndns.org> References: <4625B7E4.6000305@w3.org> <00b101c781aa$c377cbe0$0a01a8c0@rodage.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: From: "Steven R. Loomis" Subject: Re: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 04:28:20 -0700 To: cldr-users@unicode.org X-Mailer: Apple Mail (2.752.3) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l3IBSOFJ001896 X-archive-position: 87 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: srl@icu-project.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Again, I don't think the question at this point is 'how', but depends on: * verification - sources for the data * explanation - examples, etc. * justification - how is it used, by whom, in what context, etc (to determine how it fits into the constellation of locale data). at some point it's all just a collection of data. By the way, thanks for noticing the lack of intercalary (what we have called"leap month") marker. It missed 1.4 and completely slipped my mind. I filed a bug, http://unicode.org/cldr/bugs/locale-bugs? findid=1335 i am hoping to give these calendars some more of my attention this year. -s On 18 Apr 2007, at 04:14, Philippe Verdy wrote: > Another related issue: how do we translate the astrological months > (i.e. > roughly the moves of the Sun or planets within constellations over the > ecliptic)? I don't mean that the CLDR should indicate how to > compute the > astrological positions (because they are quite complex, and often > based on > traditions that have lots of difference with the actual > astronomical moves, > and this is also related to the Chinese calendars, and many > historical and > religious calendars where tradition plays an important role). > >> -----Message d'origine----- >> De : cldr-users-bounce@unicode.org [mailto:cldr-users- >> bounce@unicode.org] >> De la part de Steven R. Loomis >> Envoy : mercredi 18 avril 2007 12:16 >> : cldr-users@unicode.org >> Objet : Re: Relating calendar eras in CLDR >> >> The eras map to the offset information found here: >> >> http://source.icu-project.org/repos/icu/icu/trunk/source/i18n/ >> japancal.cpp >> >> there's a request filed to add this data to CLDR supplemental >> proper. it's not done yet. >> >> with this information you should be able to map any way you need to. > > > > > From verdy_p@wanadoo.fr Wed Apr 18 06:50:01 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 06:50:01 -0600 (CST) Received: from smtp20.orange.fr (smtp20.orange.fr [193.252.22.31]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3ICo02R004489 for ; Wed, 18 Apr 2007 06:50:01 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2023.orange.fr (SMTP Server) with ESMTP id 304251C00070; Wed, 18 Apr 2007 14:49:55 +0200 (CEST) Received: from HARNON (APoitiers-156-1-42-104.w86-213.abo.wanadoo.fr [86.213.89.104]) by mwinf2023.orange.fr (SMTP Server) with ESMTP id ED8EA1C00063; Wed, 18 Apr 2007 14:49:54 +0200 (CEST) X-ME-UUID: 20070418124954973.ED8EA1C00063@mwinf2023.orange.fr From: "Philippe Verdy" To: Cc: "'Steven R. Loomis'" References: <4625B7E4.6000305@w3.org> <00b001c781a9$1c9e9700$0a01a8c0@rodage.dyndns.org> <4BCE37FF-8567-4D86-80CB-D12ED15EB77A@icu-project.org> Subject: RE: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 14:49:45 +0200 Organization: Ordinateur Personnel Message-ID: <00b201c781b8$0b09b6a0$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4BCE37FF-8567-4D86-80CB-D12ED15EB77A@icu-project.org> Thread-Index: AceBrCbhX52soPT4QbCW4iOjsqj/bQAAOyvw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-archive-position: 88 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Steven R. Loomis wrote: > > Translating these Chinese months as "January".."December" or even > > simple numbers like "1".."12" is completely wrong without the > > indication of the intercalary month qualifier > > The intercalary month qualifer is in ICU's data but is not > currently in CLDR for chinese calendar. The original author of the > Chinese calendar calculation code and data used an asterisk (*) for > the qualifier. > > http://source.icu-project.org/repos/icu/icu/trunk/source/data/xml/ > main/root.xml > > > > > > > > > * > > ... This leaves the question of which date elements are needed for each calendar type. There's more than just a era, year, month and day (and optionally weekday). And we still lack the data for Chinese "Jeiqis" (I am not sure about the romanized orthography). And note that in China, there are actually two traditions for months, one is based on the true moon, the other one is adjusted with the solar year, and the year does not start on the same date in both traditions. We could also add the case of cycles of multiple years, which is a numeric system by itself except that it uses a complex base, not a single base (think of it as intercalary years), but do not involve a change of era. In this Chinese system, years are designated by a pair of characters (also linked to astronological meanings, i.e. simplifications of astronomic cycles). And how do we format other things in Christian calendars (for example the dominical letter, used in easter date computing to adjust solar years with weeks)? > CLDR refers to months as NUMERICAL only, within a system. If you > saw somewhere "January", "February", etc associated with a chinese > (non-gregorian) calendar, it may have only been for reference in the > absence of fallback data. For example there are Islamic, Hebrew, > Coptic, and other months which aren't related to Gregorian (if i > recall correctly). So do not worry about "January". I know that they are refered by numbers, but this is still not the main issue (well in fact it is, the CLDR data has named these months using names used for the Gregorian months, only because there's confusion, even within China, by the modern coexistence of the civil and traditional calendars). > As to the translation, I don't think that it is incorrect to say that > the translation can't be done, just that localized output is not > possible unless the leap months are indicated. So unless I am > misunderstanding, the data is 'insufficient' without the marker, not > 'inaccurate'. Correct? It will remain inaccurate as long as there's no formal description about which numerical date elements are needed to properly represent a date within a given calendar. Many date formats are missing qualification about their usability for other non-Gregorian calendars. Is there a way in a locale to get a mapping from a set of date elements and the calendars in which they are usable? How to manage the case of abbreviated dates (where not all elements are specified in the requested format)? If we look at the Chinese calendar, a format like "yyyy-mm-dd" is completely unusable because it is missing a place for the intercalary month qualifier. In in this format, "mm" really designates something else than a Gregorian month (the unlocalized numeric values are in fact different and one cannot assume that each next month starts with an incremented month number from the current month number). You did not reply about Chinese half-months: how can they be formatted??? How could one format Roman dates (whose dates that are counted negatively in reference to a future date, with several distinct periods for each month, plus extra days out of any month?) Same question about formatting the Egyptian Demotic dates with intercalary days that are not part of any month but added at end of year to align the year with the solar cycle, and which are named based on deities or celebrations? From verdy_p@wanadoo.fr Wed Apr 18 06:59:05 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 06:59:05 -0600 (CST) Received: from smtp20.orange.fr (smtp20.orange.fr [193.252.22.31]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3ICx50M008525 for ; Wed, 18 Apr 2007 06:59:05 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2023.orange.fr (SMTP Server) with ESMTP id AB5B11C00063 for ; Wed, 18 Apr 2007 14:58:59 +0200 (CEST) Received: from HARNON (APoitiers-156-1-42-104.w86-213.abo.wanadoo.fr [86.213.89.104]) by mwinf2023.orange.fr (SMTP Server) with ESMTP id 824021C0005A for ; Wed, 18 Apr 2007 14:58:59 +0200 (CEST) X-ME-UUID: 20070418125859533.824021C0005A@mwinf2023.orange.fr From: "Philippe Verdy" To: References: <4625B7E4.6000305@w3.org> <00b101c781aa$c377cbe0$0a01a8c0@rodage.dyndns.org> Subject: RE: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 14:58:50 +0200 Organization: Ordinateur Personnel Message-ID: <00b301c781b9$4f95d1e0$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceBrWXDEleBQxpkT9e1TPsJfweRsQAC62Ig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l3ICx50M008525 X-archive-position: 89 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users > -----Message d'origine----- > De: cldr-users-bounce@unicode.org [mailto:cldr-users-bounce@unicode.org] > De la part de Steven R. Loomis > Envoy: mercredi 18 avril 2007 13:28 > : cldr-users@unicode.org > Objet: Re: Relating calendar eras in CLDR > > Again, I don't think the question at this point is 'how', but depends > on: > * verification - sources for the data > * explanation - examples, etc. > * justification - how is it used, by whom, in what context, etc (to > determine how it fits into the constellation of locale data). > > at some point it's all just a collection of data. > > By the way, thanks for noticing the lack of intercalary (what we have > called"leap month") marker. It missed 1.4 and completely slipped my > mind. I filed a bug, http://unicode.org/cldr/bugs/locale-bugs? > findid=1335 > > i am hoping to give these calendars some more of my attention this year. This was already noted as part of bug 1335 that you have commented back directly to me just yesterday, my reply to the list was directly related to a reevaluation of this old bug... The case of Chinese months was already noted: http://www.unicode.org/cldr/bugs/locale-bugs/tools/?id=1263#reply21 From fsasaki@w3.org Wed Apr 18 07:16:59 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 07:16:59 -0600 (CST) Received: from toro.w3.mag.keio.ac.jp (toro.w3.mag.keio.ac.jp [133.27.228.201]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3IDGwK4018790 for ; Wed, 18 Apr 2007 07:16:59 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 7561F4ADC for ; Wed, 18 Apr 2007 22:16:43 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro.w3.mag.keio.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqeqi47A67N0 for ; Wed, 18 Apr 2007 22:16:43 +0900 (JST) Received: from [127.0.0.1] (p6058-ipad52marunouchi.tokyo.ocn.ne.jp [219.160.130.58]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 4B4E245A0 for ; Wed, 18 Apr 2007 22:16:43 +0900 (JST) Message-ID: <46261A2C.4090609@w3.org> Date: Wed, 18 Apr 2007 22:16:28 +0900 From: Felix Sasaki User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: cldr-users@unicode.org Subject: Re: Relating calendar eras in CLDR References: <4625B7E4.6000305@w3.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 90 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: fsasaki@w3.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Thank you for your explanations, Mark, Philippe and Steven. The intent of CLDR and ways to get the supplemental data is now much clearer to me. I'm hoping to use the supplemental data for Japanese and will try to get some feedback from you later. Regards, Felix Steven R. Loomis wrote: > The eras map to the offset information found here: > > http://source.icu-project.org/repos/icu/icu/trunk/source/i18n/japancal.cpp > > > there's a request filed to add this data to CLDR supplemental proper. > it's not done yet. > > with this information you should be able to map any way you need to. > > -s > > On 17 Apr 2007, at 23:17, Felix Sasaki wrote: >> While looking at CLDR data for Japanese, I had a question. >> >> For Japanese, there are two calendars: >> and . The Japanese calendar >> has 235 areas described like this: >> 大化 >> 白雉 >> 白鳯 >> 朱鳥 >> ... >> 平成 >> the areas don't overlap and there is no break in between. Hence, it >> would be no problem to convert a Japanese date like "HEISEI19NEN" (平 >> 成１９年 in Japanese script） to an ISO 8601 date "2007". For such a >> conversion, you would need era alignment information like in the >> "start attribute below: >> 平成(HEISEI) (this reads as: the >> first year of the HEISEI era maps to the ISO 8601 year "1988") >> my question is: why is such alignment of calendar information not >> realized in CLDR? Or to put it differently: How are processors of >> localized dates are expected to be able to compare "HEISEI19NEN" with >> "2007" - or is this just not possible with CLDR data? >> >> Regards, Felix >> >> > > > From richard.wordingham@ntlworld.com Wed Apr 18 02:04:11 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 09:15:22 -0600 (CST) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3I84Ak2002345 for ; Wed, 18 Apr 2007 02:04:10 -0600 Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com with ESMTP id <20070418080418.EZKD2491.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com> for ; Wed, 18 Apr 2007 09:04:18 +0100 Received: from JRWXP1 ([82.18.16.213]) by aamtaout03-winn.ispmail.ntl.com with SMTP id <20070418080437.CGYH26699.aamtaout03-winn.ispmail.ntl.com@JRWXP1> for ; Wed, 18 Apr 2007 09:04:37 +0100 Message-ID: <002e01c7818f$e0b95fe0$d5101252@JRWXP1> From: "Richard Wordingham" To: References: <4625B7E4.6000305@w3.org> Subject: Re: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 09:02:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-archive-position: 91 X-Approved-By: v-magdad@microsoft.com X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: richard.wordingham@ntlworld.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Felix Sasaki wrote on Wednesday, April 18, 2007 7:17 AM Subject: Relating calendar eras in CLDR The Japanese calendar > has 235 areas described like this: > 大化 > ... > 平成 > the areas don't overlap and there is no break in between. Weren't there gaps at the beginning and two series of emperors in the 14th century? > Hence, it would be no problem to convert a Japanese date like > "HEISEI19NEN" (平成 １９年 in Japanese script） to an ISO 8601 date "2007". For > such a conversion, you would need era alignment information like in the > "start attribute below: > 平成(HEISEI) (this reads as: the first > year of the HEISEI era maps to the ISO 8601 year "1988") You need the day and month of the start date if you are to do the reverse conversion. And, of course, Japanese and Gregorian years didn't always coincide. (Similarly, the months of the Buddhist Era were brought into alignment with the Gregorian calendar decades before the year start was - we've just had the main Thai new year.) The data set can get horrendously large. Do you want to track the dates of the Julian to Gregorian switch? Should systems be able to accept 30 February 1812 as a valid date? What were the leap years during the time of Augustus? Do we record when time shifted from local solar time to a round offset from GMT? And, of course, there is the question of when the year number changed under the Julian system. Usage there was long variable, and the British tax year continues the old system in which the year number changed during March. Richard. From kent.karlsson14@comhem.se Wed Apr 18 12:44:54 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 12:44:54 -0600 (CST) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3IIirRs019708 for ; Wed, 18 Apr 2007 12:44:53 -0600 Received: from c83-248-98-120.bredband.comhem.se ([83.248.98.120]:1862 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1HeF9A-0005Gp-4K for cldr-users@unicode.org; Wed, 18 Apr 2007 20:44:52 +0200 From: "Kent Karlsson" To: References: <4625B7E4.6000305@w3.org> Subject: RE: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 20:47:19 +0200 Message-ID: <006101c781e9$ff2e83b0$7a63f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4625B7E4.6000305@w3.org> Thread-Index: AceBgX/njqHpOBuKSxapHC/BD8JJGgAHLWaw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Scan-Result: No virus found in message 1HeF9A-0005Gp-4K. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1HeF9A-0005Gp-4K b74e93647e2c7a5b82fac4c7a862a729 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l3IIirRs019708 X-archive-position: 92 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: kent.karlsson14@comhem.se Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Felix Sasaki wrote: > ... > 平成 > the areas don't overlap and there is no break in between. Hence, it Actually they do overlap. In some cases there seem to be a one day overlap. See http://www.i18nguy.com/l10n/emperor-date.html. Furthermore, there was a "northern court" and a "southern court" for a while in Japan, with overlap... See http://en.wikipedia.org/wiki/Japanese_era. > would be no problem to convert a Japanese date like "HEISEI19NEN" (平成 > １９年 in Japanese script） to an ISO 8601 date "2007". For such a > conversion, you would need era alignment information like in > the "start attribute below: > 平成(HEISEI) (this reads as: the > first year of the HEISEI era maps to the ISO 8601 year "1988") You'll need start date (to the day) and end date (to the day) for each. For output, one would also need to have some kind of preference between the southern and northern courts (if you care about 600-700 years ago), and for the one-day overlaps. /kent k From srl@icu-project.org Wed Apr 18 15:22:59 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 15:22:59 -0600 (CST) Received: from v.icu-project.org (v.icu-project.org [161.58.210.87]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3ILMxev002057 for ; Wed, 18 Apr 2007 15:22:59 -0600 Received: from [192.18.43.225] (helo=[129.145.161.149]) by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HeHc7-000Pyx-T9; Wed, 18 Apr 2007 21:22:56 +0000 In-Reply-To: <00b201c781b8$0b09b6a0$0a01a8c0@rodage.dyndns.org> References: <4625B7E4.6000305@w3.org> <00b001c781a9$1c9e9700$0a01a8c0@rodage.dyndns.org> <4BCE37FF-8567-4D86-80CB-D12ED15EB77A@icu-project.org> <00b201c781b8$0b09b6a0$0a01a8c0@rodage.dyndns.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-5-1055671993 Message-Id: <30577D52-D296-4F17-A2D7-D7224D3031F8@icu-project.org> Cc: From: "Steven R. Loomis" Subject: Re: Relating calendar eras in CLDR Date: Wed, 18 Apr 2007 14:22:47 -0700 To: X-Mailer: Apple Mail (2.752.3) X-archive-position: 93 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: srl@icu-project.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users --Apple-Mail-5-1055671993 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 18 Apr 2007, at 05:49, Philippe Verdy wrote: >> CLDR refers to months as NUMERICAL only, within a system. If you >> saw somewhere "January", "February", etc associated with a chinese >> (non-gregorian) calendar, it may have only been for reference in the >> absence of fallback data. For example there are Islamic, Hebrew, >> Coptic, and other months which aren't related to Gregorian (if i >> recall correctly). So do not worry about "January". > > I know that they are refered by numbers, but this is still not the > main > issue (well in fact it is, the CLDR data has named these months > using names > used for the Gregorian months, only because there's confusion, even > within > China, by the modern coexistence of the civil and traditional > calendars). "CLDR data has named these months using names used for the Gregorian months" Philippe, Please explain what exactly you are referring to by this, such as, by giving a URL, a line number within a file or a spec, etc. -s --Apple-Mail-5-1055671993 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 18 Apr 2007, at = 05:49, Philippe Verdy wrote:

=A0 CLDR refers to months as = NUMERICAL only, within a system.=A0 = If you

saw somewhere "January", "February", etc associated with a = chinese

(non-gregorian) calendar, it may have only been for reference = in the

absence = of fallback data.=A0 For = example there are Islamic,=A0 = Hebrew,

Coptic, and other months which aren't related to Gregorian = (if i

recall = correctly). =A0 So do not = worry about "January".


=

I know that they are refered = by numbers, but this is still not the main

issue (well in fact it is, the CLDR = data has named these months using names

used for the Gregorian months, only = because there's confusion, even within

China, by the modern coexistence of the = civil and traditional calendars).

=

"CLDR data has named these months using = names=A0used for the Gregorian months"

Philippe,=A0
=A0 = Please explain what exactly you are referring to by this, such as, by = giving a URL, a line number within a file or a spec, etc.

-s

= --Apple-Mail-5-1055671993-- From fsasaki@w3.org Wed Apr 18 16:31:09 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 16:31:09 -0600 (CST) Received: from toro.w3.mag.keio.ac.jp (toro.w3.mag.keio.ac.jp [133.27.228.201]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3IMV8ab030401 for ; Wed, 18 Apr 2007 16:31:08 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 2B42A4B1F for ; Thu, 19 Apr 2007 07:30:48 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro.w3.mag.keio.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA8NRAb5aWtM for ; Thu, 19 Apr 2007 07:30:48 +0900 (JST) Received: from [127.0.0.1] (p6058-ipad52marunouchi.tokyo.ocn.ne.jp [219.160.130.58]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 02E664B1C for ; Thu, 19 Apr 2007 07:30:47 +0900 (JST) Message-ID: <46269C09.8070404@w3.org> Date: Thu, 19 Apr 2007 07:30:33 +0900 From: Felix Sasaki User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: cldr-users@unicode.org Subject: Re: Relating calendar eras in CLDR References: <4625B7E4.6000305@w3.org> <006101c781e9$ff2e83b0$7a63f853@streamserve.com> In-Reply-To: <006101c781e9$ff2e83b0$7a63f853@streamserve.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 94 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: fsasaki@w3.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Kent Karlsson wrote: > > Felix Sasaki wrote: > >> ... >> 平成 >> the areas don't overlap and there is no break in between. Hence, it >> > > Actually they do overlap. In some cases there seem to be a one day overlap. > See http://www.i18nguy.com/l10n/emperor-date.html. > > Furthermore, there was a "northern court" and a "southern court" for a while > in Japan, with overlap... See http://en.wikipedia.org/wiki/Japanese_era. > true, but I think these overlaps and the gaps mentioned by Richard are not important for my application scenario: converting a Japanese date to an ISO 8601 date. Note that I don't want to convert in the other direction. I agree also with all concerns mentioned by Richard (what to do about the Julian / Gregorian switch etc.), but again I think for the conversion into a "canonicalized date format" you can ignore them - with some additional information. What "some additional information" means depends on the input date format. But at least in the case of Japanese the supplementary data mentioned by Steven http://source.icu-project.org/repos/icu/icu/trunk/source/i18n/japancal.cpp seems to be sufficient. Regards, Felix. >> would be no problem to convert a Japanese date like "HEISEI19NEN" (平成 >> １９年 in Japanese script） to an ISO 8601 date "2007". For such a >> conversion, you would need era alignment information like in >> the "start attribute below: >> 平成(HEISEI) (this reads as: the >> first year of the HEISEI era maps to the ISO 8601 year "1988") >> > > You'll need start date (to the day) and end date (to the day) for each. > For output, one would also need to have some kind of preference between > the southern and northern courts (if you care about 600-700 years ago), > and for the one-day overlaps. > > > /kent k > > > > From verdy_p@wanadoo.fr Wed Apr 18 20:08:25 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Wed, 18 Apr 2007 20:08:25 -0600 (CST) Received: from smtp20.orange.fr (smtp20.orange.fr [193.252.22.29]) by unicode.org (8.13.4/8.12.11) with ESMTP id l3J28O1P004323 for ; Wed, 18 Apr 2007 20:08:25 -0600 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2014.orange.fr (SMTP Server) with ESMTP id 3CFD61C000B6 for ; Thu, 19 Apr 2007 04:08:19 +0200 (CEST) Received: from HARNON (APoitiers-156-1-108-5.w90-5.abo.wanadoo.fr [90.5.11.5]) by mwinf2014.orange.fr (SMTP Server) with ESMTP id 61C921C000BD for ; Thu, 19 Apr 2007 04:08:18 +0200 (CEST) X-ME-UUID: 20070419020818400.61C921C000BD@mwinf2014.orange.fr From: "Philippe Verdy" To: References: <4625B7E4.6000305@w3.org> <002e01c7818f$e0b95fe0$d5101252@JRWXP1> Subject: RE: Relating calendar eras in CLDR Date: Thu, 19 Apr 2007 04:08:08 +0200 Organization: Ordinateur Personnel Message-ID: <00f701c78227$932724e0$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002e01c7818f$e0b95fe0$d5101252@JRWXP1> Thread-Index: AceBzTa9WqO+05sYSQO8YN+7jhzIcQAVT06A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-archive-position: 95 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: verdy_p@wanadoo.fr Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users De la par