From asmodai@in-nomine.org Mon Jul 2 05:05:31 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 02 Jul 2007 05:05:31 -0500 (CDT) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by unicode.org (8.13.4/8.12.11) with ESMTP id l62A5UDu001484 for ; Mon, 2 Jul 2007 05:05:31 -0500 Received: from nexus.in-nomine.org (chronias.xs4all.nl [82.92.216.8]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id l62A5TaZ023840 for ; Mon, 2 Jul 2007 12:05:29 +0200 (CEST) (envelope-from asmodai@in-nomine.org) Received: from localhost (localhost.domini.in-nomine.org [127.0.0.1]) by nexus.in-nomine.org (Postfix) with ESMTP id A1980C716 for ; Mon, 2 Jul 2007 12:04:14 +0200 (CEST) X-Virus-Scanned: by XS4ALL Virus Scanner Received: from nexus.in-nomine.org ([127.0.0.1]) by localhost (nexus.domini.in-nomine.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWwB1vqARnon for ; Mon, 2 Jul 2007 12:04:10 +0200 (CEST) Received: by nexus.in-nomine.org (Postfix, from userid 1000) id 0C716C715; Mon, 2 Jul 2007 12:04:10 +0200 (CEST) Date: Mon, 2 Jul 2007 12:04:09 +0200 From: Jeroen Ruigrok van der Werven To: cldr-users@unicode.org Subject: [ANN] Babel 0.8.1 released Message-ID: <20070702100409.GG30825@nexus.in-nomine.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Organisation: Ninth Circle Enterprises User-Agent: Mutt/1.5.15 (2007-04-06) X-archive-position: 165 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: asmodai@in-nomine.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users My original forward of 0.8.0 never seem to have made it to the list, here's an announcement for 0.8.1. Babel builds on CLDR's data to provide an i18n and L10N infrastructure in Python. ----- Forwarded message from Christopher Lenz ----- From: Christopher Lenz To: python-babel@googlegroups.com Subject: [ANN] Babel 0.8.1 released Date: Mon, 2 Jul 2007 12:00:42 +0200 X-Mailer: Apple Mail (2.752.3) Babel 0.8.1 - Jul 2, 2007 ========================= We're proud to present the latest release of the Babel: 0.8.1. Babel is a Python library that provides an integrated collection of utilities that assist with internationalizing and localizing Python applications (in particular web-based applications.) This release contains a number of bugfixes and minor improvements over the initial 0.8 release. You can download the new release here: Please don't hesitate to report any issues you may find with this release: For questions, comments and user discussions, please use the Babel mailing list: What's New: ----------- * `default_locale()` would fail when the value of the `LANGUAGE` environment variable contained multiple language codes separated by colon, as is explicitly allowed by the GNU gettext tools. As the `default_locale()` function is called at the module level in some modules, this bug would completely break importing these modules on systems where `LANGUAGE` is set that way. * The character set specified in PO template files is now respected when creating new catalog files based on that template. This allows the use of characters outside the ASCII range in POT files (ticket #17). * The default ordering of messages in generated POT files, which is based on the order those messages are found when walking the source tree, is no longer subject to differences between platforms; directory and file names are now always sorted alphabetically. * The Python message extractor now respects the special encoding comment to be able to handle files containing non-ASCII characters (ticket #23). * Added 'N_' (gettext noop) to the extractor's default keywords. * Made locale string parsing more robust, and also take the script part into account (ticket #27). * Added a function to list all locales for which locale data is available. * Added a command-line option to the `pybabel` command which prints out all available locales (ticket #24). * The name of the command-line script has been changed from just `babel` to `pybabel` to avoid a conflict with the OpenBabel project (ticket #34). Acknowledgments ---------------- A big thank you to everyone who tried Babel and provided feedback, reported bugs, and/or contributed patches! Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Python Babel" group. To post to this group, send email to python-babel@googlegroups.com To unsubscribe from this group, send email to python-babel-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/python-babel?hl=en -~----------~----~----~----~------~----~------~--~--- ----- End forwarded message ----- -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ When we blindly adopt a religion, a political system, a literary dogma, we become automatons. We cease to grow... From dwayne@translate.org.za Mon Jul 2 05:07:48 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 02 Jul 2007 05:07:48 -0500 (CDT) Received: from etna.obsidianonline.net (etna.obsidian.co.za [196.36.119.67]) by unicode.org (8.13.4/8.12.11) with ESMTP id l62A7mxU002446 for ; Mon, 2 Jul 2007 05:07:48 -0500 Received: from localhost (localhost [127.0.0.1]) by etna.obsidianonline.net (Postfix) with ESMTP id 7933B5A8333 for ; Mon, 2 Jul 2007 12:07:41 +0200 (SAST) X-Virus-Scanned: amavisd-new at obsidianonline.net Received: from etna.obsidianonline.net ([127.0.0.1]) by localhost (etna.obsidianonline.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypZnoe2HzRaW for ; Mon, 2 Jul 2007 12:07:37 +0200 (SAST) Received: from [192.168.0.4] (dsl-242-218-145.telkomadsl.co.za [41.242.218.145]) by etna.obsidianonline.net (Postfix) with ESMTP id 36CA957F4B5 for ; Mon, 2 Jul 2007 12:07:37 +0200 (SAST) Subject: Google data From: Dwayne Bailey To: cldr-users@unicode.org Content-Type: text/plain Organization: Translate.org.za Date: Mon, 02 Jul 2007 12:03:47 +0200 Message-Id: <1183370627.4153.52.camel@dhcppc2> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 (2.10.1-4.fc7) Content-Transfer-Encoding: 7bit X-archive-position: 166 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: dwayne@translate.org.za Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Hi All, How do we reject Google data outright? I'm getting rubbish like this in Xhosa. Portugeuse -> portokugusseee English -> Isingesi -> should be isiNgesi I don't mind the suggestions. But we're getting Google with 4 votes and these are causing disputes with contributors from OOo who've spent time checking the these things against authorities and entering them into the survey tool. In Afrikaans we have a dispute over Feroes (sp) where Google has the German spelling while the CLDR has the correct Afrikaans spelling but the votes are equal. For Google it says "(default vote)", I'm not sure if that means that its a general vote or that in this case with neck on neck votes that it will default to the Google contribution. In the later case we'll move from the correct in 1.4 to incorrect for 1.5 if Google prevails. I've checked in the translation interface in Google. Some of the incorrect items I could find and alter. But I couldn't find others so I'm not sure where these are coming from, at least that would allow us to align the upstream as we've done many times with OpenOffice.org. Many of these issues are in language names, if we're happy to simply pull these from Google then it might also be good to consider pulling them in from other source: KDE, GNOME, Mozilla (we've translated many of these many times in various places). Its a good way to populate the lists if we need it for that. -- Dwayne Bailey Translate.org.za +27-12-460-1095 (w) +27-83-443-7114 (cell) From v-magdad@microsoft.com Mon Jul 2 11:18:26 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 02 Jul 2007 11:19:07 -0500 (CDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by unicode.org (8.13.4/8.12.11) with ESMTP id l62GIPdT015817; Mon, 2 Jul 2007 11:18:25 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.700.0; Mon, 2 Jul 2007 09:18:19 -0700 Received: from NA-EXMSG-C125.redmond.corp.microsoft.com ([157.54.61.91]) by tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) with mapi; Mon, 2 Jul 2007 09:18:19 -0700 From: "Magda Danish (Unicode)" To: " (unicode@unicode.org)" Date: Mon, 2 Jul 2007 09:18:19 -0700 Subject: Universal Declaration of Human Rights in Unicode Thread-Topic: Universal Declaration of Human Rights in Unicode Thread-Index: AQHHvMSaDtFbOg5QmU6LF5S6a13JOw== Message-ID: <871A62EA91884849A3BE952CA63832D0139693EC7B@NA-EXMSG-C125.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l62GIPdT015817 X-archive-position: 167 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: v-magdad@microsoft.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users MOUNTAIN VIEW, CA -- (MARKET WIRE) -- 07/02/07 -- The Unicode® Consortium announces a new project to make the United Nation's Universal Declaration of Human Rights available on the web, in as many languages as possible, using the power of Unicode. Unicode is ideally suited for this project because it is the universal character set, able to represent all languages of the world. The initial collection for the UDHR in Unicode project now contains more than 300 languages from Abkhaz to Zulu. For each language, the text of the UDHR is made available in the following Unicode-based formats: XML, plain text, HTML, and PDF. There are also links to resources for the languages, such as dictionaries and grammars. The Consortium is calling for participation to help complete this work, particularly by language experts, to improve and refine the data. Information on how you can participate can be found on the project's website at http://www.unicode.org/udhr/. The UDHR in Unicode project makes the Declaration more accessible world-wide by providing a uniform, easily searchable, standards-based set of translations. The Unicode community will also benefit by having access to a multi-lingual corpus, which can be used to test Unicode implementations, in particular for less widely used languages. For more information on the Unicode Standard, please visit http://www.unicode.org. About the Unicode Consortium The Unicode Consortium is a non-profit organization founded to develop, extend and promote use of the Unicode Standard and related globalization standards. The membership of the consortium represents a broad spectrum of corporations and organizations in the computer and information processing industry. Members are: Adobe Systems, Apple, Basis Technology, Denic e.G., Google, Government of India -- Ministry of Information Technology, Government of Pakistan -- National Language Authority, Government of Tamil Nadu -- Tamil Virtual University, HP, IBM, Justsystem, Microsoft, Monotype Imaging, Oracle, SAP, Sun Microsystems, Sybase, The University of California at Berkeley, Yahoo!, and over 100 Associate, Liaison, and Individual members. For more information, please contact the Unicode Consortium http://www.unicode.org/. From verdy_p@wanadoo.fr Mon Jul 2 17:14:40 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 02 Jul 2007 17:14:40 -0500 (CDT) Received: from smtp24.orange.fr (smtp24.orange.fr [193.252.22.27]) by unicode.org (8.13.4/8.12.11) with ESMTP id l62MEd9s007083 for ; Mon, 2 Jul 2007 17:14:40 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2414.orange.fr (SMTP Server) with ESMTP id 6F5151C0009A for ; Tue, 3 Jul 2007 00:14:34 +0200 (CEST) Received: from HARNON (APoitiers-156-1-42-9.w86-213.abo.wanadoo.fr [86.213.89.9]) by mwinf2414.orange.fr (SMTP Server) with ESMTP id BDF3C1C00092 for ; Tue, 3 Jul 2007 00:14:31 +0200 (CEST) X-ME-UUID: 20070702221431802.BDF3C1C00092@mwinf2414.orange.fr From: "Philippe Verdy" To: References: <1183370627.4153.52.camel@dhcppc2> Subject: RE: Google data Date: Tue, 3 Jul 2007 00:14:28 +0200 Organization: Ordinateur Personnel Message-ID: <007601c7bcf6$5c09c7b0$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: <1183370627.4153.52.camel@dhcppc2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace8kfM15RJhRt8pTJ+ZPhs8ri/TDAAYPblw Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id l62MEd9s007083 X-archive-position: 168 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 If you look closely at most entries made by Google, the automated entries that have been added are just Google search results according to bare statistics and suggestions. They appear as "Google (default) vote" and do not seem to be counted as actual votes (their weight is apparently 0), just as suggestions to help speed up the work for translators. The actual votes by Google's vetter do not display "(default)". It may be useful, during the proposal and vetting process to add alternate names to help disambiguate some cases. But Google default findings will not help you fond the best form: it may add plural forms, will not choose the preferred capitalisation, may remove needed accents. I'm not dissatisfied by actual Google votes (at least in the French locale where I could commit proposals and casts my votes). There are more problems with incoherent entries that must still be solved using forum discussions to help finding a consensus. Anyway, Apple is still late in applying the recent concensus everywhere, despite it helped resolve many disputes (so there are now very few issues remaining in the French locale for the names of languages, the most difficult part of the CLDR data, because of ambiguities and multiple names). The other parts that may cause problems are for the names of country and regions, but most of them should not cause a problem, only a few ones because of the existence of multiple forms: a common name, frequently used, a formal short name, a long name, and sometimes changes in orthographic rules for your locale (plus possible official changes in the formal name in the native language that is sometimes reflected in your locale, but still not common, for example with recent countries like Timor-Leste) A few disputes will remain with the abbreviated names for months and week days, but this can be solved easily. Finally some disputes are existing because some vetters have voted in the wrong locale, assuming that the locale associated to a language code was associated to all variants, when it is the ONLY option for the variant of a country that cannot have any specialization and inherit from it. For example, the French [fr] locale is used directly for French of France [fr_FR], and French Canadian specifializations, if they need to be different, should be made in [fr_CA] (this typically concerns mostly the date and time formats). I hope that, at least for all the major locales (i.e. the 10 first languages of Wikipedia for example), a concensus will be reached so that they can be used as a good cross-reference to help solving the ambiguities for other locales. Unfortunately, the CLDR data to translate most often lacks such contextual information. For now, we still lacks votes (despite of an existing consensus among existing vetters) to make all the necessary changes we have agreed. Especially from IBM and Apple that have only partly reviewed the data. The current vetting process does not really show a summary of the remaining disputes: notably, it does not display the case when everybody agrees for a change, but the current CLDR 1.5 proposal still reflects anold option, only because it was part of the previous (bogous) CLDR 1.4 release. Thanks, the CLDR 1.5 vetting process is now taking much longer than CLDR 1.4 was released much too soon with incorrect data (and not enough time of server availability to allow vetters to vote). I really hope that CLDR 1.5 Data will be much better than 1.4, but I fear it will be difficult for minority languages like isiXhosa due to the rare vetters present. So if you are one of them, beextremely careful about what you suggest, and reverify your votes over several days to see if it does not remain incoherences. I suggest you stop using votes directly from the long list; if you see some difference, don't modify from it (as you may have clicked elsewhere without notice), click on each item and vote for them separately. Philippe. > -----Message d'origine----- > De : cldr-users-bounce@unicode.org [mailto:cldr-users-bounce@unicode.org] > De la part de Dwayne Bailey > Envoyé : lundi 2 juillet 2007 12:04 > À : cldr-users@unicode.org > Objet : Google data > > Hi All, > > How do we reject Google data outright? I'm getting rubbish like this in > Xhosa. > > Portugeuse -> portokugusseee > English -> Isingesi -> should be isiNgesi > > I don't mind the suggestions. But we're getting Google with 4 votes and > these are causing disputes with contributors from OOo who've spent time > checking the these things against authorities and entering them into the > survey tool. From mark.edward.davis@gmail.com Mon Jul 2 19:51:04 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Mon, 02 Jul 2007 19:51:04 -0500 (CDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by unicode.org (8.13.4/8.12.11) with ESMTP id l630orM9018839 for ; Mon, 2 Jul 2007 19:51:02 -0500 Received: by wa-out-1112.google.com with SMTP id j40so2703709wah for ; Mon, 02 Jul 2007 17:50:52 -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=lw8+0KCg6aIggIb418JAKEY7b+PFly98RNvQ8yPswlPup9P/DygDC3EOPUw9a0iJuC/KLbigMgpWzbNR2DM1bbo/Xji/Val03q5xlFlwXS3jHKcWv/cQRH4kvTzypS3uqb97YwCE1RBKWHaMw+RmyAi66GGqF6sNlj6bT2tdGyo= 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=N6qL8mUyfxkz26S8ff7N6XH/c1GGEE6Bfi2Ogfxiej38YHL9yRAa2ie7AQ3w2SOdbERel0rpgk3/RTM2g4EQ4Ea3n1eLaywXmDYwG2E9k0/jGEXy8rwuiVLwJPKNNMWOM5vPaONrAPsvtwBCnVt175Cs5MDFGmq0jiOCrlDID54= Received: by 10.115.32.1 with SMTP id k1mr5630536waj.1183423852740; Mon, 02 Jul 2007 17:50:52 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Mon, 2 Jul 2007 17:50:52 -0700 (PDT) Message-ID: <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> Date: Mon, 2 Jul 2007 17:50:52 -0700 From: "Mark Davis" To: cldr-users@unicode.org Subject: Re: Google data In-Reply-To: <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_141973_11180830.1183423852702" References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> X-Google-Sender-Auth: 74896dcb79ee6fcd X-archive-position: 169 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_141973_11180830.1183423852702 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhdCBhbmFseXNpcyBpcyB3ZWxsLW1lYW50LCBidXQgbm90IHF1aXRlIHJpZ2h0LiBUaGUgZGVm YXVsdCBkYXRhIHdhcwpleHRyYWN0ZWQgZnJvbSBvdGhlciB0cmFuc2xhdGlvbiBkYXRhLCBub3Qg c3RhdGlzdGljYWxseSBkZXJpdmVkLgoKQmFjayB0byB0aGUgbWFpbiBpc3N1ZTogRGVmYXVsdCBk YXRhIGlzIGdpdmVuIGEgZGVmYXVsdCB2b3RlIGZyb20gdGhlCm9yZ2FuaXphdGlvbiAoaW4gdGhp cyBjYXNlLCBHb29nbGUpLCB3aGljaCBtZWFucyB0aGF0IGl0IGlzIGlnbm9yZWQgKmlmKgp0aGVy ZSBpcyBhbm90aGVyIHZvdGUgZnJvbSB0aGF0IHNvdXJjZS4gQnV0IG90aGVyd2lzZSBpdCBnZXRz IHdlaWdodGVkIGFzIGlmCml0IHdlcmUgYSB2b3RlIGZyb20gdGhlIG9yZ2FuaXphdGlvbi4KCkkg ZmlsZWQgYSBidWcgb24gdGhpcyBhdApodHRwOi8vd3d3LnVuaWNvZGUub3JnL2NsZHIvYnVncy9s b2NhbGUtYnVncz9maW5kaWQ9MTQxMSBmb3IgZGlzY3Vzc2lvbiBhdAp0aGUgbWVldGluZyB0b21v cnJvdyBtb3JuaW5nLiBJZiB5b3UgaGF2ZSBhbnkgZnVydGhlciBjb21tZW50cywgcGxlYXNlIGFk ZAp0aGVtIHRvIHRoYXQgYnVnIHJlcG9ydCBhcyBhIFJlcGx5LgoKTWFyawoKCk9uIDcvMi8wNywg UGhpbGlwcGUgVmVyZHkgPHZlcmR5X3BAd2FuYWRvby5mcj4gd3JvdGU6Cj4KPiBJZiB5b3UgbG9v ayBjbG9zZWx5IGF0IG1vc3QgZW50cmllcyBtYWRlIGJ5IEdvb2dsZSwgdGhlIGF1dG9tYXRlZCBl bnRyaWVzCj4gdGhhdCBoYXZlIGJlZW4gYWRkZWQgYXJlIGp1c3QgR29vZ2xlIHNlYXJjaCByZXN1 bHRzIGFjY29yZGluZyB0byBiYXJlCj4gc3RhdGlzdGljcyBhbmQgc3VnZ2VzdGlvbnMuIFRoZXkg YXBwZWFyIGFzICJHb29nbGUgKGRlZmF1bHQpIHZvdGUiIGFuZCBkbwo+IG5vdCBzZWVtIHRvIGJl IGNvdW50ZWQgYXMgYWN0dWFsIHZvdGVzICh0aGVpciB3ZWlnaHQgaXMgYXBwYXJlbnRseSAwKSwK PiBqdXN0Cj4gYXMgc3VnZ2VzdGlvbnMgdG8gaGVscCBzcGVlZCB1cCB0aGUgd29yayBmb3IgdHJh bnNsYXRvcnMuCj4KPiBUaGUgYWN0dWFsIHZvdGVzIGJ5IEdvb2dsZSdzIHZldHRlciBkbyBub3Qg ZGlzcGxheSAiKGRlZmF1bHQpIi4KPiBJdCBtYXkgYmUgdXNlZnVsLCBkdXJpbmcgdGhlIHByb3Bv c2FsIGFuZCB2ZXR0aW5nIHByb2Nlc3MgdG8gYWRkIGFsdGVybmF0ZQo+IG5hbWVzIHRvIGhlbHAg ZGlzYW1iaWd1YXRlIHNvbWUgY2FzZXMuCj4KPiBCdXQgR29vZ2xlIGRlZmF1bHQgZmluZGluZ3Mg d2lsbCBub3QgaGVscCB5b3UgZm9uZCB0aGUgYmVzdCBmb3JtOiBpdCBtYXkKPiBhZGQKPiBwbHVy YWwgZm9ybXMsIHdpbGwgbm90IGNob29zZSB0aGUgcHJlZmVycmVkIGNhcGl0YWxpc2F0aW9uLCBt YXkgcmVtb3ZlCj4gbmVlZGVkIGFjY2VudHMuCj4KPiBJJ20gbm90IGRpc3NhdGlzZmllZCBieSBh Y3R1YWwgR29vZ2xlIHZvdGVzIChhdCBsZWFzdCBpbiB0aGUgRnJlbmNoIGxvY2FsZQo+IHdoZXJl IEkgY291bGQgY29tbWl0IHByb3Bvc2FscyBhbmQgY2FzdHMgbXkgdm90ZXMpLiBUaGVyZSBhcmUg bW9yZQo+IHByb2JsZW1zCj4gd2l0aCBpbmNvaGVyZW50IGVudHJpZXMgdGhhdCBtdXN0IHN0aWxs IGJlIHNvbHZlZCB1c2luZyBmb3J1bSBkaXNjdXNzaW9ucwo+IHRvCj4gaGVscCBmaW5kaW5nIGEg Y29uc2Vuc3VzLiBBbnl3YXksIEFwcGxlIGlzIHN0aWxsIGxhdGUgaW4gYXBwbHlpbmcgdGhlCj4g cmVjZW50Cj4gY29uY2Vuc3VzIGV2ZXJ5d2hlcmUsIGRlc3BpdGUgaXQgaGVscGVkIHJlc29sdmUg bWFueSBkaXNwdXRlcyAoc28gdGhlcmUKPiBhcmUKPiBub3cgdmVyeSBmZXcgaXNzdWVzIHJlbWFp bmluZyBpbiB0aGUgRnJlbmNoIGxvY2FsZSBmb3IgdGhlIG5hbWVzIG9mCj4gbGFuZ3VhZ2VzLCB0 aGUgbW9zdCBkaWZmaWN1bHQgcGFydCBvZiB0aGUgQ0xEUiBkYXRhLCBiZWNhdXNlIG9mCj4gYW1i aWd1aXRpZXMKPiBhbmQgbXVsdGlwbGUgbmFtZXMpLgo+Cj4gVGhlIG90aGVyIHBhcnRzIHRoYXQg bWF5IGNhdXNlIHByb2JsZW1zIGFyZSBmb3IgdGhlIG5hbWVzIG9mIGNvdW50cnkgYW5kCj4gcmVn aW9ucywgYnV0IG1vc3Qgb2YgdGhlbSBzaG91bGQgbm90IGNhdXNlIGEgcHJvYmxlbSwgb25seSBh IGZldyBvbmVzCj4gYmVjYXVzZSBvZiB0aGUgZXhpc3RlbmNlIG9mIG11bHRpcGxlIGZvcm1zOiBh IGNvbW1vbiBuYW1lLCBmcmVxdWVudGx5Cj4gdXNlZCwKPiBhIGZvcm1hbCBzaG9ydCBuYW1lLCBh IGxvbmcgbmFtZSwgYW5kIHNvbWV0aW1lcyBjaGFuZ2VzIGluIG9ydGhvZ3JhcGhpYwo+IHJ1bGVz IGZvciB5b3VyIGxvY2FsZSAocGx1cyBwb3NzaWJsZSBvZmZpY2lhbCBjaGFuZ2VzIGluIHRoZSBm b3JtYWwgbmFtZQo+IGluCj4gdGhlIG5hdGl2ZSBsYW5ndWFnZSB0aGF0IGlzIHNvbWV0aW1lcyBy ZWZsZWN0ZWQgaW4geW91ciBsb2NhbGUsIGJ1dCBzdGlsbAo+IG5vdCBjb21tb24sIGZvciBleGFt cGxlIHdpdGggcmVjZW50IGNvdW50cmllcyBsaWtlIFRpbW9yLUxlc3RlKQo+Cj4gQSBmZXcgZGlz cHV0ZXMgd2lsbCByZW1haW4gd2l0aCB0aGUgYWJicmV2aWF0ZWQgbmFtZXMgZm9yIG1vbnRocyBh bmQgd2Vlawo+IGRheXMsIGJ1dCB0aGlzIGNhbiBiZSBzb2x2ZWQgZWFzaWx5Lgo+Cj4gRmluYWxs eSBzb21lIGRpc3B1dGVzIGFyZSBleGlzdGluZyBiZWNhdXNlIHNvbWUgdmV0dGVycyBoYXZlIHZv dGVkIGluIHRoZQo+IHdyb25nIGxvY2FsZSwgYXNzdW1pbmcgdGhhdCB0aGUgbG9jYWxlIGFzc29j aWF0ZWQgdG8gYSBsYW5ndWFnZSBjb2RlIHdhcwo+IGFzc29jaWF0ZWQgdG8gYWxsIHZhcmlhbnRz LCB3aGVuIGl0IGlzIHRoZSBPTkxZIG9wdGlvbiBmb3IgdGhlIHZhcmlhbnQgb2YKPiBhCj4gY291 bnRyeSB0aGF0IGNhbm5vdCBoYXZlIGFueSBzcGVjaWFsaXphdGlvbiBhbmQgaW5oZXJpdCBmcm9t IGl0LiBGb3IKPiBleGFtcGxlLCB0aGUgRnJlbmNoIFtmcl0gbG9jYWxlIGlzIHVzZWQgZGlyZWN0 bHkgZm9yIEZyZW5jaCBvZiBGcmFuY2UKPiBbZnJfRlJdLCBhbmQgRnJlbmNoIENhbmFkaWFuIHNw ZWNpZmlhbGl6YXRpb25zLCBpZiB0aGV5IG5lZWQgdG8gYmUKPiBkaWZmZXJlbnQsIHNob3VsZCBi ZSBtYWRlIGluIFtmcl9DQV0gKHRoaXMgdHlwaWNhbGx5IGNvbmNlcm5zIG1vc3RseSB0aGUKPiBk YXRlIGFuZCB0aW1lIGZvcm1hdHMpLgo+Cj4gSSBob3BlIHRoYXQsIGF0IGxlYXN0IGZvciBhbGwg dGhlIG1ham9yIGxvY2FsZXMgKGkuZS4gdGhlIDEwIGZpcnN0Cj4gbGFuZ3VhZ2VzCj4gb2YgV2lr aXBlZGlhIGZvciBleGFtcGxlKSwgYSBjb25jZW5zdXMgd2lsbCBiZSByZWFjaGVkIHNvIHRoYXQg dGhleSBjYW4gYmUKPiB1c2VkIGFzIGEgZ29vZCBjcm9zcy1yZWZlcmVuY2UgdG8gaGVscCBzb2x2 aW5nIHRoZSBhbWJpZ3VpdGllcyBmb3Igb3RoZXIKPiBsb2NhbGVzLiBVbmZvcnR1bmF0ZWx5LCB0 aGUgQ0xEUiBkYXRhIHRvIHRyYW5zbGF0ZSBtb3N0IG9mdGVuIGxhY2tzIHN1Y2gKPiBjb250ZXh0 dWFsIGluZm9ybWF0aW9uLgo+Cj4gRm9yIG5vdywgd2Ugc3RpbGwgbGFja3Mgdm90ZXMgKGRlc3Bp dGUgb2YgYW4gZXhpc3RpbmcgY29uc2Vuc3VzIGFtb25nCj4gZXhpc3RpbmcgdmV0dGVycykgdG8g bWFrZSBhbGwgdGhlIG5lY2Vzc2FyeSBjaGFuZ2VzIHdlIGhhdmUgYWdyZWVkLgo+IEVzcGVjaWFs bHkgZnJvbSBJQk0gYW5kIEFwcGxlIHRoYXQgaGF2ZSBvbmx5IHBhcnRseSByZXZpZXdlZCB0aGUg ZGF0YS4KPgo+IFRoZSBjdXJyZW50IHZldHRpbmcgcHJvY2VzcyBkb2VzIG5vdCByZWFsbHkgc2hv dyBhIHN1bW1hcnkgb2YgdGhlCj4gcmVtYWluaW5nCj4gZGlzcHV0ZXM6IG5vdGFibHksIGl0IGRv ZXMgbm90IGRpc3BsYXkgdGhlIGNhc2Ugd2hlbiBldmVyeWJvZHkgYWdyZWVzIGZvcgo+IGEKPiBj aGFuZ2UsIGJ1dCB0aGUgY3VycmVudCBDTERSIDEuNSBwcm9wb3NhbCBzdGlsbCByZWZsZWN0cyBh bm9sZCBvcHRpb24sCj4gb25seQo+IGJlY2F1c2UgaXQgd2FzIHBhcnQgb2YgdGhlIHByZXZpb3Vz IChib2dvdXMpIENMRFIgMS40IHJlbGVhc2UuCj4KPiBUaGFua3MsIHRoZSBDTERSIDEuNSB2ZXR0 aW5nIHByb2Nlc3MgaXMgbm93IHRha2luZyBtdWNoIGxvbmdlciB0aGFuIENMRFIKPiAxLjQKPiB3 YXMgcmVsZWFzZWQgbXVjaCB0b28gc29vbiB3aXRoIGluY29ycmVjdCBkYXRhIChhbmQgbm90IGVu b3VnaCB0aW1lIG9mCj4gc2VydmVyIGF2YWlsYWJpbGl0eSB0byBhbGxvdyB2ZXR0ZXJzIHRvIHZv dGUpLgo+Cj4gSSByZWFsbHkgaG9wZSB0aGF0IENMRFIgMS41IERhdGEgd2lsbCBiZSBtdWNoIGJl dHRlciB0aGFuIDEuNCwgYnV0IEkgZmVhcgo+IGl0Cj4gd2lsbCBiZSBkaWZmaWN1bHQgZm9yIG1p bm9yaXR5IGxhbmd1YWdlcyBsaWtlIGlzaVhob3NhIGR1ZSB0byB0aGUgcmFyZQo+IHZldHRlcnMg cHJlc2VudC4gU28gaWYgeW91IGFyZSBvbmUgb2YgdGhlbSwgYmVleHRyZW1lbHkgY2FyZWZ1bCBh Ym91dCB3aGF0Cj4geW91IHN1Z2dlc3QsIGFuZCByZXZlcmlmeSB5b3VyIHZvdGVzIG92ZXIgc2V2 ZXJhbCBkYXlzIHRvIHNlZSBpZiBpdCBkb2VzCj4gbm90Cj4gcmVtYWluIGluY29oZXJlbmNlcy4g SSBzdWdnZXN0IHlvdSBzdG9wIHVzaW5nICB2b3RlcyBkaXJlY3RseSBmcm9tIHRoZQo+IGxvbmcK PiBsaXN0OyBpZiB5b3Ugc2VlIHNvbWUgZGlmZmVyZW5jZSwgZG9uJ3QgbW9kaWZ5IGZyb20gaXQg KGFzIHlvdSBtYXkgaGF2ZQo+IGNsaWNrZWQgZWxzZXdoZXJlIHdpdGhvdXQgbm90aWNlKSwgY2xp Y2sgb24gZWFjaCBpdGVtIGFuZCB2b3RlIGZvciB0aGVtCj4gc2VwYXJhdGVseS4KPgo+IFBoaWxp cHBlLgo+Cj4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0KPiA+IERlOiBjbGRyLXVzZXJz LWJvdW5jZUB1bmljb2RlLm9yZyBbbWFpbHRvOmNsZHItdXNlcnMtYm91bmNlQHVuaWNvZGUub3Jn XQo+ID4gRGUgbGEgcGFydCBkZSBEd2F5bmUgQmFpbGV5Cj4gPiBFbnZvecOpOiBsdW5kaSAyIGp1 aWxsZXQgMjAwNyAxMjowNAo+ID4gw4A6IGNsZHItdXNlcnNAdW5pY29kZS5vcmcKPiA+IE9iamV0 OiBHb29nbGUgZGF0YQo+ID4KPiA+IEhpIEFsbCwKPiA+Cj4gPiBIb3cgZG8gd2UgcmVqZWN0IEdv b2dsZSBkYXRhIG91dHJpZ2h0PyAgSSdtIGdldHRpbmcgcnViYmlzaCBsaWtlIHRoaXMgaW4KPiA+ IFhob3NhLgo+ID4KPiA+IFBvcnR1Z2V1c2UgLT4gcG9ydG9rdWd1c3NlZWUKPiA+IEVuZ2xpc2gg LT4gSXNpbmdlc2kgLT4gc2hvdWxkIGJlIGlzaU5nZXNpCj4gPgo+ID4gSSBkb24ndCBtaW5kIHRo ZSBzdWdnZXN0aW9ucy4gIEJ1dCB3ZSdyZSBnZXR0aW5nIEdvb2dsZSB3aXRoIDQgdm90ZXMgYW5k Cj4gPiB0aGVzZSBhcmUgY2F1c2luZyBkaXNwdXRlcyB3aXRoIGNvbnRyaWJ1dG9ycyBmcm9tIE9P byB3aG8ndmUgc3BlbnQgdGltZQo+ID4gY2hlY2tpbmcgdGhlIHRoZXNlIHRoaW5ncyBhZ2FpbnN0 IGF1dGhvcml0aWVzIGFuZCBlbnRlcmluZyB0aGVtIGludG8gdGhlCj4gPiBzdXJ2ZXkgdG9vbC4K Pgo+Cj4KPgo+Cj4KCgotLSAKTWFyawo= ------=_Part_141973_11180830.1183423852702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhdCBhbmFseXNpcyBpcyB3ZWxsLW1lYW50LCBidXQgbm90IHF1aXRlIHJpZ2h0LiBUaGUgZGVm YXVsdCBkYXRhIHdhcyBleHRyYWN0ZWQgZnJvbSBvdGhlciB0cmFuc2xhdGlvbiBkYXRhLCBub3Qg c3RhdGlzdGljYWxseSBkZXJpdmVkLjxicj48YnI+QmFjayB0byB0aGUgbWFpbiBpc3N1ZTogRGVm YXVsdCBkYXRhIGlzIGdpdmVuIGEgZGVmYXVsdCB2b3RlIGZyb20gdGhlIG9yZ2FuaXphdGlvbiAo aW4gdGhpcyBjYXNlLCBHb29nbGUpLCB3aGljaCBtZWFucyB0aGF0IGl0IGlzIGlnbm9yZWQgKmlm KiB0aGVyZSBpcyBhbm90aGVyIHZvdGUgZnJvbSB0aGF0IHNvdXJjZS4gQnV0IG90aGVyd2lzZSBp dCBnZXRzIHdlaWdodGVkIGFzIGlmIGl0IHdlcmUgYSB2b3RlIGZyb20gdGhlIG9yZ2FuaXphdGlv bi4KPGJyPjxicj5JIGZpbGVkIGEgYnVnIG9uIHRoaXMgYXQgPGEgaHJlZj0iaHR0cDovL3d3dy51 bmljb2RlLm9yZy9jbGRyL2J1Z3MvbG9jYWxlLWJ1Z3M/ZmluZGlkPTE0MTEiPmh0dHA6Ly93d3cu dW5pY29kZS5vcmcvY2xkci9idWdzL2xvY2FsZS1idWdzP2ZpbmRpZD0xNDExPC9hPiBmb3IgZGlz Y3Vzc2lvbiBhdCB0aGUgbWVldGluZyB0b21vcnJvdyBtb3JuaW5nLiBJZiB5b3UgaGF2ZSBhbnkg ZnVydGhlciBjb21tZW50cywgcGxlYXNlIGFkZCB0aGVtIHRvIHRoYXQgYnVnIHJlcG9ydCBhcyBh IFJlcGx5Lgo8YnI+PGJyPk1hcms8YnI+PGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gNy8yLzA3LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+UGhpbGlwcGUgVmVy ZHk8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86dmVyZHlfcEB3YW5hZG9vLmZyIj52ZXJkeV9wQHdh bmFkb28uZnI8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1h cmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CklmIHlvdSBsb29r IGNsb3NlbHkgYXQgbW9zdCBlbnRyaWVzIG1hZGUgYnkgR29vZ2xlLCB0aGUgYXV0b21hdGVkIGVu dHJpZXM8YnI+dGhhdCBoYXZlIGJlZW4gYWRkZWQgYXJlIGp1c3QgR29vZ2xlIHNlYXJjaCByZXN1 bHRzIGFjY29yZGluZyB0byBiYXJlPGJyPnN0YXRpc3RpY3MgYW5kIHN1Z2dlc3Rpb25zLiBUaGV5 IGFwcGVhciBhcyAmcXVvdDtHb29nbGUgKGRlZmF1bHQpIHZvdGUmcXVvdDsgYW5kIGRvCjxicj5u b3Qgc2VlbSB0byBiZSBjb3VudGVkIGFzIGFjdHVhbCB2b3RlcyAodGhlaXIgd2VpZ2h0IGlzIGFw cGFyZW50bHkgMCksIGp1c3Q8YnI+YXMgc3VnZ2VzdGlvbnMgdG8gaGVscCBzcGVlZCB1cCB0aGUg d29yayBmb3IgdHJhbnNsYXRvcnMuPGJyPjxicj5UaGUgYWN0dWFsIHZvdGVzIGJ5IEdvb2dsZSYj Mzk7cyB2ZXR0ZXIgZG8gbm90IGRpc3BsYXkgJnF1b3Q7KGRlZmF1bHQpJnF1b3Q7Lgo8YnI+SXQg bWF5IGJlIHVzZWZ1bCwgZHVyaW5nIHRoZSBwcm9wb3NhbCBhbmQgdmV0dGluZyBwcm9jZXNzIHRv IGFkZCBhbHRlcm5hdGU8YnI+bmFtZXMgdG8gaGVscCBkaXNhbWJpZ3VhdGUgc29tZSBjYXNlcy48 YnI+PGJyPkJ1dCBHb29nbGUgZGVmYXVsdCBmaW5kaW5ncyB3aWxsIG5vdCBoZWxwIHlvdSBmb25k IHRoZSBiZXN0IGZvcm06IGl0IG1heSBhZGQ8YnI+cGx1cmFsIGZvcm1zLCB3aWxsIG5vdCBjaG9v c2UgdGhlIHByZWZlcnJlZCBjYXBpdGFsaXNhdGlvbiwgbWF5IHJlbW92ZQo8YnI+bmVlZGVkIGFj Y2VudHMuPGJyPjxicj5JJiMzOTttIG5vdCBkaXNzYXRpc2ZpZWQgYnkgYWN0dWFsIEdvb2dsZSB2 b3RlcyAoYXQgbGVhc3QgaW4gdGhlIEZyZW5jaCBsb2NhbGU8YnI+d2hlcmUgSSBjb3VsZCBjb21t aXQgcHJvcG9zYWxzIGFuZCBjYXN0cyBteSB2b3RlcykuIFRoZXJlIGFyZSBtb3JlIHByb2JsZW1z PGJyPndpdGggaW5jb2hlcmVudCBlbnRyaWVzIHRoYXQgbXVzdCBzdGlsbCBiZSBzb2x2ZWQgdXNp bmcgZm9ydW0gZGlzY3Vzc2lvbnMgdG8KPGJyPmhlbHAgZmluZGluZyBhIGNvbnNlbnN1cy4gQW55 d2F5LCBBcHBsZSBpcyBzdGlsbCBsYXRlIGluIGFwcGx5aW5nIHRoZSByZWNlbnQ8YnI+Y29uY2Vu c3VzIGV2ZXJ5d2hlcmUsIGRlc3BpdGUgaXQgaGVscGVkIHJlc29sdmUgbWFueSBkaXNwdXRlcyAo c28gdGhlcmUgYXJlPGJyPm5vdyB2ZXJ5IGZldyBpc3N1ZXMgcmVtYWluaW5nIGluIHRoZSBGcmVu Y2ggbG9jYWxlIGZvciB0aGUgbmFtZXMgb2YKPGJyPmxhbmd1YWdlcywgdGhlIG1vc3QgZGlmZmlj dWx0IHBhcnQgb2YgdGhlIENMRFIgZGF0YSwgYmVjYXVzZSBvZiBhbWJpZ3VpdGllczxicj5hbmQg bXVsdGlwbGUgbmFtZXMpLjxicj48YnI+VGhlIG90aGVyIHBhcnRzIHRoYXQgbWF5IGNhdXNlIHBy b2JsZW1zIGFyZSBmb3IgdGhlIG5hbWVzIG9mIGNvdW50cnkgYW5kPGJyPnJlZ2lvbnMsIGJ1dCBt b3N0IG9mIHRoZW0gc2hvdWxkIG5vdCBjYXVzZSBhIHByb2JsZW0sIG9ubHkgYSBmZXcgb25lcwo8 YnI+YmVjYXVzZSBvZiB0aGUgZXhpc3RlbmNlIG9mIG11bHRpcGxlIGZvcm1zOiBhIGNvbW1vbiBu YW1lLCBmcmVxdWVudGx5IHVzZWQsPGJyPmEgZm9ybWFsIHNob3J0IG5hbWUsIGEgbG9uZyBuYW1l LCBhbmQgc29tZXRpbWVzIGNoYW5nZXMgaW4gb3J0aG9ncmFwaGljPGJyPnJ1bGVzIGZvciB5b3Vy IGxvY2FsZSAocGx1cyBwb3NzaWJsZSBvZmZpY2lhbCBjaGFuZ2VzIGluIHRoZSBmb3JtYWwgbmFt ZSBpbgo8YnI+dGhlIG5hdGl2ZSBsYW5ndWFnZSB0aGF0IGlzIHNvbWV0aW1lcyByZWZsZWN0ZWQg aW4geW91ciBsb2NhbGUsIGJ1dCBzdGlsbDxicj5ub3QgY29tbW9uLCBmb3IgZXhhbXBsZSB3aXRo IHJlY2VudCBjb3VudHJpZXMgbGlrZSBUaW1vci1MZXN0ZSk8YnI+PGJyPkEgZmV3IGRpc3B1dGVz IHdpbGwgcmVtYWluIHdpdGggdGhlIGFiYnJldmlhdGVkIG5hbWVzIGZvciBtb250aHMgYW5kIHdl ZWsKPGJyPmRheXMsIGJ1dCB0aGlzIGNhbiBiZSBzb2x2ZWQgZWFzaWx5Ljxicj48YnI+RmluYWxs eSBzb21lIGRpc3B1dGVzIGFyZSBleGlzdGluZyBiZWNhdXNlIHNvbWUgdmV0dGVycyBoYXZlIHZv dGVkIGluIHRoZTxicj53cm9uZyBsb2NhbGUsIGFzc3VtaW5nIHRoYXQgdGhlIGxvY2FsZSBhc3Nv Y2lhdGVkIHRvIGEgbGFuZ3VhZ2UgY29kZSB3YXM8YnI+YXNzb2NpYXRlZCB0byBhbGwgdmFyaWFu dHMsIHdoZW4gaXQgaXMgdGhlIE9OTFkgb3B0aW9uIGZvciB0aGUgdmFyaWFudCBvZiBhCjxicj5j b3VudHJ5IHRoYXQgY2Fubm90IGhhdmUgYW55IHNwZWNpYWxpemF0aW9uIGFuZCBpbmhlcml0IGZy b20gaXQuIEZvcjxicj5leGFtcGxlLCB0aGUgRnJlbmNoIFtmcl0gbG9jYWxlIGlzIHVzZWQgZGly ZWN0bHkgZm9yIEZyZW5jaCBvZiBGcmFuY2U8YnI+W2ZyX0ZSXSwgYW5kIEZyZW5jaCBDYW5hZGlh biBzcGVjaWZpYWxpemF0aW9ucywgaWYgdGhleSBuZWVkIHRvIGJlPGJyPmRpZmZlcmVudCwgc2hv dWxkIGJlIG1hZGUgaW4gW2ZyX0NBXSAodGhpcyB0eXBpY2FsbHkgY29uY2VybnMgbW9zdGx5IHRo ZQo8YnI+ZGF0ZSBhbmQgdGltZSBmb3JtYXRzKS48YnI+PGJyPkkgaG9wZSB0aGF0LCBhdCBsZWFz dCBmb3IgYWxsIHRoZSBtYWpvciBsb2NhbGVzIChpLmUuIHRoZSAxMCBmaXJzdCBsYW5ndWFnZXM8 YnI+b2YgV2lraXBlZGlhIGZvciBleGFtcGxlKSwgYSBjb25jZW5zdXMgd2lsbCBiZSByZWFjaGVk IHNvIHRoYXQgdGhleSBjYW4gYmU8YnI+dXNlZCBhcyBhIGdvb2QgY3Jvc3MtcmVmZXJlbmNlIHRv IGhlbHAgc29sdmluZyB0aGUgYW1iaWd1aXRpZXMgZm9yIG90aGVyCjxicj5sb2NhbGVzLiBVbmZv cnR1bmF0ZWx5LCB0aGUgQ0xEUiBkYXRhIHRvIHRyYW5zbGF0ZSBtb3N0IG9mdGVuIGxhY2tzIHN1 Y2g8YnI+Y29udGV4dHVhbCBpbmZvcm1hdGlvbi48YnI+PGJyPkZvciBub3csIHdlIHN0aWxsIGxh Y2tzIHZvdGVzIChkZXNwaXRlIG9mIGFuIGV4aXN0aW5nIGNvbnNlbnN1cyBhbW9uZzxicj5leGlz dGluZyB2ZXR0ZXJzKSB0byBtYWtlIGFsbCB0aGUgbmVjZXNzYXJ5IGNoYW5nZXMgd2UgaGF2ZSBh Z3JlZWQuCjxicj5Fc3BlY2lhbGx5IGZyb20gSUJNIGFuZCBBcHBsZSB0aGF0IGhhdmUgb25seSBw YXJ0bHkgcmV2aWV3ZWQgdGhlIGRhdGEuPGJyPjxicj5UaGUgY3VycmVudCB2ZXR0aW5nIHByb2Nl c3MgZG9lcyBub3QgcmVhbGx5IHNob3cgYSBzdW1tYXJ5IG9mIHRoZSByZW1haW5pbmc8YnI+ZGlz cHV0ZXM6IG5vdGFibHksIGl0IGRvZXMgbm90IGRpc3BsYXkgdGhlIGNhc2Ugd2hlbiBldmVyeWJv ZHkgYWdyZWVzIGZvciBhCjxicj5jaGFuZ2UsIGJ1dCB0aGUgY3VycmVudCBDTERSIDEuNSBwcm9w b3NhbCBzdGlsbCByZWZsZWN0cyBhbm9sZCBvcHRpb24sIG9ubHk8YnI+YmVjYXVzZSBpdCB3YXMg cGFydCBvZiB0aGUgcHJldmlvdXMgKGJvZ291cykgQ0xEUiAxLjQgcmVsZWFzZS48YnI+PGJyPlRo YW5rcywgdGhlIENMRFIgMS41IHZldHRpbmcgcHJvY2VzcyBpcyBub3cgdGFraW5nIG11Y2ggbG9u Z2VyIHRoYW4gQ0xEUiAKMS40PGJyPndhcyByZWxlYXNlZCBtdWNoIHRvbyBzb29uIHdpdGggaW5j b3JyZWN0IGRhdGEgKGFuZCBub3QgZW5vdWdoIHRpbWUgb2Y8YnI+c2VydmVyIGF2YWlsYWJpbGl0 eSB0byBhbGxvdyB2ZXR0ZXJzIHRvIHZvdGUpLjxicj48YnI+SSByZWFsbHkgaG9wZSB0aGF0IENM RFIgMS41IERhdGEgd2lsbCBiZSBtdWNoIGJldHRlciB0aGFuIDEuNCwgYnV0IEkgZmVhciBpdDxi cj53aWxsIGJlIGRpZmZpY3VsdCBmb3IgbWlub3JpdHkgbGFuZ3VhZ2VzIGxpa2UgaXNpWGhvc2Eg ZHVlIHRvIHRoZSByYXJlCjxicj52ZXR0ZXJzIHByZXNlbnQuIFNvIGlmIHlvdSBhcmUgb25lIG9m IHRoZW0sIGJlZXh0cmVtZWx5IGNhcmVmdWwgYWJvdXQgd2hhdDxicj55b3Ugc3VnZ2VzdCwgYW5k IHJldmVyaWZ5IHlvdXIgdm90ZXMgb3ZlciBzZXZlcmFsIGRheXMgdG8gc2VlIGlmIGl0IGRvZXMg bm90PGJyPnJlbWFpbiBpbmNvaGVyZW5jZXMuIEkgc3VnZ2VzdCB5b3Ugc3RvcCB1c2luZyZuYnNw OyZuYnNwO3ZvdGVzIGRpcmVjdGx5IGZyb20gdGhlIGxvbmcKPGJyPmxpc3Q7IGlmIHlvdSBzZWUg c29tZSBkaWZmZXJlbmNlLCBkb24mIzM5O3QgbW9kaWZ5IGZyb20gaXQgKGFzIHlvdSBtYXkgaGF2 ZTxicj5jbGlja2VkIGVsc2V3aGVyZSB3aXRob3V0IG5vdGljZSksIGNsaWNrIG9uIGVhY2ggaXRl bSBhbmQgdm90ZSBmb3IgdGhlbTxicj5zZXBhcmF0ZWx5Ljxicj48YnI+UGhpbGlwcGUuPGJyPjxi cj4mZ3Q7IC0tLS0tTWVzc2FnZSBkJiMzOTtvcmlnaW5lLS0tLS0KPGJyPiZndDsgRGU6IDxhIGhy ZWY9Im1haWx0bzpjbGRyLXVzZXJzLWJvdW5jZUB1bmljb2RlLm9yZyI+Y2xkci11c2Vycy1ib3Vu Y2VAdW5pY29kZS5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNsZHItdXNlcnMtYm91 bmNlQHVuaWNvZGUub3JnIj5jbGRyLXVzZXJzLWJvdW5jZUB1bmljb2RlLm9yZzwvYT5dPGJyPiZn dDsgRGUgbGEgcGFydCBkZSBEd2F5bmUgQmFpbGV5PGJyPgomZ3Q7IEVudm95w6k6IGx1bmRpIDIg anVpbGxldCAyMDA3IDEyOjA0PGJyPiZndDsgw4A6IDxhIGhyZWY9Im1haWx0bzpjbGRyLXVzZXJz QHVuaWNvZGUub3JnIj5jbGRyLXVzZXJzQHVuaWNvZGUub3JnPC9hPjxicj4mZ3Q7IE9iamV0OiBH b29nbGUgZGF0YTxicj4mZ3Q7PGJyPiZndDsgSGkgQWxsLDxicj4mZ3Q7PGJyPiZndDsgSG93IGRv IHdlIHJlamVjdCBHb29nbGUgZGF0YSBvdXRyaWdodD8mbmJzcDsmbmJzcDtJJiMzOTttIGdldHRp bmcgcnViYmlzaCBsaWtlIHRoaXMgaW4KPGJyPiZndDsgWGhvc2EuPGJyPiZndDs8YnI+Jmd0OyBQ b3J0dWdldXNlIC0mZ3Q7IHBvcnRva3VndXNzZWVlPGJyPiZndDsgRW5nbGlzaCAtJmd0OyBJc2lu Z2VzaSAtJmd0OyBzaG91bGQgYmUgaXNpTmdlc2k8YnI+Jmd0Ozxicj4mZ3Q7IEkgZG9uJiMzOTt0 IG1pbmQgdGhlIHN1Z2dlc3Rpb25zLiZuYnNwOyZuYnNwO0J1dCB3ZSYjMzk7cmUgZ2V0dGluZyBH b29nbGUgd2l0aCA0IHZvdGVzIGFuZDxicj4mZ3Q7IHRoZXNlIGFyZSBjYXVzaW5nIGRpc3B1dGVz IHdpdGggY29udHJpYnV0b3JzIGZyb20gT09vIHdobyYjMzk7dmUgc3BlbnQgdGltZQo8YnI+Jmd0 OyBjaGVja2luZyB0aGUgdGhlc2UgdGhpbmdzIGFnYWluc3QgYXV0aG9yaXRpZXMgYW5kIGVudGVy aW5nIHRoZW0gaW50byB0aGU8YnI+Jmd0OyBzdXJ2ZXkgdG9vbC48YnI+PGJyPjxicj48YnI+PGJy Pjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPk1h cmsK ------=_Part_141973_11180830.1183423852702-- From yury.tarasievich@gmail.com Tue Jul 3 02:38:03 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 02:38:03 -0500 (CDT) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.233]) by unicode.org (8.13.4/8.12.11) with ESMTP id l637c2k7024469 for ; Tue, 3 Jul 2007 02:38:03 -0500 Received: by nz-out-0506.google.com with SMTP id x3so1077777nzd for ; Tue, 03 Jul 2007 00:38:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J1fXXa04a2ceCVI6IRuRArpOVx3LbX4qn3tI2mKviiG2OhxqfEwbhn6U+8Y5ZqKkzRaSJwUlU4aDm+6uGjdVTAHYVi7w0HoIofHdhC2XTmBQZIsoVp5PQUHXzUr0wo2RNbfvhRaHGjteOdefyhAcCS8wXbd2KJAQmQ5L4zYnGJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i5EuSocl8wpiqe+kno1kmPafQbtap+QspCmGiyyUazpbxQJtMFENkcXpnJVIp+PzzzBftHyqbqjSU8OaNp/VEaDTkrlZ+2Q9KQngUZV91GRDNxfPBu9iPHGGM+mzAI4IAXJSbIxNEkdolIvCS/wk074FLr0Zqfgt5LyVhkLdX5k= Received: by 10.114.184.16 with SMTP id h16mr5951210waf.1183448282089; Tue, 03 Jul 2007 00:38:02 -0700 (PDT) Received: by 10.114.184.20 with HTTP; Tue, 3 Jul 2007 00:38:02 -0700 (PDT) Message-ID: <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> Date: Tue, 3 Jul 2007 10:38:02 +0300 From: "Yury Tarasievich" To: cldr-users@unicode.org Subject: Re: Google data In-Reply-To: <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> X-archive-position: 170 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: yury.tarasievich@gmail.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Two questions to the maintainers of the data: 1. Is there no academic review or some sanity check of what you release? 2. Is there a procedure to request complete excluding the locale from the release? At the very least, to freeze the Belarusian data at 1.4 revision? The Belarusian locale data had some glaring errors before (cf. my emails to this list), but now it is a *raving mess*, supposedly after the "google tool" working on it. If that's the way CLDR treats culture-related data, I'm not even going to bother with correcting that. 1. In language names, there's now quite a quantity of entries written down in a distorted (in-group and non-normative) variant of Belarusian cultivated on Internet. 2. Some entries are plainly somebody's uneducated invention (e.g., entry for afrikaans), unexplainable even by distortion. 3. To top that, the majority of google entries in languages are grammatically corrupt (wrong declension). --- From srl@icu-project.org Tue Jul 3 02:52:16 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 02:52:16 -0500 (CDT) 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 l637qGm5000710 for ; Tue, 3 Jul 2007 02:52:16 -0500 Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.102]) by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1I5dBH-000HEj-KY for cldr-users@unicode.org; Tue, 03 Jul 2007 07:52:15 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-47--1016520675 Message-Id: <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> From: "Steven R. Loomis" Subject: Re: Google data Date: Tue, 3 Jul 2007 00:51:49 -0700 To: cldr-users@unicode.org X-Mailer: Apple Mail (2.752.3) X-archive-position: 171 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-47--1016520675 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 03 Lul 2007, at 00:38, Yury Tarasievich wrote: > Two questions to the maintainers of the data: > > 1. Is there no academic review or some sanity check of what you > release? It is reviewed by vetters. We try to sanity check it, and as well, automated tests sanity check that text is in the right script at least. > 2. Is there a procedure to request complete excluding the locale from > the release? At the very least, to freeze the Belarusian data at 1.4 > revision? > > The Belarusian locale data had some glaring errors before (cf. my > emails to this list), but now it is a *raving mess*, supposedly after > the "google tool" working on it. If that's the way CLDR treats > culture-related data, I'm not even going to bother with correcting > that. The google tool (by which I assume you mean, the Google default vote) *cannot* overturn an approved 1.4 item by itself. > 1. In language names, there's now quite a quantity of entries written > down in a distorted (in-group and non-normative) variant of Belarusian > cultivated on Internet. > > 2. Some entries are plainly somebody's uneducated invention (e.g., > entry for afrikaans), unexplainable even by distortion. > > 3. To top that, the majority of google entries in languages are > grammatically corrupt (wrong declension). It sounds like we will want to discuss this as well. -s --Apple-Mail-47--1016520675 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On 03 Lul 2007, at 00:38, Yury Tarasievich = wrote:
Two questions to the maintainers of the = data:

1. Is there no academic review or some sanity check = of what you release?

=A0It is = reviewed by vetters. We try to sanity check it, and as well, automated = tests sanity check that text is in the right script at = least.

2. Is there a procedure to request complete = excluding the locale from
the release? = At the very least, to freeze the Belarusian data at 1.4
revision?

The Belarusian locale data had = some glaring errors before (cf. my
emails to = this list), but now it is a *raving mess*, supposedly after
the "google tool" working on it. If that's the way = CLDR treats
culture-related data, I'm not = even going to bother with correcting
=A0The google tool (by = which I assume you mean, the Google default vote) *cannot* overturn an = approved 1.4 item by itself.

1. In language names, = there's now quite a quantity of entries written
down in a distorted (in-group and non-normative) = variant of Belarusian
cultivated on = Internet.

2. Some entries are plainly somebody's uneducated = invention (e.g.,
entry for afrikaans), = unexplainable even by distortion.

3. To top that, the majority of = google entries in languages are
grammatically = corrupt (wrong declension).

It sounds like we will want to = discuss this as well.

-s

= --Apple-Mail-47--1016520675-- From yury.tarasievich@gmail.com Tue Jul 3 03:06:47 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 03:06:47 -0500 (CDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by unicode.org (8.13.4/8.12.11) with ESMTP id l6386kkd007641 for ; Tue, 3 Jul 2007 03:06:46 -0500 Received: by wr-out-0506.google.com with SMTP id i4so1321031wra for ; Tue, 03 Jul 2007 01:06:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YrRPeQj/nLgT4F4hCbkxv1mCXsA/bKICtDxKj60ZEaqEMCvnMaVdgMo94HnEMPSqikCxhtaP4JGK9sczS2rILOdudNlP7p0c4ZUfcadupCLvHNBHn/ykTuOMroPupIpSP81psa7pW6drrxJdGew5JdhYeOyVNfp65GNzkmG2D2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JnWupl7AZmvJiyKroxIJLNmKra/OxJl/HeHTTYuAEGVpMOjlWKk5+FOEJRQjUh1vzm7ppddBzkuxM6Q7UF3gOVvWVLwBxJPcpA/1Q4SQ+ekjv9gCFwKpAndm8Nk/aOowIB82TO8epm12eDvUe/Uyhoa8L5ZlVcNggu9WUO9A25E= Received: by 10.114.196.1 with SMTP id t1mr5929845waf.1183450005382; Tue, 03 Jul 2007 01:06:45 -0700 (PDT) Received: by 10.114.184.20 with HTTP; Tue, 3 Jul 2007 01:06:45 -0700 (PDT) Message-ID: <9f3c41b10707030106y678d0b0egf3024a2cabe3252a@mail.gmail.com> Date: Tue, 3 Jul 2007 11:06:45 +0300 From: "Yury Tarasievich" To: cldr-users@unicode.org Subject: Re: Google data In-Reply-To: <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> X-archive-position: 172 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: yury.tarasievich@gmail.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users On 03/07/07, Steven R. Loomis wrote: ... > The google tool (by which I assume you mean, the Google default vote) > *cannot* overturn an approved 1.4 item by itself. Yes, I mean the "default vote". It gets weight 4, also. So, how are such situations resolved? ... > It sounds like we will want to discuss this as well. And what happens now? Thanks. --- From srl@icu-project.org Tue Jul 3 03:19:58 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 03:19:58 -0500 (CDT) 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 l638JsZp016442 for ; Tue, 3 Jul 2007 03:19:58 -0500 Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.102]) by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1I5dby-000HzV-1g for cldr-users@unicode.org; Tue, 03 Jul 2007 08:19:50 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <9f3c41b10707030106y678d0b0egf3024a2cabe3252a@mail.gmail.com> References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <9f3c41b10707030106y678d0b0egf3024a2cabe3252a@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <29E5739B-04D1-4CC3-8958-C424AC94DCD3@icu-project.org> Content-Transfer-Encoding: 7bit From: "Steven R. Loomis" Subject: Re: Google data Date: Tue, 3 Jul 2007 01:19:23 -0700 To: cldr-users@unicode.org X-Mailer: Apple Mail (2.752.3) X-archive-position: 173 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 03 Lul 2007, at 01:06, Yury Tarasievich wrote: > On 03/07/07, Steven R. Loomis wrote: > ... >> The google tool (by which I assume you mean, the Google default >> vote) >> *cannot* overturn an approved 1.4 item by itself. > > Yes, I mean the "default vote". It gets weight 4, also. > > So, how are such situations resolved? > ... The email is a good start. >> It sounds like we will want to discuss this as well. > > And what happens now? I wasn't specific enough. By "we", I meant the CLDR committee which meets in some hours. -s From kent.karlsson14@comhem.se Tue Jul 3 03:24:49 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 03:24:49 -0500 (CDT) 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 l638OlD9018801 for ; Tue, 3 Jul 2007 03:24:47 -0500 Received: from c83-248-107-61.bredband.comhem.se ([83.248.107.61]:4049 helo=WGBGKKA02) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.66) (envelope-from ) id 1I5dgk-00043L-3U for cldr-users@unicode.org; Tue, 03 Jul 2007 10:24:46 +0200 From: "Kent Karlsson" To: References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> Subject: RE: Google data Date: Tue, 3 Jul 2007 10:24:41 +0200 Message-ID: <01b101c7bd4b$9d9c6de0$ea62f853@streamserve.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B2_01C7BD5C.61253DE0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace9R2iv6qVinnBHQnOgs9MtJt8PiQAAySBA X-Originating-IP: 83.248.107.61 X-Scan-Result: No virus found in message 1I5dgk-00043L-3U. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1I5dgk-00043L-3U e8d2279fb1ec0b592bee8d9fd210bfc8 X-archive-position: 174 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 This is a multi-part message in MIME format. ------=_NextPart_000_01B2_01C7BD5C.61253DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I don't like the Google default vote data myself. I don't mind the submission of data, but these (usually) get a vote weight of 4, preventing "winning item" change, even when everyone (including Google default vote) agrees on the actual strings, and creates problems when (almost) all but the Google default vote agree. B.t.w. I think Yuri meant "qualified vetting" by "sanity check", while Steven meant "simple automated error check" by "sanity check"... /kent k _____ From: cldr-users-bounce@unicode.org [mailto:cldr-users-bounce@unicode.org] On Behalf Of Steven R. Loomis Sent: Tuesday, July 03, 2007 9:52 AM To: cldr-users@unicode.org Subject: Re: Google data On 03 Lul 2007, at 00:38, Yury Tarasievich wrote: Two questions to the maintainers of the data: 1. Is there no academic review or some sanity check of what you release? It is reviewed by vetters. We try to sanity check it, and as well, automated tests sanity check that text is in the right script at least. 2. Is there a procedure to request complete excluding the locale from the release? At the very least, to freeze the Belarusian data at 1.4 revision? The Belarusian locale data had some glaring errors before (cf. my emails to this list), but now it is a *raving mess*, supposedly after the "google tool" working on it. If that's the way CLDR treats culture-related data, I'm not even going to bother with correcting that. The google tool (by which I assume you mean, the Google default vote) *cannot* overturn an approved 1.4 item by itself. 1. In language names, there's now quite a quantity of entries written down in a distorted (in-group and non-normative) variant of Belarusian cultivated on Internet. 2. Some entries are plainly somebody's uneducated invention (e.g., entry for afrikaans), unexplainable even by distortion. 3. To top that, the majority of google entries in languages are grammatically corrupt (wrong declension). It sounds like we will want to discuss this as well. -s ------=_NextPart_000_01B2_01C7BD5C.61253DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't like the Google default vote data myself. I don't mind = the=20 submission of data,
but these (usually) get a vote weight of 4, preventing "winning = item"=20 change, even when
everyone (including Google default vote) agrees on the actual = strings,=20 and creates
problems when (almost) all but the=20 Google default vote agree.
 
B.t.w. I think Yuri meant "qualified vetting" by "sanity = check", while=20 Steven meant
"simple automated error check" by "sanity = check"...
 
       =20 /kent = k
 

From: = cldr-users-bounce@unicode.org=20 [mailto:cldr-users-bounce@unicode.org] On Behalf Of Steven R.=20 Loomis
Sent: Tuesday, July 03, 2007 9:52 AM
To:=20 cldr-users@unicode.org
Subject: Re: Google = data

On 03 Lul 2007, at 00:38, Yury = Tarasievich=20 wrote:
Two questions to the maintainers of the = data:

1. Is there no academic review or some = sanity check=20 of what you release?

 It is reviewed by vetters. We try to sanity check it, and = as well,=20 automated tests sanity check that text is in the right script at=20 least.

2. Is there a procedure to request = complete=20 excluding the locale from
the release? At the very least, to freeze = the=20 Belarusian data at 1.4
revision?

The Belarusian locale data had some = glaring errors=20 before (cf. my
emails to this list), but now it is a = *raving=20 mess*, supposedly after
the "google tool" working on it. If = that's the way=20 CLDR treats
culture-related data, I'm not even going = to bother=20 with correcting
that.

 The google tool (by which I assume you mean, the Google = default=20 vote) *cannot* overturn an approved 1.4 item by itself.

1. In language names, there's now quite a = quantity=20 of entries written
down in a distorted (in-group and = non-normative)=20 variant of Belarusian
cultivated on Internet.

2. Some entries are plainly somebody's = uneducated=20 invention (e.g.,
entry for afrikaans), unexplainable even = by=20 distortion.

