Re: [l10n-dev] Unicode Releases Common Locale Data Repository, Version 1.4
hi Eike there are 2 options that I can see : 1. go with your suggestion, where the localegen tool adds an option to populate fields in the form by reading the data from cldr 2. each CLDR release comes with the OOo XML files already generated from CLDR, which users can download. In this case, users would still need to populate the proprietary OOo XML fields by hand which is not so user friendly, but would be easy to do. I prefer option 1. Alberto : what do you think of this idea ? would you be able to implement this in your tool ? Peter Eike Rathke wrote On 09/26/06 12:35,: Hi Peter, On Mon, Sep 11, 2006 at 13:29:33 +0100, Peter Nugent wrote: the tools should be avaailble for download from : http://unicode.org/Public/cldr/1.4.0/ where core.zip contains the 1.4 data. the 1.4 tools should also be posted to the same location soon. but for now you can get the latest CVS snapshot of tools and data at : ftp://ftp.unicode.org/Public/cldr/cldr-repository-daily.tgz Well, yes, I know that data is downloadable and tools may be built from the repository. But this is too cumbersome for localizers who just want to create some locale data for their locale of interest. They need a generate from CLDR or enter data here form similar to the Locale Generator available at http://www.it46.se/localegen/ The CLDR tools are really fine (I appreciate) for the tedious work of locale data audits and merging data from CLDR to OOo, but in the current state are nothing for an end user, which most locale data submitters are to be considered in this context. Encouraging people to generate OOo locale data from data already available at CLDR is hard if using the tools is much harder than creating the data from scratch using other tools. As the it46 generator is already able to generate CLDR data as well, maybe it could be an option to teach it to merge existing CLDR data to a new OOo locale data? Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Unicode Releases Common Locale Data Repository, Version 1.4
Eike apologies for the delayed reply, I only saw this now. the tools should be avaailble for download from : http://unicode.org/Public/cldr/1.4.0/ where core.zip contains the 1.4 data. the 1.4 tools should also be posted to the same location soon. but for now you can get the latest CVS snapshot of tools and data at : ftp://ftp.unicode.org/Public/cldr/cldr-repository-daily.tgz (the Oo.o tools have not changed since the 1.4 release) all CLDR tools are in the cldr/tools/java dir where you will find a readme for building them. the Oo.o tools are in cldr/data/tools/java/org/unicode/cldr/ooo/ which also contains a readme on how to use them. Peter Eike Rathke wrote On 08/30/06 16:07,: Hi Peter, On Wed, Jul 19, 2006 at 11:24:23 +0100, Peter Nugent wrote: There are tools at the link below for generating new OO.o locale data files from CLDR, which I would encourage people to use when starting a new OO.o locale. Forgive my blindness, but where on the CLDR site may I find such tool? Yes, of course I know that there are the Java tools checked in to the repository we did the comparison and merging between CLDR and OOo with. Just how should a localizer, not being a developer, (a) find them and (b) use them? You can contact me directly for more information. I prefer making information publicly available on the list ;-) Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] Unicode Releases Common Locale Data Repository, Version 1.4
hi all, I'm fwding the announcement of the release of cldr 1.4. Many thanks to those of you who participated in contributing data or vetting of data. There are tools at the link below for generating new OO.o locale data files from CLDR, which I would encourage people to use when starting a new OO.o locale. You can contact me directly for more information. thx Peter Unicode Releases Common Locale Data Repository, Version 1.4 Mountain View, CA, July 17, 2006 - The Unicode® Consortium announced today the release of the new version of the Unicode Common Locale Data Repository (CLDR 1.4), providing key building blocks for software to support the world's languages. CLDR is by far the largest and most extensive standard repository of locale data. This data is used by a wide spectrum of companies for their software internationalization and localization: adapting software to the conventions of different languages for such common software tasks as formatting of dates, times, time zones, numbers, and currency values; sorting text; choosing languages or countries by name; and many others. This release of CLDR contains data for 121 languages and 142 territories -- 360 locales in all. Version 1.4 of the repository contains over 25% more locale data than the previous release, with over 17,000 new or modified data items entered by over 100 different contributors. Major contributors to CLDR 1.4 include Apple, Google, IBM, and Sun, plus official representatives from a number of countries. Many other organizations and individuals around the globe have also made important contributions. CLDR 1.4 uses the XML format provided by the newest version of the Locale Data Markup Language (LDML 1.4). LDML is a format used not only for CLDR, but also for general interchange of locale data, such as in Microsoft's .NET. Some of the major features of LDML 1.4 used in the repository include new XML structures supporting customizable detection of words, lines, and sentences (segmentation), transliteration between different alphabets, and full compatibility with the recently approved internet standards for language tags. It also supports enhanced formats for dates and times, and adds new guidelines for date, time, and number parsing. For more information about the CLDR project, see http://www.unicode.org/cldr/ http://www.unicode.org/cldr/ . The latest features of CLDR will also be showcased at the 30th Internationalization and Unicode Conference (IUC) on November 17-19, 2006 in Washington, D.C. -- see http://www.unicodeconference.org/ http://www.unicodeconference.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: Adobe Systems, L'Agence intergouvernementale de la Francophonie, Apple Computer, Basis Technology, Denic e.G., Google, Government of India - Ministry of Information Technology, Government of Pakistan - National Language Authority, HP, IBM, Justsystem, Microsoft, Monotype Imaging, Oracle, SAP, Sun Microsystems, Sybase, The University of California at Berkeley, Yahoo, plus well over a hundred Associate, Liaison, and Individual members. For more information, please contact the Unicode Consortium (http://www.unicode.org/ http://www.unicode.org/ ). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locales with LocaleGen and CLDR
Alberto great, let me know if you have any issues with the tools. hmm, never came across a 4 day week before, is a new calendar type required here also ? Peter Alberto Escudero Pascual wrote: Hi Peter, I have now over half a dozen of locales of people that have used the http://www.it46.se/localegen tool that we will like to send into OOo and CLDR. I will try to get up and running the converter tool from the CVS and send you the locales in cldr format. I have one issue regarding Igbo, their calendar has 4 days in a week. How should i address their calendar both in OOo and CLDR? If any other groups want to submit new locales please refer to the Localgen, i will try to push them into CLDR if we get them via ther tool before Wednesday 13.00 PM (GMT) next week Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit - new process to submit corrections to CLDR
Hi Simos you should have received an e mail just now with your account details. If there are any other problems pls let me know. thx Peter Peter Nugent ha scritto: Simos Xenitellis ha scritto: O/H Peter Nugent έγραψε: Simos Sorry you didn't receive a reply so far, I will set up an account for you - which languages are you interested in ? Thanks Peter, I am interested for the Greek language. I also plan to sent an e-mail to some user groups with members from a variety of languages, suggesting to register and describe to them how to add/update their locale data. great thanks. Shall I point anyone interested to you to have an account created? yes. Does the registration form at Unicode.org work to help create a CLDR submitter ID work? I believe it does. Simos Anyone else who needs to get an account please e mail me directly and I will take care of it. thx Peter Simos Xenitellis ha scritto: O/H Eike Rathke έγραψε: Hi, While we are in the hot phase of the second audit and started submitting bugs against the CLDR, the CLDR data correction process has changed. Submitting data bugs against the CLDR is now deprecated. Instead, the survey tool should be used. For an entry page please visit http://www.unicode.org/cldr/wiki?DataBugs I'll update the description in our audit document soon. I applied to get a CLDR Submitter ID last weekend and I did not hear from them yet. I just wrote to their contact e-mail address (found on the page to submit a request of username/password) and I am expecting for a reply. Has anyone been through this to get an account? How long does it take to get a reply? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] [Fwd: Announcement: CLDR 1.4 Data Submission Period Now Starting]
Pls e mail me directly if you need an account for the CLDR survey tool, or if you run into any issues thx Peter Peter Nugent ha scritto: Hi, jsut a reminder, please use the survey tool below to file bugs highlighted by the new locale data audit, rather than filing bugs against CLDR. CLDR TC is now returning all data bugs and asking people to use the survey tool instead. thx Peter Peter Nugent ha scritto: Hi, CLDR is now looking for your locale data submissions and corrections. For those of you with feedback on CLDR issues in Eike's Locale Data Audit chart, you can provide it directly to CLDR using the survey tool in the link below. thx Peter Messaggio originale Oggetto: Announcement: CLDR 1.4 Data Submission Period Now Starting Data: Fri, 03 Feb 2006 09:04:13 -0800 Da: Rick McGowan [EMAIL PROTECTED] A: unicode@unicode.org Mountain View, CA, USA - 2006-02-03 - The Unicode Consortium today announced the start of the submission period for locale and language data for CLDR Version 1.4. The Common Locale Data Repository (CLDR) project provides a general XML format for the exchange of language and locale data for use in application and system development, and gathers, stores, and makes available a common set of language and locale data generated in that format. CLDR Version 1.3 contained data for 96 languages and 130 territories. In addition to new data, CLDR 1.4 will add new structure to support, among other things: flexible date time formatting (including quarters), measurement system names, segmentation (customized line word break), and transliteration. For more information, see http://www.unicode.org/cldr/. During this period, the Unicode consortium encourages the submission of proposed new data and proposed corrections into the repository. Most of the data can be entered or viewed via the newly-revised Survey Tool at http://unicode.org/cldr/apps/survey. An Instructions link on that page provides usage information. At the end of the submission period (2006-03-15), there is a vetting period for the submitted data. CLDR 1.4 is scheduled for release on 2006-05-15. -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit - new process to submit corrections to CLDR
Simos Sorry you didn't receive a reply so far, I will set up an account for you - which languages are you interested in ? Anyone else who needs to get an account please e mail me directly and I will take care of it. thx Peter Simos Xenitellis ha scritto: O/H Eike Rathke έγραψε: Hi, While we are in the hot phase of the second audit and started submitting bugs against the CLDR, the CLDR data correction process has changed. Submitting data bugs against the CLDR is now deprecated. Instead, the survey tool should be used. For an entry page please visit http://www.unicode.org/cldr/wiki?DataBugs I'll update the description in our audit document soon. I applied to get a CLDR Submitter ID last weekend and I did not hear from them yet. I just wrote to their contact e-mail address (found on the page to submit a request of username/password) and I am expecting for a reply. Has anyone been through this to get an account? How long does it take to get a reply? Simos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit - new process to submit corrections to CLDR
Simos Xenitellis ha scritto: O/H Peter Nugent έγραψε: Simos Sorry you didn't receive a reply so far, I will set up an account for you - which languages are you interested in ? Thanks Peter, I am interested for the Greek language. I also plan to sent an e-mail to some user groups with members from a variety of languages, suggesting to register and describe to them how to add/update their locale data. great thanks. Shall I point anyone interested to you to have an account created? yes. Does the registration form at Unicode.org work to help create a CLDR submitter ID work? I believe it does. Simos Anyone else who needs to get an account please e mail me directly and I will take care of it. thx Peter Simos Xenitellis ha scritto: O/H Eike Rathke έγραψε: Hi, While we are in the hot phase of the second audit and started submitting bugs against the CLDR, the CLDR data correction process has changed. Submitting data bugs against the CLDR is now deprecated. Instead, the survey tool should be used. For an entry page please visit http://www.unicode.org/cldr/wiki?DataBugs I'll update the description in our audit document soon. I applied to get a CLDR Submitter ID last weekend and I did not hear from them yet. I just wrote to their contact e-mail address (found on the page to submit a request of username/password) and I am expecting for a reply. Has anyone been through this to get an account? How long does it take to get a reply? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] [Fwd: Announcement: CLDR 1.4 Data Submission Period Now Starting]
Hi, jsut a reminder, please use the survey tool below to file bugs highlighted by the new locale data audit, rather than filing bugs against CLDR. CLDR TC is now returning all data bugs and asking people to use the survey tool instead. thx Peter Peter Nugent ha scritto: Hi, CLDR is now looking for your locale data submissions and corrections. For those of you with feedback on CLDR issues in Eike's Locale Data Audit chart, you can provide it directly to CLDR using the survey tool in the link below. thx Peter Messaggio originale Oggetto: Announcement: CLDR 1.4 Data Submission Period Now Starting Data: Fri, 03 Feb 2006 09:04:13 -0800 Da: Rick McGowan [EMAIL PROTECTED] A: unicode@unicode.org Mountain View, CA, USA - 2006-02-03 - The Unicode Consortium today announced the start of the submission period for locale and language data for CLDR Version 1.4. The Common Locale Data Repository (CLDR) project provides a general XML format for the exchange of language and locale data for use in application and system development, and gathers, stores, and makes available a common set of language and locale data generated in that format. CLDR Version 1.3 contained data for 96 languages and 130 territories. In addition to new data, CLDR 1.4 will add new structure to support, among other things: flexible date time formatting (including quarters), measurement system names, segmentation (customized line word break), and transliteration. For more information, see http://www.unicode.org/cldr/. During this period, the Unicode consortium encourages the submission of proposed new data and proposed corrections into the repository. Most of the data can be entered or viewed via the newly-revised Survey Tool at http://unicode.org/cldr/apps/survey. An Instructions link on that page provides usage information. At the end of the submission period (2006-03-15), there is a vetting period for the submitted data. CLDR 1.4 is scheduled for release on 2006-05-15. -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOo locale data and CLDR
Eike Rathke ha scritto: Hi Peter, On Fri, Aug 26, 2005 at 15:05:40 +0100, Peter Nugent wrote: there's actually a CLDR bug 660 on adding new locales to CLDR whch are in OO but not yet in CLDR : http://dev.icu-project.org/cgi-bin/locale-bugs/data?id=660;expression=nugent;user=guest Ah, thanks for pointing out. Btw, I wouldn't list en_CB there, it's a fake and not a locale, I'll remove it from the OOo source. thanks for pointing that out, I've updated the bug if there are any more planned pls add these to this bug I'll take a look next week. great, thanks Eike Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] OOo locale data and CLDR
Eike, there's actually a CLDR bug 660 on adding new locales to CLDR whch are in OO but not yet in CLDR : http://dev.icu-project.org/cgi-bin/locale-bugs/data?id=660;expression=nugent;user=guest if there are any more planned pls add these to this bug thx Peter Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] Eike Rathke ha scritto: Hi Kazunari, On Fri, Aug 26, 2005 at 03:13:43 +0900, Kazunari Hirano wrote: http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html I love to look at this big page. Why are you listing 107 locales on this page? Because these were available in OOo when the comparison was done. http://www.unicode.org/cldr/version/1.3.html CLDR Version 1.3 contains data for 296 locales: 96 languages and 130 territories. Does this mean OpenOffice.org could support 96 languages if these data are added to OpenOffice.org and if there are people who want to localize it with those languages and really work for the localization? Yes and no. For some languages respectively their script types and writing systems much more implementation work would have to be done than just adding some locale data. So fixating the view on just the number of languages that could be theoretically supported isn't appropriate. How about languages which are not listed on CLDR? Of course locale data can be added to OOo if not yet present in CLDR, currently there are a few, for example Basque 'eu' or the artificial Esperanto 'eo' and Interlingua 'ia'. Strictly speaking these are not locales, so maybe they will never make it into CLDR. On the other hand, OOo data could be also the initial data for CLDR on the next import round, maybe also for Common if accepted and not just as platform data. Btw, I think it would had been better to create a new thread for the topic than burrying it in the OOoCon thread. Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Much too many TODOs in locale data audit
if you have already provided feedback (as you have Hristo) then nothing further is required I believe. I assume there are no TODO: clarify items for your locale (the site seems to be unreachable at the moment) Peter Hristo Simenov Hristov wrote: On Wednesday 13 April 2005 18:31, Eike Rathke wrote: Hi, I updated http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.htm l as far as I could. The outcome is a bunch of orange cells in the Solution columns with far too many TODOs. As a result, only a few locales will get aligned to the CLDR in this round. I urge every localization team to take a look at the data and discuss the TODO items on the [EMAIL PROTECTED] list. I hope to be able to do the next round for OOo2.0.1, and unsolved TODO: clarify items by then will simply be ignored and data aligned to CLDR. So please, take your chance now and state whether the CLDR needs different data for your locale of choice, and don't forget to give some reference, online or book, that we can include in bug reports against the CLDR, otherwise there might be difficulties to get changes in. Thank you. I'll attach a file to this mail showing the results in a condensed form. It is plain text, despite the extension, but in case you use the Vim editor and have the vimoutliner package installed you'll get some colors and have folds and percentage calculation and such. So, what can I do? Acording to this: http://www.jtcsv.com/cgibin/locale-bugs?findid=459 I think that it is fixed. Regards. -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Much too many TODOs in locale data audit
[_] en_US [_] en_ZA [_] en_ZW [_] es_AR [_] fi_FI [_] id_ID [_] is_IS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale data audit for af_ZA
Dwayne I can do the conversion if you can provide fully resolved glibc files (i.e. no copy directives). However, you will still only have partial information as there is a lot of OO specific data which is not in glibc or CLDR Peter Dwayne Bailey ha scritto: On Tue, 2005-04-05 at 16:08 +0100, Peter Nugent wrote: Hi Dwayne thx for the feedback. What are the locales you wish to add ? If they are in CLDR , I have a tool to geenrate OO data from CLDR. To see the list of CLDR locales go to : http://unicode.org/cldr/data/common/main/ They are not in the CLDR. It seems from the comparison data that they are able to pull glibc locales. If we can do glibc - CLDR - OOo that will save me much effort not to mention prevent me from making silly editing errors. Excuse me for listing all 11 languages, it just helps me ensure that I haven't left any out. The glibc bug report or details follow next to the language: Afrikaans: af_ZA: in OOo bug reports submitted English: en_ZA: in OOo Zulu: http://sources.redhat.com/bugzilla/show_bug.cgi?id=488 Xhosa: http://sources.redhat.com/bugzilla/show_bug.cgi?id=493 Ndebele: still to be created Swati: http://sources.redhat.com/bugzilla/show_bug.cgi?id=533 Sotho, Northern: http://sources.redhat.com/bugzilla/show_bug.cgi?id=486 Sotho, Southern:http://sources.redhat.com/bugzilla/show_bug.cgi?id=495 Tswana: http://sources.redhat.com/bugzilla/show_bug.cgi?id=529 Tsonga: http://sources.redhat.com/bugzilla/show_bug.cgi?id=532 Venda: http://sources.redhat.com/bugzilla/show_bug.cgi?id=491 I'll have a look at the decimal and group separators issue and get back to you thx Peter Dwayne Bailey ha scritto: Sorry I'm only getting to this now :( Re: 0 af_ZA (Afrikaans_South Africa) Items: 0-3 All entries under common are correct. Validated against the AWS (Afrikaanse Woordelys en Spelreels), sorry no online version. Items: 4, 5 The ones listed under common are technically correct according to the AWS. However, I concur with issue 30568 and thus the current items listed under open_office are correct. I have a number of other locales to add most of these are already glibc locales. Is there any easy way to convert a glibc locale to the OOo xml? Should I just add these new locales as issues? -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale data audit for af_ZA
Hi Dwayne thx for the feedback. What are the locales you wish to add ? If they are in CLDR , I have a tool to geenrate OO data from CLDR. To see the list of CLDR locales go to : http://unicode.org/cldr/data/common/main/ I'll have a look at the decimal and group separators issue and get back to you thx Peter Dwayne Bailey ha scritto: Sorry I'm only getting to this now :( Re: 0 af_ZA (Afrikaans_South Africa) Items: 0-3 All entries under common are correct. Validated against the AWS (Afrikaanse Woordelys en Spelreels), sorry no online version. Items: 4, 5 The ones listed under common are technically correct according to the AWS. However, I concur with issue 30568 and thus the current items listed under open_office are correct. I have a number of other locales to add most of these are already glibc locales. Is there any easy way to convert a glibc locale to the OOo xml? Should I just add these new locales as issues? -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale data audit for af_ZA
Dwayne ther appears to be some ambihuity on the decimal and group separators issue , can you point to some websites in Afrikaans with examples justifying your claim ? thx Peter Peter Nugent ha scritto: Hi Dwayne thx for the feedback. What are the locales you wish to add ? If they are in CLDR , I have a tool to geenrate OO data from CLDR. To see the list of CLDR locales go to : http://unicode.org/cldr/data/common/main/ I'll have a look at the decimal and group separators issue and get back to you thx Peter Dwayne Bailey ha scritto: Sorry I'm only getting to this now :( Re: 0 af_ZA (Afrikaans_South Africa) Items: 0-3 All entries under common are correct. Validated against the AWS (Afrikaanse Woordelys en Spelreels), sorry no online version. Items: 4, 5 The ones listed under common are technically correct according to the AWS. However, I concur with issue 30568 and thus the current items listed under open_office are correct. I have a number of other locales to add most of these are already glibc locales. Is there any easy way to convert a glibc locale to the OOo xml? Should I just add these new locales as issues? -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Hi Hristo pls see my reply below thx Peter Hristo Simeonov Hristov ha scritto: On Thursday 03 March 2005 19:35, Peter Nugent wrote: Hi Hristo, I am finally addressing this issue in CLDR and I have a question regarding the abbreviated day and month names you provide : Is there a difference in the abbreviated day and month names when use. stand-alone as opposed to embedded in a string ? Normally this is the case for slavic languages. I cannot understand this. Can you provide me some example in English? sure : if we take the example of the abbreviated form of the 3rd month of the year stand-alone name : Mar written on top of a calendar embedded name : Fri the 4th of Mar 2005 in most languages Mar is the same in both the nominative (stand-alone) and genitive (embedded) cases but in Russian for example (according to CLDR) : stand-alone Mar = embedded Mar = other slavic languages are similar. So i was wondering if your date is stand-alone or embedded or is there a distinction in Bulgarian ? If so then which form are you providing below ? In CLDR we store the 2 forms separately thanks Peter Hristo Simenov Hristov ha scritto: On 10 12 2004 16:13, Hristo Simenov Hristov wrote: Hi Eike, 112 - is our name of the current currency. BGN is currency abbreviation. 113 - . . (before noon) is translation of 114 - . . (after noon) is translation of PM 115 - we will change days of week and months short names. , , , , , , - these will be days of week. I do not know official links but a search with google - http://trip.dir.bg/pra/viewplaces.php?id=1 , , , , , , , , , , , - these will be months. I do not know official links but a search with google - http://www.bgglobe.net/index.php?l=0c=31a=1 I made the patch and I will file an issue for this. Changes will be only for 2.0 version. 116, 117 - .. (before Christ) and .. (after Christ) is translation of BC/AD in Bulgarian. ... (before new era) and .. (new era) are from our communism time when communists tried to erase all about Christianity. So, in CLDR file have a lot of mistakes. Do you know who is responsable for our local there to contact with him and fix mistakes? The issue is 38813 -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Hi Modestas, thanks for your feedback. The list only shows data where there are conflicts between OO and CLDR. If the data agrees, it is assumed to be correct and is not shown. You raise a good point regarding the form of the month and day names. While CLDR allows noth embedded and stand-alone month names , OO (and many others such as POSIX and JDK) only allows 1 option. So the question is which one to choose ? From looking at the data it seem sthat OO currently has the embedded or genitive data (i.e. vasario for February) so it looks best to continue with this. Maybe Eike can say more on this. Havinng said all this, if you can provide both forms of day and month names I will check them against the CLDR standard. PLs also proivide some references as these will be recorded in CLDR for future reference. To see the CLDR data, see : http://www.unicode.org/cldr/ http://www.unicode.org/cldr/data/common/main/ thanks Peter Modestas Rimkus ha scritto: Hi! Sorry for such a late response. Hopefully it's not too late to correct Lithuanian locale data at least in OOo. But first of all I have some questions. Lithuanian locale (724-751) looks incomplete. There's only one abbrevated name of day of the week (729). Where are the other six? The same goes with abbrevated names of months (739). How to submit the rest of them and is there any other locale data needed? In what form should names of months and days of the week be provided? I guess the form should be the one used in full date format, for example, 2005 m. vasario 20 d. (2005-02-20). The lithuanian name of February is vasaris, though. Thanks. I'll try to provide correct Lithuanian locale data asap. Modestas Eike Rathke wrote: Hi, I just put up a document http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Dooteo, thx for the feedback. Are there any online references or standards to justify the changes ? The CLDR committee geenrally requires these in order to get changes accepted. Also they are recorded for future reference. thx Peter dooteo ha scritto: Hi Eike and Peter, Can you fix next ones (for Basque lang)? 51 eu (Basque_) platforms with this locale : open_office, common, N. ParentNode Name ID OPEN_OFFICE COMMON Currency name for Basq is EUR, as ca_ES, and es_ES or fr_FR too.. 318 currency displayName ESP Peseta ESP Perhaps there is 'Peseta' to be able to write about the old one? 319 currency displayName EUR Euro EUR And the same for symbool: it should be (euro) (bug) 320 currency symbol ESP Pts (ok) 320 currency symbol EUR Euro First day of week is monday: (bug) 321 gregorian_week firstDay day mon sun (ok) 321 gregorian_week firstDay day mon mon a dot (.) is missed: (bug) 322 gregorian_dayWidth_stand-alone_abbreviated day sun ig. ig (ok) 322 gregorian_dayWidth_stand-alone_abbreviated day sun ig. ig. a dot (.) is missed: (bug) 323 gregorian_dayWidth_stand-alone_abbreviated day mon al. al (ok) 323 gregorian_dayWidth_stand-alone_abbreviated day mon al. al. wrong abbreviate name: (bug) 324 gregorian_dayWidth_stand-alone_abbreviated day tue ar. as (ok) 324 gregorian_dayWidth_stand-alone_abbreviated day tue ar. ar. a dot (.) is missed: (bug) 325 gregorian_dayWidth_stand-alone_abbreviated day wed az. az (ok) 325 gregorian_dayWidth_stand-alone_abbreviated day wed az. az. a dot (.) is missed: (bug) 326 gregorian_dayWidth_stand-alone_abbreviated day thu og. og (ok) 326 gregorian_dayWidth_stand-alone_abbreviated day thu og. og. a dot (.) is missed: (bug) 327 gregorian_dayWidth_stand-alone_abbreviated day fri or. or (ok) 327 gregorian_dayWidth_stand-alone_abbreviated day fri or. or. a dot (.) is missed: (bug) 328 gregorian_dayWidth_stand-alone_abbreviated day sat lr. lr (ok) 328 gregorian_dayWidth_stand-alone_abbreviated day sat lr. lr. K.A. is the right one (bug) 329 gregorian_eraAbbr era 0 K.A. BCE (ok) 329 gregorian_eraAbbr era 0 K.A. K.A. K.O. is the right one (bug) 330 gregorian_eraAbbr era 1 K.O. CE (ok) 330 gregorian_eraAbbr era 1 K.O. K.O. That's all :) Thank you and best regards, Dooteo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Re: gl_ES problem in OpenOffice (bug 37309)
Hi Mikhail I agree totally with Eike, UTF-8 is the way to go. As far as I know most or all other platforms (i.e. solaris , glibc) use UTF-8 for all locales. A good example of the advantage of this is what happened when the Euro switchover happened. ISO8859-1 doesn't have the Euro symbol so any platform using theis charset had to change to one which did. UTF-8 future proofs us , it also makes maintenance easier as Eike said. Peter Eike Rathke ha scritto: Hi Mikhail, On Wed, Feb 02, 2005 at 12:26:15 -0500, Mikhail Teterin wrote: [Dear developers! This is my conversation with Eike regarding an encoding used for the translation files in OOo. To clarify: this was about i18npool's *.xml locale data files, not resource files. I'm advocating the use of 8-bit native charsets, while Eike insists on using UTF-8 for all. Eike suggested, I take this to your list.] So, the same for computers, but harder for people. Sounds like my way is better. UTF-8 only makes sense, when charsets need to be mixed -- not in this case. Changing encodings would also make use of ref=... references harder, one would always have to check that encodings match, and changing encoding of one file might affect others, which is not a desirable situation. Sorry, I don't understand this. Can you explain? The locale data files use a ref=... mechanism to refer data of other locales, for example the gl_ES.xml contains LC_CTYPE ref=es_ES/ LC_COLLATION ref=en_US/ LC_SEARCH ref=en_US/ LC_INDEX ref=es_ES/ LC_CURRENCY ref=es_ES/ LC_TRANSLITERATION ref=en_US/ LC_NumberingLevel ref=en_US/ LC_OutLineNumberingLevel ref=en_US/ Now if gl_ES.xml and en_US.xml or es_ES.xml used different encodings this might not work anymore if also replaceTo=... was used (it isn't in the case of gl_ES) and the maintainer copied an encoded replaceFrom=... value from the referred file without noticing it was a different encoding. This may sound hypothetical but it is possible and can be prevented by sticking to one encoding only. The uniformity here is hardly advantageous -- these files are, by their very nature, maintained by different people, which in itself, viewed in context of ref=... uses, almost forbids any other encoding than UTF-8 Why? Western Europeans will use iso8859-1, Eastern -- some KOI8 derivative, etc. They will almost never need to cooperate -- within one file Yes, almost never. Which makes it a perfect candidate for always be prepared for it. Installation of the GNU recode package should be always possible, even on the oldest machine. Everything is possible, of course. I maintain, that gratuitious use of UTF is inelegant -- if the file format allows to stick to 8-bit encodings, using a multibyte one is wrong. Now please take a look at my situation as a maintainer of all these files, if I would have to switch back and forth between encodings for each and every file I edit it would soon annoy me. If I can not `vi' it, it ain't a text-file :-) Use vim, that handles utf-8 ;-) Eike P.S.: Please consider to subscribe to the mailing lists you're posting to. By doing so you won't miss replies that are directed to the list only. Please reply only to the list, not to my personal account. Thanks. -- Peter Nugent, Software Engineer, Sun Microsystems Ireland Ltd, Hamilton House, East Point Business Park, Dublin 3, Ireland. Tel +353.1.8199522 Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