3. To top that, the majority of google = entries in=20 languages are
grammatically corrupt (wrong=20 declension).

It sounds like we will = want to=20 discuss this as well.

-s

------=_NextPart_000_01B2_01C7BD5C.61253DE0-- From yury.tarasievich@gmail.com Tue Jul 3 03:33:00 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 03:33:00 -0500 (CDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by unicode.org (8.13.4/8.12.11) with ESMTP id l638WxQ4023082 for ; Tue, 3 Jul 2007 03:33:00 -0500 Received: by wa-out-1112.google.com with SMTP id j40so2820781wah for ; Tue, 03 Jul 2007 01:32:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AEAF62z8kcWPYuWtXdn/d5lV4AyyVjcamUYtvsPTVoiRpVhe2lOFsMPoQHBYB9WjjJDYP8fA7w0u1BTQhnC5whRBpfquIL8UHF6ZGrcLvbDcYH1A0qH2xxxrZpESJnRDKagIuJyIeAU58n2c9tZLFzfFrZ6Foml/jwsYI0OGNrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=icdPvLh9YfqqocCs+BwE8herxiHn7XuZ88sji7aFMpaWIJ53UUCeUQ+YUUIOYv64ZxQaZwOpoTYaMk+cSxe5R3DCPKVE95js4u53dwzzEbOVrSWRsIHRIN/beBwrQA2x5l/IcdTyW9kbijxnHmin8EjylUtx5+72xOAg19lNDTU= Received: by 10.115.109.1 with SMTP id l1mr5904784wam.1183451576085; Tue, 03 Jul 2007 01:32:56 -0700 (PDT) Received: by 10.114.184.20 with HTTP; Tue, 3 Jul 2007 01:32:56 -0700 (PDT) Message-ID: <9f3c41b10707030132k4fc3cf87i48d323df4c15a405@mail.gmail.com> Date: Tue, 3 Jul 2007 11:32:56 +0300 From: "Yury Tarasievich" To: cldr-users@unicode.org Subject: Re: Google data In-Reply-To: <29E5739B-04D1-4CC3-8958-C424AC94DCD3@icu-project.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <9f3c41b10707030106y678d0b0egf3024a2cabe3252a@mail.gmail.com> <29E5739B-04D1-4CC3-8958-C424AC94DCD3@icu-project.org> X-archive-position: 175 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: yury.tarasievich@gmail.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users On 03/07/07, Steven R. Loomis wrote: > On 03 Lul 2007, at 01:06, Yury Tarasievich wrote: > > On 03/07/07, Steven R. Loomis wrote: > > ... > >> The google tool (by which I assume you mean, the Google default > >> vote) > >> *cannot* overturn an approved 1.4 item by itself. ... > > So, how are such situations resolved? > > ... > > The email is a good start. Could you please be more specific -- ought this to be private email or maillist discussion? Also, Bugzilla here doesn't work, I'm given to understand. What's the procedure, then? --- From yury.tarasievich@gmail.com Tue Jul 3 03:37:09 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 03:37:09 -0500 (CDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by unicode.org (8.13.4/8.12.11) with ESMTP id l638b9un024937 for ; Tue, 3 Jul 2007 03:37:09 -0500 Received: by wa-out-1112.google.com with SMTP id j40so2821953wah for ; Tue, 03 Jul 2007 01:37:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UwRVPrHlg4OdXW1Dz77Qn/mHFFx2dIKEY6zlmr6BXr3zSxrtie3vJse1GLF/TgkXp57ms3S/Dzr2XK8+Aj7V2RpqTF69XL0HxUPkFg7Im9dPTILeE4DvPO8kLWpOIFhpxXNJ5yvIo+HIM2DVY8hh6IwCkciq7xkU8VZKrcTVUTI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C2hvhp4XSJ9n6h1VVm2aGt1yi9aPND0kNJEoWXEGs0JAgNh/A8tIfWdErwmfOqKGXhh8X0RoDuYa9yz//2QalEONa+geFfuI/I0VVu5V+bIMstdezpnZhNwp3k9O3eXx/w4KqwaFjYvULiusv5c4ZIJMflIOHKU6zDLWfp4+8P8= Received: by 10.114.135.1 with SMTP id i1mr5940210wad.1183451828695; Tue, 03 Jul 2007 01:37:08 -0700 (PDT) Received: by 10.114.184.20 with HTTP; Tue, 3 Jul 2007 01:37:08 -0700 (PDT) Message-ID: <9f3c41b10707030137o526e5503hd2cc959e7518fc41@mail.gmail.com> Date: Tue, 3 Jul 2007 11:37:08 +0300 From: "Yury Tarasievich" To: cldr-users@unicode.org Subject: Re: Google data In-Reply-To: <01b101c7bd4b$9d9c6de0$ea62f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <01b101c7bd4b$9d9c6de0$ea62f853@streamserve.com> X-archive-position: 176 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: yury.tarasievich@gmail.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users On 03/07/07, Kent Karlsson wrote: ... > B.t.w. I think Yuri meant "qualified vetting" by "sanity check", while > Steven meant > "simple automated error check" by "sanity check"... Yes, right, qualified... The today's glance at what the data became left me quite speechless. Mockage of culture, no less. --- From asmodai@in-nomine.org Tue Jul 3 03:53:48 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 03:53:48 -0500 (CDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by unicode.org (8.13.4/8.12.11) with ESMTP id l638rhi3000730 for ; Tue, 3 Jul 2007 03:53:47 -0500 Received: from nexus.in-nomine.org (chronias.xs4all.nl [82.92.216.8]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id l638rYOG073977 for ; Tue, 3 Jul 2007 10:53:43 +0200 (CEST) (envelope-from asmodai@in-nomine.org) Received: from localhost (localhost.domini.in-nomine.org [127.0.0.1]) by nexus.in-nomine.org (Postfix) with ESMTP id 29716C59C for ; Tue, 3 Jul 2007 10:52:20 +0200 (CEST) X-Virus-Scanned: by XS4ALL Virus Scanner Received: from nexus.in-nomine.org ([127.0.0.1]) by localhost (nexus.domini.in-nomine.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0lR5i3tPRMm for ; Tue, 3 Jul 2007 10:52:17 +0200 (CEST) Received: by nexus.in-nomine.org (Postfix, from userid 1000) id 980F0C59A; Tue, 3 Jul 2007 10:52:17 +0200 (CEST) Date: Tue, 3 Jul 2007 10:52:17 +0200 From: Jeroen Ruigrok van der Werven To: cldr-users@unicode.org Subject: Re: Google data Message-ID: <20070703085217.GO30825@nexus.in-nomine.org> References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <01b101c7bd4b$9d9c6de0$ea62f853@streamserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01b101c7bd4b$9d9c6de0$ea62f853@streamserve.com> Organisation: Ninth Circle Enterprises User-Agent: Mutt/1.5.15 (2007-04-06) X-archive-position: 177 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: asmodai@in-nomine.org Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users -On [20070703 10:32], Kent Karlsson (kent.karlsson14@comhem.se) wrote: >I don't like the Google default vote data myself. I don't mind the submission >of data, but these (usually) get a vote weight of 4, preventing "winning >item" change, even when everyone (including Google default vote) agrees on >the actual strings, and creates problems when (almost) all but the Google >default vote agree. Please excuse my lack of understanding in this case and feel free to enlighten me or point me in the right direction. Does this mean 'we' have an automated tool that gathers locale specific data in order to build the CLDR's data? This tool's auto submission gets a pretty heavy vote, assuming normal voters get 1 vote? One lesson I always learnt about translation and localization is to never blindly trust machine and computer translations or data. Often you walk into cultural issues or, worse, you outright insult them. If I would judge on my own country and the people that publish websites I would be very afraid for any resulting locale data. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Sleep tonight, sweet summer light, scattered yesterdays, the past is far away... From mark.edward.davis@gmail.com Tue Jul 3 04:30:06 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 04:30:06 -0500 (CDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by unicode.org (8.13.4/8.12.11) with ESMTP id l639U646029563 for ; Tue, 3 Jul 2007 04:30:06 -0500 Received: by wa-out-1112.google.com with SMTP id j40so2836235wah for ; Tue, 03 Jul 2007 02:30:06 -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=LbXyd3mgABUu9xu6qDU57vE1ovjsJBHFUEGsWSwicw6WPILxilw2ywS90m8THbAJJDMJ+Qp57Rhqnf2A+11SubGmxuPXWx1DFid5cLVND8PQ0FKGVXwkHMLIKdRl89jr2IgnbDrkuetZPK0kAB261fZ3/uywEQrzHZWIYXiwVCw= 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=B1//BfbIrmrY0+DVTxmMpVwfYpAgXGJ5BssPnIVulV1x27hzlEtsMbC/w0oOUDd3UUgEvc7P7kfFKHw6RwWUpX0H6ANGY8blZhikwk7epth2YBgtnYqENQxtilNA0p7v+bojg0SuHX4oS0tUXWX14aMtW+5XZ1eYMKXa+6qmJd4= Received: by 10.114.170.1 with SMTP id s1mr5999548wae.1183455004807; Tue, 03 Jul 2007 02:30:04 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 3 Jul 2007 02:30:04 -0700 (PDT) Message-ID: <30b660a20707030230i4132ad96od242b4498b2ebe2d@mail.gmail.com> Date: Tue, 3 Jul 2007 02:30:04 -0700 From: "Mark Davis" To: cldr-users@unicode.org Subject: Re: Google data In-Reply-To: <20070703085217.GO30825@nexus.in-nomine.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_147292_2104308.1183455004764" References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <01b101c7bd4b$9d9c6de0$ea62f853@streamserve.com> <20070703085217.GO30825@nexus.in-nomine.org> X-Google-Sender-Auth: af890d5ad940acdc X-archive-position: 178 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_147292_2104308.1183455004764 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline TGV0IG1lIHJlcGVhdDogdGhlc2UgYXJlIG5vdCBtYWNoaW5lIHRyYW5zbGF0aW9ucywgbm9yIGNv bXB1dGVyCnRyYW5zbGF0aW9ucy4gVGhleSBhcmUgdGFrZW4gZnJvbSBkYXRhIHRyYW5zbGF0ZWQg YnkgaHVtYW5zLgoKT2YgY291cnNlLCB0aGF0IGRhdGEgbWF5IGJlIGluY29ycmVjdCwgYnV0IGl0 IHdhcyBub3QgbWFjaGluZSBnZW5lcmF0ZWQuCkknbGwgcmVwZWF0OgoKSSBmaWxlZCBhIGJ1ZyBv biB0aGlzIGF0Cmh0dHA6Ly93d3cudW5pY29kZS5vcmcvY2xkci9idWdzL2xvY2FsZS1idWdzP2Zp bmRpZD0xNDExIGZvciBkaXNjdXNzaW9uIGF0CnRoZSBtZWV0aW5nIHRvbW9ycm93IG1vcm5pbmcu IElmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnRzLCBwbGVhc2UgYWRkCnRoZW0gdG8gdGhh dCBidWcgcmVwb3J0IGFzIGEgUmVwbHkuCgpTbyBwbGVhc2UgbG9vayBhdApodHRwOi8vd3d3LnVu aWNvZGUub3JnL2NsZHIvYnVncy9sb2NhbGUtYnVncz9maW5kaWQ9MTQxMXRvIHNlZSBpZiB5b3UK d2FudCB0byBhZGQgYW55dGhpbmcgdGhhdCB0aGUgY29tbWl0dGVlIHNob3VsZCBjb25zaWRlci4K Ck1hcmsKCk9uIDcvMy8wNywgSmVyb2VuIFJ1aWdyb2sgdmFuIGRlciBXZXJ2ZW4gPGFzbW9kYWlA aW4tbm9taW5lLm9yZz4gd3JvdGU6Cj4KPiAtT24gWzIwMDcwNzAzIDEwOjMyXSwgS2VudCBLYXJs c3NvbiAoa2VudC5rYXJsc3NvbjE0QGNvbWhlbS5zZSkgd3JvdGU6Cj4gPkkgZG9uJ3QgbGlrZSB0 aGUgR29vZ2xlIGRlZmF1bHQgdm90ZSBkYXRhIG15c2VsZi4gSSBkb24ndCBtaW5kIHRoZQo+IHN1 Ym1pc3Npb24KPiA+b2YgZGF0YSwgYnV0IHRoZXNlICh1c3VhbGx5KSBnZXQgYSB2b3RlIHdlaWdo dCBvZiA0LCBwcmV2ZW50aW5nICJ3aW5uaW5nCj4gPml0ZW0iIGNoYW5nZSwgZXZlbiB3aGVuIGV2 ZXJ5b25lIChpbmNsdWRpbmcgR29vZ2xlIGRlZmF1bHQgdm90ZSkgYWdyZWVzCj4gb24KPiA+dGhl IGFjdHVhbCBzdHJpbmdzLCBhbmQgY3JlYXRlcyBwcm9ibGVtcyB3aGVuIChhbG1vc3QpIGFsbCBi dXQgdGhlIEdvb2dsZQo+ID5kZWZhdWx0IHZvdGUgYWdyZWUuCj4KPiBQbGVhc2UgZXhjdXNlIG15 IGxhY2sgb2YgdW5kZXJzdGFuZGluZyBpbiB0aGlzIGNhc2UgYW5kIGZlZWwgZnJlZSB0bwo+IGVu bGlnaHRlbgo+IG1lIG9yIHBvaW50IG1lIGluIHRoZSByaWdodCBkaXJlY3Rpb24uCj4KPiBEb2Vz IHRoaXMgbWVhbiAnd2UnIGhhdmUgYW4gYXV0b21hdGVkIHRvb2wgdGhhdCBnYXRoZXJzIGxvY2Fs ZSBzcGVjaWZpYwo+IGRhdGEKPiBpbiBvcmRlciB0byBidWlsZCB0aGUgQ0xEUidzIGRhdGE/Cj4K PiBUaGlzIHRvb2wncyBhdXRvIHN1Ym1pc3Npb24gZ2V0cyBhIHByZXR0eSBoZWF2eSB2b3RlLCBh c3N1bWluZyBub3JtYWwKPiB2b3RlcnMKPiBnZXQgMSB2b3RlPwo+Cj4gT25lIGxlc3NvbiBJIGFs d2F5cyBsZWFybnQgYWJvdXQgdHJhbnNsYXRpb24gYW5kIGxvY2FsaXphdGlvbiBpcyB0byBuZXZl cgo+IGJsaW5kbHkgdHJ1c3QgbWFjaGluZSBhbmQgY29tcHV0ZXIgdHJhbnNsYXRpb25zIG9yIGRh dGEuIE9mdGVuIHlvdSB3YWxrCj4gaW50bwo+IGN1bHR1cmFsIGlzc3VlcyBvciwgd29yc2UsIHlv dSBvdXRyaWdodCBpbnN1bHQgdGhlbS4KPgo+IElmIEkgd291bGQganVkZ2Ugb24gbXkgb3duIGNv dW50cnkgYW5kIHRoZSBwZW9wbGUgdGhhdCBwdWJsaXNoIHdlYnNpdGVzIEkKPiB3b3VsZCBiZSB2 ZXJ5IGFmcmFpZCBmb3IgYW55IHJlc3VsdGluZyBsb2NhbGUgZGF0YS4KPgo+IC0tCj4gSmVyb2Vu IFJ1aWdyb2sgdmFuIGRlciBXZXJ2ZW4gPGFzbW9kYWkoLWF0LSlpbi1ub21pbmUub3JnPiAvIGFz bW9kYWkKPiDjgqTjgqfjg6vjg7zjg7Mg44Op44Km44OV44Ot44OD44KvIOODtOOCoeODsyDjg4fj g6sg44Km44Kn44Or44O044Kn44OzCj4gaHR0cDovL3d3dy5pbi1ub21pbmUub3JnLyB8IGh0dHA6 Ly93d3cucmFuZ2FrdS5vcmcvCj4gU2xlZXAgdG9uaWdodCwgc3dlZXQgc3VtbWVyIGxpZ2h0LCBz Y2F0dGVyZWQgeWVzdGVyZGF5cywgdGhlIHBhc3QgaXMgZmFyCj4gYXdheS4uLgo+Cj4KCgotLSAK TWFyawo= ------=_Part_147292_2104308.1183455004764 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline TGV0IG1lIHJlcGVhdDogdGhlc2UgYXJlIG5vdCBtYWNoaW5lIHRyYW5zbGF0aW9ucywgbm9yIGNv bXB1dGVyIHRyYW5zbGF0aW9ucy4gVGhleSBhcmUgdGFrZW4gZnJvbSBkYXRhIHRyYW5zbGF0ZWQg YnkgaHVtYW5zLjxicj48YnI+T2YgY291cnNlLCB0aGF0IGRhdGEgbWF5IGJlIGluY29ycmVjdCwg YnV0IGl0IHdhcyBub3QgbWFjaGluZSBnZW5lcmF0ZWQuIEkmIzM5O2xsIHJlcGVhdDo8YnI+Cjxi cj48ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDogNDBweDsiPkkgZmlsZWQgYSBidWcgb24gdGhpcyBh dCA8YSBocmVmPSJodHRwOi8vd3d3LnVuaWNvZGUub3JnL2NsZHIvYnVncy9sb2NhbGUtYnVncz9m aW5kaWQ9MTQxMSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4 dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vd3d3LnVuaWNvZGUub3JnL2NsZHIvYnVn cy9sb2NhbGUtYnVncz9maW5kaWQ9MTQxMQo8L2E+CmZvciBkaXNjdXNzaW9uIGF0IHRoZSBtZWV0 aW5nIHRvbW9ycm93IG1vcm5pbmcuIElmIHlvdSBoYXZlIGFueSBmdXJ0aGVyCmNvbW1lbnRzLCBw bGVhc2UgYWRkIHRoZW0gdG8gdGhhdCBidWcgcmVwb3J0IGFzIGEgUmVwbHkuCjxicj48L2Rpdj48 YnI+U28gcGxlYXNlIGxvb2sgYXQgPGEgaHJlZj0iaHR0cDovL3d3dy51bmljb2RlLm9yZy9jbGRy L2J1Z3MvbG9jYWxlLWJ1Z3M/ZmluZGlkPTE0MTEiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJy ZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0cDovL3d3dy51 bmljb2RlLm9yZy9jbGRyL2J1Z3MvbG9jYWxlLWJ1Z3M/ZmluZGlkPTE0MTEKPC9hPiB0byBzZWUg aWYgeW91IHdhbnQgdG8gYWRkIGFueXRoaW5nIHRoYXQgdGhlIGNvbW1pdHRlZSBzaG91bGQgY29u c2lkZXIuPGJyPjxicj5NYXJrPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gNy8zLzA3LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+SmVyb2VuIFJ1aWdyb2sgdmFu IGRlciBXZXJ2ZW48L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86YXNtb2RhaUBpbi1ub21pbmUub3Jn Ij4KYXNtb2RhaUBpbi1ub21pbmUub3JnPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIw NCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFl eDsiPi1PbiBbMjAwNzA3MDMgMTA6MzJdLCBLZW50IEthcmxzc29uICg8YSBocmVmPSJtYWlsdG86 a2VudC5rYXJsc3NvbjE0QGNvbWhlbS5zZSI+CmtlbnQua2FybHNzb24xNEBjb21oZW0uc2U8L2E+ KSB3cm90ZTo8YnI+Jmd0O0kgZG9uJiMzOTt0IGxpa2UgdGhlIEdvb2dsZSBkZWZhdWx0IHZvdGUg ZGF0YSBteXNlbGYuIEkgZG9uJiMzOTt0IG1pbmQgdGhlIHN1Ym1pc3Npb248YnI+Jmd0O29mIGRh dGEsIGJ1dCB0aGVzZSAodXN1YWxseSkgZ2V0IGEgdm90ZSB3ZWlnaHQgb2YgNCwgcHJldmVudGlu ZyAmcXVvdDt3aW5uaW5nPGJyPiZndDtpdGVtJnF1b3Q7IGNoYW5nZSwgZXZlbiB3aGVuIGV2ZXJ5 b25lIChpbmNsdWRpbmcgR29vZ2xlIGRlZmF1bHQgdm90ZSkgYWdyZWVzIG9uCjxicj4mZ3Q7dGhl IGFjdHVhbCBzdHJpbmdzLCBhbmQgY3JlYXRlcyBwcm9ibGVtcyB3aGVuIChhbG1vc3QpIGFsbCBi dXQgdGhlIEdvb2dsZTxicj4mZ3Q7ZGVmYXVsdCB2b3RlIGFncmVlLjxicj48YnI+UGxlYXNlIGV4 Y3VzZSBteSBsYWNrIG9mIHVuZGVyc3RhbmRpbmcgaW4gdGhpcyBjYXNlIGFuZCBmZWVsIGZyZWUg dG8gZW5saWdodGVuPGJyPm1lIG9yIHBvaW50IG1lIGluIHRoZSByaWdodCBkaXJlY3Rpb24uCjxi cj48YnI+RG9lcyB0aGlzIG1lYW4gJiMzOTt3ZSYjMzk7IGhhdmUgYW4gYXV0b21hdGVkIHRvb2wg dGhhdCBnYXRoZXJzIGxvY2FsZSBzcGVjaWZpYyBkYXRhPGJyPmluIG9yZGVyIHRvIGJ1aWxkIHRo ZSBDTERSJiMzOTtzIGRhdGE/PGJyPjxicj5UaGlzIHRvb2wmIzM5O3MgYXV0byBzdWJtaXNzaW9u IGdldHMgYSBwcmV0dHkgaGVhdnkgdm90ZSwgYXNzdW1pbmcgbm9ybWFsIHZvdGVycwo8YnI+Z2V0 IDEgdm90ZT88YnI+PGJyPk9uZSBsZXNzb24gSSBhbHdheXMgbGVhcm50IGFib3V0IHRyYW5zbGF0 aW9uIGFuZCBsb2NhbGl6YXRpb24gaXMgdG8gbmV2ZXI8YnI+YmxpbmRseSB0cnVzdCBtYWNoaW5l IGFuZCBjb21wdXRlciB0cmFuc2xhdGlvbnMgb3IgZGF0YS4gT2Z0ZW4geW91IHdhbGsgaW50bzxi cj5jdWx0dXJhbCBpc3N1ZXMgb3IsIHdvcnNlLCB5b3Ugb3V0cmlnaHQgaW5zdWx0IHRoZW0uCjxi cj48YnI+SWYgSSB3b3VsZCBqdWRnZSBvbiBteSBvd24gY291bnRyeSBhbmQgdGhlIHBlb3BsZSB0 aGF0IHB1Ymxpc2ggd2Vic2l0ZXMgSTxicj53b3VsZCBiZSB2ZXJ5IGFmcmFpZCBmb3IgYW55IHJl c3VsdGluZyBsb2NhbGUgZGF0YS48YnI+PGJyPi0tPGJyPkplcm9lbiBSdWlncm9rIHZhbiBkZXIg V2VydmVuICZsdDthc21vZGFpKC1hdC0paW4tPGEgaHJlZj0iaHR0cDovL25vbWluZS5vcmciPgpu b21pbmUub3JnPC9hPiZndDsgLyBhc21vZGFpPGJyPuOCpOOCp+ODq+ODvOODsyDjg6njgqbjg5Xj g63jg4Pjgq8g44O044Kh44OzIOODh+ODqyDjgqbjgqfjg6vjg7Tjgqfjg7M8YnI+PGEgaHJlZj0i aHR0cDovL3d3dy5pbi1ub21pbmUub3JnLyI+aHR0cDovL3d3dy5pbi1ub21pbmUub3JnLzwvYT4g fCA8YSBocmVmPSJodHRwOi8vd3d3LnJhbmdha3Uub3JnLyI+aHR0cDovL3d3dy5yYW5nYWt1Lm9y Zy88L2E+PGJyPlNsZWVwIHRvbmlnaHQsIHN3ZWV0IHN1bW1lciBsaWdodCwgc2NhdHRlcmVkIHll c3RlcmRheXMsIHRoZSBwYXN0IGlzIGZhcgo8YnI+IGF3YXkuLi48YnI+PGJyPjwvYmxvY2txdW90 ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+TWFyawo= ------=_Part_147292_2104308.1183455004764-- From mark.edward.davis@gmail.com Tue Jul 3 05:11:59 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 05:11:59 -0500 (CDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by unicode.org (8.13.4/8.12.11) with ESMTP id l63ABwHH026312 for ; Tue, 3 Jul 2007 05:11:58 -0500 Received: by wa-out-1112.google.com with SMTP id j40so2847153wah for ; Tue, 03 Jul 2007 03:11:58 -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=COv5uMnu5D+ewyBSGQZ36o9UzAIdH4gNKeLT/Sr60ARCOxYb1GhbS38YWh/ggdRYDij08OutsnRV/BW7UIp5DwROQSVOnJCnGu7A26l0V4CheQQGxLDATiI9U28IzOYe1VdSKvVPT430NVvaWaJD3RPD8ihb3QMU3yuqZDzcM8c= 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=bhawVTJ8kO6Fmu58/cyLUY4WMHNBsPUdLL2eMCdkz7HXwCThCbYF/16WTR2eypi/i2l6V9x8Lj4t+wpBC6sBgqkQUsybF22zV97tFBOm+wlUqFt1zn7iIQg2VMSTIhsHDz2CD/zSkY/CMeoHgBR6MFIT2vzlXiR7DuvDxW9Qhyk= Received: by 10.115.32.1 with SMTP id k1mr6008241waj.1183457517935; Tue, 03 Jul 2007 03:11:57 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 3 Jul 2007 03:11:57 -0700 (PDT) Message-ID: <30b660a20707030311y5f28e85er46f7f4837b46cbcb@mail.gmail.com> Date: Tue, 3 Jul 2007 03:11:57 -0700 From: "Mark Davis" To: cldr-users@unicode.org Subject: Re: Google data In-Reply-To: <30b660a20707030230i4132ad96od242b4498b2ebe2d@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_147884_11965233.1183457517882" References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <01b101c7bd4b$9d9c6de0$ea62f853@streamserve.com> <20070703085217.GO30825@nexus.in-nomine.org> <30b660a20707030230i4132ad96od242b4498b2ebe2d@mail.gmail.com> X-Google-Sender-Auth: 1a455e3c7555e648 X-archive-position: 179 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_147884_11965233.1183457517882 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I should emphasize that we appreciate the work that everyone is doing -- and know that it can be very frustrating when things don't work as expected. It is actually quite a complicated process behind the scenes, so there will be glitches -- please raise any issues that you see either on this forum or with bug reports, and we'll see what we can do to take care of them, or at least try to tell you how to work around them. Mark ------=_Part_147884_11965233.1183457517882 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I should emphasize that we appreciate the work that everyone is doing -- and know that it can be very frustrating when things don't work as expected. It is actually quite a complicated process behind the scenes, so there will be glitches -- please raise any issues that you see either on this forum or with bug reports, and we'll see what we can do to take care of them, or at least try to tell you how to work around them.

Mark ------=_Part_147884_11965233.1183457517882-- From srl@icu-project.org Tue Jul 3 09:30:39 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 09:30:39 -0500 (CDT) 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 l63EUZdD000947 for ; Tue, 3 Jul 2007 09:30:39 -0500 Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.102]) by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1I5jOf-0006uI-HR for cldr-users@unicode.org; Tue, 03 Jul 2007 14:30:29 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <9f3c41b10707030132k4fc3cf87i48d323df4c15a405@mail.gmail.com> References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <9f3c41b10707030106y678d0b0egf3024a2cabe3252a@mail.gmail.com> <29E5739B-04D1-4CC3-8958-C424AC94DCD3@icu-project.org> <9f3c41b10707030132k4fc3cf87i48d323df4c15a405@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A2D4A86-761E-4022-91DE-5AE1D980FAAC@icu-project.org> Content-Transfer-Encoding: 7bit From: "Steven R. Loomis" Subject: Re: Google data Date: Tue, 3 Jul 2007 07:30:01 -0700 To: cldr-users@unicode.org X-Mailer: Apple Mail (2.752.3) X-archive-position: 180 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 03 Lul 2007, at 01:32, Yury Tarasievich wrote: > On 03/07/07, Steven R. Loomis wrote: >> On 03 Lul 2007, at 01:06, Yury Tarasievich wrote: >> > On 03/07/07, Steven R. Loomis wrote: >> > ... >> >> The google tool (by which I assume you mean, the Google default >> >> vote) >> >> *cannot* overturn an approved 1.4 item by itself. > ... >> > So, how are such situations resolved? >> > ... >> >> The email is a good start. > > Could you please be more specific -- ought this to be private email or > maillist discussion? I mean, you did the right thing by sending the email. Sorry again for the misunderstanding. > Also, Bugzilla here doesn't work, I'm given to understand. What's the > procedure, then? The bug tracking system does indeed work, we use it, and review it, every week. -s From srl@icu-project.org Tue Jul 3 09:39:05 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 09:39:05 -0500 (CDT) 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 l63Ed2if003761 for ; Tue, 3 Jul 2007 09:39:05 -0500 Received: from monkey.sbay.org ([216.27.178.44] helo=[10.0.0.102]) by v.icu-project.org with esmtpa (Exim 4.63 (FreeBSD)) (envelope-from ) id 1I5jWs-0007Y4-Tp for cldr-users@unicode.org; Tue, 03 Jul 2007 14:38:59 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <5A2D4A86-761E-4022-91DE-5AE1D980FAAC@icu-project.org> References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <9f3c41b10707030106y678d0b0egf3024a2cabe3252a@mail.gmail.com> <29E5739B-04D1-4CC3-8958-C424AC94DCD3@icu-project.org> <9f3c41b10707030132k4fc3cf87i48d323df4c15a405@mail.gmail.com> <5A2D4A86-761E-4022-91DE-5AE1D980FAAC@icu-project.org> Content-Type: multipart/alternative; boundary=Apple-Mail-49--992120842 Message-Id: <2D56C1D3-11CE-4CB4-8B5D-78289EE57621@icu-project.org> From: "Steven R. Loomis" Subject: Re: Google data Date: Tue, 3 Jul 2007 07:38:29 -0700 To: cldr-users@unicode.org X-Mailer: Apple Mail (2.752.3) X-archive-position: 181 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-49--992120842 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed But, if something is not working, please let us know. -s On 03 Lul 2007, at 07:30, Steven R. Loomis wrote: >> Also, Bugzilla here doesn't work, I'm given to understand. What's the >> procedure, then? > > The bug tracking system does indeed work, we use it, and review it, > every week. > --Apple-Mail-49--992120842 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII But, if something is not working, please let us = know.
-s

On 03 Lul 2007, at 07:30, = Steven R. Loomis wrote:

Also, Bugzilla here doesn't work, I'm given to understand. What's = the

procedure, then?


The = bug tracking system does indeed work, we use it, and review it, every = week.


=

= --Apple-Mail-49--992120842-- From verdy_p@wanadoo.fr Tue Jul 3 11:26:12 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 11:26:12 -0500 (CDT) Received: from smtp24.orange.fr (smtp24.orange.fr [193.252.22.26]) by unicode.org (8.13.4/8.12.11) with ESMTP id l63GQBNv015313 for ; Tue, 3 Jul 2007 11:26:12 -0500 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2418.orange.fr (SMTP Server) with ESMTP id 0A14F1C000A3 for ; Tue, 3 Jul 2007 18:26:06 +0200 (CEST) Received: from HARNON (APoitiers-156-1-5-70.w86-207.abo.wanadoo.fr [86.207.164.70]) by mwinf2418.orange.fr (SMTP Server) with ESMTP id 25B5E1C0008C for ; Tue, 3 Jul 2007 18:26:05 +0200 (CEST) X-ME-UUID: 20070703162605154.25B5E1C0008C@mwinf2418.orange.fr From: "Philippe Verdy" To: References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <01b101c7bd4b$9d9c6de0$ea62f853@streamserve.com> <20070703085217.GO30825@nexus.in-nomine.org> <30b660a20707030230i4132ad96od242b4498b2ebe2d@mail.gmail.com> Subject: RE: Google data Date: Tue, 3 Jul 2007 18:26:01 +0200 Organization: Ordinateur Personnel Message-ID: <00a001c7bd8e$d8904e10$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01C7BD9F.9C191E10" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <30b660a20707030230i4132ad96od242b4498b2ebe2d@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace9VZVqrfsrw0bdTV2+FFuK0A8m+gAMV8/w X-archive-position: 182 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 This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01C7BD9F.9C191E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When you say that =93they are taken from data translated by humans=94 it = does mean that they were translated by Google, just that Google has found = those translations made by humans, most probably from its web indexing = database. I have serious doubt that these =93(default)=94 votes were translated = really by someone working for Google or reviewed by one of them. =20 I can find many occurrences in the remaining entries, including those in = a locale for which Google is strategically involved (French is an example) where this data was not reviewed. For example we can easily find = Google=92s default votes in favour of =93Za=EFre=94, which is the former name of = the country, that should not be kept in any locale, even when there are evidences = that another translation is preferred (as shown by the votes of other = vetters). =20 I can only explain that by the fact that it was selected by some = automated search made by Google within the billions of webpages that Google has indexed and for which it has maintained statistics for linking purpose. = I=92 not saying that this data is wrong, in the Google search perspective, = but it is not qualified because it is linking documents made by lots of people, including many that don=92t know the language, or that copied the = information from another website when creating and publishing their own lists of = country names, or when extracting other references in various languages without really qualifying the actual language inserted in their webpages, or = that created these texts a long time ago before the name was changed. =20 So I am not criticizing these =93default=94 Google=92s entries, only the = fact that they are counted as votes, instead of just being an hint about names = that can still be frequently seen. What is more problematic is that this data = is often not targeted for the correct language, and so the English forms = that are too often found in many texts (because of ignorance of a local name = or because the language was implicitly specified elsewhere in the = documents, in a way that Google could not detect when indexing these texts) tend to pollute the results.=20 =20 =3D=3D CLDR / UNICODE RESPONSIBILITIES =3D=3D =20 If Unicode or ISO or MARC or other standard bodies publish such lists = with those errors, it will be perceived by many as having a sort of official status, and some (many?) people will even change their existing correct texts using the =93standard=94 forms adopted by Unicode, ISO, MARC, = ISSN/ISBN databases, even if these names were wrong (due to lack of information = and use of a =93reasonable=94 suggestion, or possible uncorrected errors due = to lack of review). =20 The CLDR data tends to get some respect because of the name of Unicode = and its large members (including other standard bodies and international organisations) that supports this project. This means that the project = has additional responsibilities to avoid increasing the confusion, = especially to avoid that English terms starts (or continues) polluting other languages = for which there already exists accurate terms and orthographies. =20 For this reason, I will much prefer an incomplete set of data for a = locale, to some data published in some CLDR release that contains many errors because it was not correctly reviewed and discussed (like it was the = case with CLDR 1.4 that has caused lots of damages since it was published, = with lots of replication of this data everywhere on the web). The CLDR data already influences a lot many places, in addition to being used in many softwares. =20 =3D=3D SOLVING DISPUTES AND AMBIGUITIES =3D=3D =20 In some cases, changing a term that is commonly found on the web is necessary because of a common false assumption for a language whose reference is difficult to find. =20 I can give an example with =93Tonga=94 in English, the language spoken = in the Tonga islands in the Pacific, which is completely unrelated to the = =93Tonga=94 language spoken in Malawi and locally named =93Tonga Nyasa=94 or = =93chiTonga=94 : be careful here when voting, because one may incorrectly assume, when = reading the English source, that this =93Tonga (Nyasa)=94 entry designates a = variant of the =93Tonga=94 language in the Pacific, and then choose to translate it = using the same term formed after a genitive form for the people of Tonga = Islands, and it would be completely wrong because =93Tonga=94 in =93Tonga = (Nyasa)=94 is not referring to any place but directly to the Tonga ethnic tribe and its culture and language=85 =20 To solve such conflicts, adding additional proposals (even without = voting for them) may help other vetters finding that they were making false assumptions, allowing them to find other references by themselves, why = they were wrong,and why other vetters are supporting another proposal. In = such cases, these extra entries will help finding the correct term and = finally a consensus. They are easier to create like this than with the current = CLDR system of adding a reference (because each time you add a reference, it requires adding a duplicate entry that may split the votes despite this = is the exact same value). =20 If you need to add an external reference for an entry in the CLDR data, = do it, but don=92t vote for it : merge your vote for the single identical = entry that already gets the votes by others (your additional entry will remain there for reference purpose only), so that they can overturn the provisionally selected entry for CLDR 1.5. (My opinion is that we should = be able to add/remove and vote for one or several references associated to = the same CLDR entry option, independantly of our vote for that entry, = instead of having to duplicate it; but the solution I propose here should still = work for the same purpose). =20 I also invite those vetters that have made proposals that are no longer supported by them (because there was some agreement found between = vetters), to delete their now unused proposals if they don=92t help disambiguating = some entries (for example acceptable synonyms that don=92t create more = confusion with other entries, and identical entries for reference purpose should = be kept, but past entries created with an agreed typo should be removed, notably all those many erroneous entries inserted with obvious typos, = like those coming from Google default data). =20 I also propose, now that we are in the vetting phase, to remove the possibility of voting directly from the long list (to avoid changing = votes by error) : we should be able to vote only in individual entries, where = the reference entries are visible along with the link for adding comments in = the forum with a relevant subject line containing the exact entry code=85 In = the current state of the data, we really better need to validate each entry individually. =20 =3D=3D RFE: CLDR SUGGESTIONS =3D=3D =20 (1) There=92s also something that the CLDR long lists does not currently = show correctly: when an entry is provisonnally approved, and it is listed =93ordered by priority=94, the list does not differentiate entries for = which there remains NO dispute, and those where all votes are still not convergent. This does not help finding those entries where possible = problems are remaining and not solved. =20 (2) And there should be a way, when visiting an individual entry and displaying its own vetting page, to look for message(s) in the forum = whose subject line matches the entry code (i.e. the subject line that is automatically created from the link at the top of this page used to = write a comment in the forum), and display specifically those message(s): it = would really be helpful for solving conflicts in a easier way. In other words, = we should be able to associate the vetted entries with a list of comments = in the forum. =20 =20 _____ =20 De : cldr-users-bounce@unicode.org = [mailto:cldr-users-bounce@unicode.org] De la part de Mark Davis Envoy=E9 : mardi 3 juillet 2007 11:30 =C0 : cldr-users@unicode.org Objet : Re: Google data =20 Let me repeat: these are not machine translations, nor computer translations. They are taken from data translated by humans. Of course, that data may be incorrect, but it was not machine generated. I'll repeat: I filed a bug on this at http://www.unicode.org/cldr/bugs/locale-bugs?findid=3D1411 for = discussion at the meeting tomorrow morning. If you have any further comments, please = add them to that bug report as a Reply.=20 So please look at = http://www.unicode.org/cldr/bugs/locale-bugs?findid=3D1411 to see if you want to add anything that the committee should consider. ------=_NextPart_000_00A1_01C7BD9F.9C191E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

When you say = that “they are taken from data translated by humans” it does mean that they = were translated by Google, just that Google has found those translations made = by humans, most probably from its web indexing database. I have serious = doubt that these “(default)” votes were translated really by someone = working for Google or reviewed by one of them.

 =

I can find many = occurrences in the remaining entries, including those in a locale for which Google = is strategically involved (French is an example) where this data was not = reviewed. For example we can easily find Google’s default votes in favour of = “Za=EFre”, which is the former name of the country, that should not be kept in any = locale, even when there are evidences that another translation is preferred (as = shown by the votes of other vetters).

 =

I can only = explain that by the fact that it was selected by some automated search made by Google = within the billions of webpages that Google has indexed and for which it has maintained statistics for linking purpose. I’ not saying that this = data is wrong, in the Google search perspective, but it is not qualified = because it is linking documents made by lots of people, including many that = don’t know the language, or that copied the information from another website = when creating and publishing their own lists of country names, or when = extracting other references in various languages without really qualifying the = actual language inserted in their webpages, or that created these texts a long time ago = before the name was changed.

 =

So I am not = criticizing these “default” Google’s entries, only the fact that = they are counted as votes, instead of just being an hint about names that can = still be frequently seen. What is more problematic is that this data is often not = targeted for the correct language, and so the English forms that are too often = found in many texts (because of ignorance of a local name or because the language = was implicitly specified elsewhere in the documents, in a way that Google = could not detect when indexing these texts) tend to pollute the results. =

 =

=3D=3D CLDR / = UNICODE RESPONSIBILITIES =3D=3D

 =

If Unicode or = ISO or MARC or other standard bodies publish such lists with those errors, it will = be perceived by many as having a sort of official status, and some (many?) people = will even change their existing correct texts using the “standard” forms = adopted by Unicode, ISO, MARC, ISSN/ISBN databases, even if these names were wrong = (due to lack of information and use of a “reasonable” suggestion, or possible uncorrected errors due to lack of = review).

 =

The CLDR data = tends to get some respect because of the name of Unicode and its large members (including other standard bodies and international organisations) that = supports this project. This means that the project has additional = responsibilities to avoid increasing the confusion, especially to avoid that English terms = starts (or continues) polluting other languages for which there already exists accurate terms and orthographies.

 =

For this reason, = I will much prefer an incomplete set of data for a locale, to some data = published in some CLDR release that contains many errors because it was not correctly reviewed and discussed (like it was the case with CLDR 1.4 that has = caused lots of damages since it was published, with lots of replication of this data everywhere on the web). The CLDR data already influences a lot many = places, in addition to being used in many softwares.

 =

=3D=3D SOLVING = DISPUTES AND AMBIGUITIES =3D=3D

 =

In some cases, = changing a term that is commonly found on the web is necessary because of a common = false assumption for a language whose reference is difficult to = find.

 =

I can give an = example with “Tonga” in English, the language spoken in the Tonga = islands in the Pacific, which is completely unrelated to the “Tonga” language spoken in Malawi and locally named “Tonga Nyasa” or = “chiTonga” : be careful here when voting, because one may incorrectly assume, when = reading the English source, that this “Tonga (Nyasa)” entry = designates a variant of the “Tonga” language in the Pacific, and then = choose to translate it using the same term formed after a genitive form for the = people of Tonga Islands, and it would be completely wrong because = “Tonga” in “Tonga (Nyasa)” is not referring to any place but directly to the Tonga = ethnic tribe and its culture and language…

 =

To solve such = conflicts, adding additional proposals (even without voting for them) may help = other vetters finding that they were making false assumptions, allowing them = to find other references by themselves, why they were wrong,and why other = vetters are supporting another proposal. In such cases, these extra entries will = help finding the correct term and finally a consensus. They are easier to create like = this than with the current CLDR system of adding a reference (because each = time you add a reference, it requires adding a duplicate entry that may split the = votes despite this is the exact same value).

 =

If you need to = add an external reference for an entry in the CLDR data, do it, but don’t = vote for it : merge your vote for the single identical entry that already = gets the votes by others (your additional entry will remain there for reference = purpose only), so that they can overturn the provisionally selected entry for = CLDR 1.5. (My opinion is that we should be able to add/remove and vote for one or = several references associated to the same CLDR entry option, independantly of = our vote for that entry, instead of having to duplicate it; but the solution I = propose here should still work for the same = purpose).

 =

I also invite = those vetters that have made proposals that are no longer supported by them (because = there was some agreement found between vetters), to delete their now unused = proposals if they don’t help disambiguating some entries (for example = acceptable synonyms that don’t create more confusion with other entries, and = identical entries for reference purpose should be kept, but past entries created = with an agreed typo should be removed, notably all those many erroneous entries = inserted with obvious typos, like those coming from Google default = data).

 =

I also propose, = now that we are in the vetting phase, to remove the possibility of voting = directly from the long list (to avoid changing votes by error) : we should be able to = vote only in individual entries, where the reference entries are visible = along with the link for adding comments in the forum with a relevant subject line containing the exact entry code… In the current state of the data, = we really better need to validate each entry = individually.

 =

=3D=3D RFE: CLDR = SUGGESTIONS =3D=3D

 =

(1) = There’s also something that the CLDR long lists does not currently show correctly: = when an entry is provisonnally approved, and it is listed “ordered by = priority”, the list does not differentiate entries for which there remains NO = dispute, and those where all votes are still not convergent. This does not help = finding those entries where possible problems are remaining and not = solved.

 =

(2) And there = should be a way, when visiting an individual entry and displaying its own vetting = page, to look for message(s) in the forum whose subject line matches the entry = code (i.e. the subject line that is automatically created from the link at the top = of this page used to write a comment in the forum), and display specifically = those message(s): it would really be helpful for solving conflicts in a easier = way. In other words, we should be able to associate the vetted entries with a = list of comments in the forum.

 =

 =

De : cldr-users-bounce@unicode.org [mailto:cldr-users-bounce@unicode.org] = De la part de Mark Davis
Envoy=E9 : mardi 3 = juillet 2007 11:30
=C0 : = cldr-users@unicode.org
Objet : Re: Google = data

 

Let me repeat: = these are not machine translations, nor computer translations. They are taken from = data translated by humans.

Of course, that data may be incorrect, but it was not machine generated. = I'll repeat:

I filed a bug on this at http://www.unicode.org/cldr/bugs/locale-bugs?findid=3D1= 411 for discussion at the meeting tomorrow morning. If you have any = further comments, please add them to that bug report as a Reply. =


So please look at http://www.unicode.org/cldr/bugs/locale-bugs?findid=3D1= 411 to see if you want to add anything that the committee should = consider.

------=_NextPart_000_00A1_01C7BD9F.9C191E10-- From mark.edward.davis@gmail.com Tue Jul 3 12:04:30 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 12:04:30 -0500 (CDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by unicode.org (8.13.4/8.12.11) with ESMTP id l63H4TRa004947 for ; Tue, 3 Jul 2007 12:04:30 -0500 Received: by wa-out-1112.google.com with SMTP id j40so2997322wah for ; Tue, 03 Jul 2007 10:04:29 -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=cDjNf1gyud/mLalqn0t/y4UhZGV8QI1AExw/1y8/Nx17luETwBhsOHHx8GGRqK/9yCzVpBNJaoYgj93hYOd4Th8EpY+XMfy9XIXS1iNmC6e+I/pI2ahO/GjB3ltc04EBlcROEM7CTyME4mpxiU6Pj+GOsrv9bKwUWzzOHY+4pJk= 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=Yi5JNzpuNfZyf975o4YhVlCaSamVXzMGAUbZ+ZE84+cS1mg6J2a3g7942ZoOADLZrBjmdzGzxLX3LOKDH23iNxQx2VXADNvwLIJqg2JJ+gnJRVF5q8lyIQWBP/93D6RSd+MBOr+fxjNO1Zr7LM5d+Ix7QkE1vCasgBPA57MMlX4= Received: by 10.114.121.1 with SMTP id t1mr6389639wac.1183482269279; Tue, 03 Jul 2007 10:04:29 -0700 (PDT) Received: by 10.114.192.10 with HTTP; Tue, 3 Jul 2007 10:04:29 -0700 (PDT) Message-ID: <30b660a20707031004i73edea1ewd6fa41359d11633f@mail.gmail.com> Date: Tue, 3 Jul 2007 10:04:29 -0700 From: "Mark Davis" To: cldr-users@unicode.org Subject: Re: Google data In-Reply-To: <00a001c7bd8e$d8904e10$0a01a8c0@rodage.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_156018_23683729.1183482269209" References: <1183370627.4153.52.camel@dhcppc2> <007601c7bcf6$5c09c7b0$0a01a8c0@rodage.dyndns.org> <30b660a20707021750k1278e389r18ac235de1d94c84@mail.gmail.com> <9f3c41b10707030038o294df944ob66c9bee0531f35a@mail.gmail.com> <5ED03672-112D-497E-8BA9-E7A7165D9F6E@icu-project.org> <01b101c7bd4b$9d9c6de0$ea62f853@streamserve.com> <20070703085217.GO30825@nexus.in-nomine.org> <30b660a20707030230i4132ad96od242b4498b2ebe2d@mail.gmail.com> <00a001c7bd8e$d8904e10$0a01a8c0@rodage.dyndns.org> X-Google-Sender-Auth: f5a43daf9ce50708 X-archive-position: 183 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_156018_23683729.1183482269209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/3/07, Philippe Verdy wrote: > > When you say that "they are taken from data translated by humans" it does > mean that they were translated by Google, just that Google has found those > translations made by humans, most probably from its web indexing database. I > have serious doubt that these "(default)" votes were translated really by > someone working for Google or reviewed by one of them. > These were translated by people, who took the English and translated it. It was NOT done by scraping. Now, in some cases this may have been older data (eg before Zaire changed names) or may have been translated out of context, etc. And there is always the possibility of human error. The way the voting is structured, the default items' votes are NOT enough for approval, and are nullified if anyone else votes from that organization. Moreover, they are *not* enough to overturn a previously approved item. If you have specific cases that you want to raise, what really helps is to post the zoomed URLs as examples. The other item you list below are unconnected, and should be raised under different topics. ------=_Part_156018_23683729.1183482269209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 7/3/07, Philippe Verdy <verdy_p@wanadoo.fr> wrote:

When you say that "they are taken from data translated by humans" it does mean that they were translated by Google, just that Google has found those translations made by humans, most probably from its web indexing database. I have serious doubt that these "(default)" votes were translated really by someone working for Google or reviewed by one of them.


These were translated by people, who took the English and translated it. It was NOT done by scraping. Now, in some cases this may have been older data (eg before Zaire changed names) or may have been translated out of context, etc. And there is always the possibility of human error.

The way the voting is structured, the default items' votes are NOT enough for approval, and are nullified if anyone else votes from that organization. Moreover, they are *not* enough to overturn a previously approved item. If you have specific cases that you want to raise, what really helps is to post the zoomed URLs as examples.

The other item you list below are unconnected, and should be raised under different topics.
------=_Part_156018_23683729.1183482269209-- From v-magdad@microsoft.com Tue Jul 3 13:10:15 2007 Received: with ECARTIS (v1.0.0; list cldr-users); Tue, 03 Jul 2007 13:10:37 -0500 (CDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by unicode.org (8.13.4/8.12.11) with ESMTP id l63IAFMZ021504; Tue, 3 Jul 2007 13:10:15 -0500 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 3 Jul 2007 11:10:09 -0700 Received: from NA-EXMSG-C125.redmond.corp.microsoft.com ([157.54.61.83]) by tk1-exhub-c102.redmond.corp.microsoft.com ([157.56.116.113]) with mapi; Tue, 3 Jul 2007 11:10:08 -0700 From: "Magda Danish (Unicode)" To: "unicode@unicode.org" Date: Tue, 3 Jul 2007 11:10:05 -0700 Subject: =?utf-8?B?IEludGVybmF0aW9uYWxpemF0aW9uICYgVW5pY29kZSBDb25mZXJlbmNlIDMx?= =?utf-8?B?LSAgT2N0b2JlciAxNSDigJMgMTcsIDIwMDcgLSBTYW4gSm9zZSwgQ0EgVVNB?= Thread-Topic: =?utf-8?B?IEludGVybmF0aW9uYWxpemF0aW9uICYgVW5pY29kZSBDb25mZXJlbmNlIDMx?= =?utf-8?B?LSAgT2N0b2JlciAxNSDigJMgMTcsIDIwMDcgLSBTYW4gSm9zZSwgQ0EgVVNB?= Thread-Index: Ace9nWDnShj+oL+NRWyRShzuilKzAg== Message-ID: <871A62EA91884849A3BE952CA63832D014729AD58F@NA-EXMSG-C125.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by unicode.org id l63IAFMZ021504 X-archive-position: 184 X-ecartis-version: Ecartis v1.0.0 Sender: cldr-users-bounce@unicode.org Errors-to: cldr-users-bounce@unicode.org X-original-sender: v-magdad@microsoft.com Precedence: bulk Reply-to: cldr-users@unicode.org X-list: cldr-users Immerse yourself in cutting-edge topics and new technologies, all geared for the internationalization community The program committee has created an exciting program full of new and cutting-edge topics that is relevant and engaging for the internationalization community. The three-day conference will feature a keynote presentation by Robert Bringhurst, a noted poet, book designer, typographer, historian and linguist. The conference includes a full day of tutorials followed by two days of presentations, panels and discussions. There will also be technology exhibits and demonstrations. Highlights of the Conference: Keynote Presenter: * Robert Bringhurst, noted poet, book designer, typographer, historian and linguist Tutorials in Three Tracks: * Unicode 5.0: An Introduction to Writing Systems & Unicode; * Fundamental Specifications and Unicode Algorithms; * Internationalization: An Introduction; * A two-part tutorial on Oracle/SQL Server, Making Sense of Oracle Character Sets and Length Semantics; * ICU, in both C and Java * Best Practices in Software Localization Process and Technology; * Web Internationalization - Standards and Best Practices; * Writing Win32 Multilingual Applications Using the Windows Vista MUI Technology; Extending Mac OS X's International Support. * Presenters come from such organizations as Apple Computer, ASMUS, Inc., Google, IBM Corporation, i18N Inc., Microsoft, W3C, and Yahoo! Sessions in Four Tracks: * Sessions on Tuesday are in four tracks; sessions on Wednesday are in three tracks plus, for the first time, a fourth track comprising the Unicode Technical Committee Meeting. * The following is just a small sample of some of the cutting-edge presentations that will be given at IUC 31. For the full program, visit the IUC 31 Web site at http://www.unicodeconference.o