[l10n-dev] Locale Data Audit
Hi, Locale Data Audit for Malay (ms_MY) Data provide by CLDR is correct, except for era 849 BC S.M. 850 AD T.M. Here is the reference http://www.karyanet.com.my/knet/index.php?tpf=istilah_karyanet&txt_cari=masihi&list_bidang=-1&btn_cari=Cari&action=cari&sid=de9041dfc39f4ee697e1701a8d68f59e For your information, this website is endorse by DBP, a goverment agency of Malaysia. Thanks, zali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Hi Eike, I tried to access to http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html b but there is an error: "Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. " As soon as it is fixed I'm gonna read it contents to make sure Basque lang is fine too there. And sorry to be so late with it... unfortunatly last months i'm very bussy... Best regards, Dooteo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
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]
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] Locale Data Audit
Hi dooteo, On Thu, Feb 10, 2005 at 10:55:05 +0100, dooteo wrote: > 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 Note that there can be more than one currency for a locale, in this case the old Peseta that was used before the Euro was introduced, so having them is no error. However, the CLDR lists the currency abbreviation instead of the name as display name, as opposed to OOo, which is why the entry is listed in the comparison. > Perhaps there is 'Peseta' to be able to write about the old one? Yes. Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Hi Jesús, On Wed, Jan 05, 2005 at 17:22:12 +0100, Jesús Corrius wrote: > >the example differs from OpenOffice, which is correct "aC" and "dC" or > >"A.C" and "D.C" ? > > The correct ones are "aC" and "dC". So this also has to be changed in OOo? Please submit an issue, you may directly assign it to me (er). Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Hi Zali many thanks for the feedback. I have filed a CLDR bug on this : http://www.jtcsv.com/cgibin/locale-bugs/incoming?id=569;user=guest regards Peter Syed Ahmad Shazali Syed Abdullah ha scritto: > Hi, > > Locale Data Audit for Malay (ms_MY) > Data provide by CLDR is correct, except for era > 849 BC S.M. > 850 AD T.M. > > Here is the reference > http://www.karyanet.com.my/knet/index.php?tpf=istilah_karyanet&txt_cari=masihi&list_bidang=-1&btn_cari=Cari&action=cari&sid=de9041dfc39f4ee697e1701a8d68f59e > For your information, this website is endorse by DBP, a goverment agency of > Malaysia. > > Thanks, > zali > > > > > - > 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
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]
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
Hi Peter, thanks for your assistance. Here's Lithuanian locale data: (I also included "stand-alone" month names in parenthesis) 724 Litai (symbol: Lt; int. symbol: LTL) 725 prieÅpiet 726 4 727 popiet 728 Pn 729 Åt 730 sekmadienis 731 pirmadienis 732 antradienis 733 treÄiadienis 734 ketvirtadienis 735 penktadienis 736 ÅeÅtadienis 737 pr. Kr. 738 po Kr. 739 Spl 740 sausio (Sausis) 741 vasario (Vasaris) 742 kovo(Kovas) 743 balandÅio (Balandis) 744 geguÅÄs (GeguÅÄ) 745 birÅelio (BirÅelis) 746 liepos (Liepa) 747 rugpjÅÄio (RugpjÅtis) 748 rugsÄjo(RugsÄjis) 749 spalio (Spalis) 750 lapkriÄio (Lapkritis) 751 gruodÅio (Gruodis) Just in case, here's the complete list of abbrevated month and day names. Months: Sau, Vas, Kov, Bal, Geg, Bir, Lie, Rgp, Rgs, Spl, Lap, Grd Days (starting Monday): Pr, An, Tr, Kt, Pn, Åt, Sk A reliable online reference of Lithuanian POSIX locale can be found here: http://www.likit.lt/all/stand/lokale/lokale.htm#p1 I also noticed a few mistakes in CLDR document. The short date format is wrong. Hyphens should be used instead of dots. For example, 2005-02-21. Spaces are also allowed, but hyphens are recommended. Also Lithuanian name for Czech language should be "ÄekÅ", not "Äekijos". Thanks, Modestas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Hi Jesús, On Wed, Jan 05, 2005 at 17:22:12 +0100, Jesús Corrius wrote: > >the example differs from OpenOffice, which is correct "aC" and "dC" or > >"A.C" and "D.C" ? > > The correct ones are "aC" and "dC". Just stumbled over it while I wanted to fix it: this was about the abbreviated era names. What are the full era names, which currently are also "A.C." and "D.C."? Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Hi Modestas, On Sun, Feb 20, 2005 at 17:17:31 +0200, Modestas Rimkus wrote: > 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. Mostly the names are used in context of the number formatter or smilar, like in your example, and very seldom they are used stand-alone. OOo currently has no mechanism to disinguish between these forms. Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Hi Modestas, many thanks for providing this info. I have files CLDR bug 573 on this : http://www.jtcsv.com/cgibin/locale-bugs/incoming?id=573;user=guest regards Peter Modestas Rimkus ha scritto: > Hi Peter, > > thanks for your assistance. Here's Lithuanian locale data: > (I also included "stand-alone" month names in parenthesis) > > 724 Litai (symbol: Lt; int. symbol: LTL) > 725 prieÅpiet > 726 4 > 727 popiet > 728 Pn > 729 Åt > 730 sekmadienis > 731 pirmadienis > 732 antradienis > 733 treÄiadienis > 734 ketvirtadienis > 735 penktadienis > 736 ÅeÅtadienis > 737 pr. Kr. > 738 po Kr. > 739 Spl > 740 sausio (Sausis) > 741 vasario (Vasaris) > 742 kovo(Kovas) > 743 balandÅio (Balandis) > 744 geguÅÄs (GeguÅÄ) > 745 birÅelio (BirÅelis) > 746 liepos (Liepa) > 747 rugpjÅÄio (RugpjÅtis) > 748 rugsÄjo(RugsÄjis) > 749 spalio (Spalis) > 750 lapkriÄio (Lapkritis) > 751 gruodÅio (Gruodis) > > Just in case, here's the complete list of abbrevated month and day names. > > Months: Sau, Vas, Kov, Bal, Geg, Bir, Lie, Rgp, Rgs, Spl, Lap, Grd > Days (starting Monday): Pr, An, Tr, Kt, Pn, Åt, Sk > > A reliable online reference of Lithuanian POSIX locale can be found > here: http://www.likit.lt/all/stand/lokale/lokale.htm#p1 > > I also noticed a few mistakes in CLDR document. > > The short date format is wrong. Hyphens should be used instead of dots. > For example, 2005-02-21. Spaces are also allowed, but hyphens are > recommended. > > Also Lithuanian name for Czech language should be "ÄekÅ", not "Äekijos". > > > Thanks, > Modestas > > > - > 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
Hi Jesús, On Mon, Feb 21, 2005 at 19:39:24 +0100, Eike Rathke wrote: > > >the example differs from OpenOffice, which is correct "aC" and "dC" or > > >"A.C" and "D.C" ? > > > > The correct ones are "aC" and "dC". > > Just stumbled over it while I wanted to fix it: this was about the > abbreviated era names. What are the full era names, which currently are > also "A.C." and "D.C."? If there is no update on this, I'll just correct the abbreviations. See http://qa.openoffice.org/issues/show_bug.cgi?id=43267 Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
Hi Jesús, On Fri, Feb 25, 2005 at 18:09:23 +0100, Eike Rathke wrote: > Hi Jesús, > > On Mon, Feb 21, 2005 at 19:39:24 +0100, Eike Rathke wrote: > > > > >the example differs from OpenOffice, which is correct "aC" and "dC" or > > > >"A.C" and "D.C" ? > > > > > > The correct ones are "aC" and "dC". > > > > Just stumbled over it while I wanted to fix it: this was about the > > abbreviated era names. What are the full era names, which currently are > > also "A.C." and "D.C."? > > If there is no update on this, I'll just correct the abbreviations. See > http://qa.openoffice.org/issues/show_bug.cgi?id=43267 Any news on this? Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit
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 used "stand-alone" as opposed to "embedded" in a string ? Normally this is the case for slavic languages. 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=0&c=31&a=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
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? > 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=0&c=31&a=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 -- Hristo Simeonov Hristov Leader of OpenOffice.org Bulgarian - 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=0&c=31&a=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
On Friday 04 March 2005 11:47, Peter Nugent wrote: > > sure : if we take the example of the abbreviated form of the 3rd mont. > > 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" = "марта" I see. Well, Bulgarian is not an inflected language. So, the names of months are allways the same. > other slavic languages are similar. > So i was wondering if your date is "stand-alone" or "embedded" or is > there a distinction in Bulgarian ? > -- Hristo Simeonov Hristov Leader of OpenOffice.org Bulgarian pgp93NhabJoXx.pgp Description: PGP signature
[l10n-dev] Locale data audit for af_ZA
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 SpelreeÃls), 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? -- Dwayne Bailey <[EMAIL PROTECTED]> Translate.org.za +27-12-460-1095 (w) +27-83-443-7114 (cell) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] locale data audit for Lao
Hi Eike, First of all, thanks for your note. I have looked at this for Lao and here is my report: 719 and 720 need to ALIGN with Common. 721 is in CORRECT form and should stay as it is for OOo. 722 should be ALIGNED with Common. Cheers, Anousak Lao OOo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale data audit for af_ZA
On Sun, 2005-04-03 at 19:15 +0200, Dwayne Bailey wrote: > 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 SpelreeÃls), sorry no online version. Patch is here: http://qa.openoffice.org/issues/show_bug.cgi?id=46568 It also contains some updates for issues not specifically listed on the audit page. > 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? > -- Dwayne Bailey <[EMAIL PROTECTED]> Translate.org.za +27-12-460-1095 (w) +27-83-443-7114 (cell) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale data audit for af_ZA
Hi Dwayne, On Mon, Apr 04, 2005 at 08:53:06 +0200, Dwayne Bailey wrote: > Patch is here: > http://qa.openoffice.org/issues/show_bug.cgi?id=46568 Thanks, I grabbed it. Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale data audit for af_ZA
Hi Dwayne, On Sun, Apr 03, 2005 at 19:15:20 +0200, Dwayne Bailey wrote: > Sorry I'm only getting to this now :( Better late than never ;-) > 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? No, there isn't. However, there will be a more or less easy way to convert from CLDR to OOo locale data, Peter Nugent prepared it and I'll work with it this week. So if the locales are present in CLDR we could pull the basic data from there, OOo specific data like number formats and so on will always have to be added separately. > Should I just add these new locales as issues? We need complete locale data anyway, so having just the issue without the data wouldn't be of help. Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - 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 SpelreeÃls), 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 SpelreeÃls), 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 Peter, On Tue, 2005-04-05 at 16:48 +0100, Peter Nugent wrote: > 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 ? We have a rather odd issue here in South Africa. I alluded to it in another email to this list today. 1) The official number representation is that which is listed currently in the CLDR. ie space and comma. You will find most newspaper text in that format. 2) However, it causes much frustration for computer users who are, for whatever reason good or bad, used to number entry with the decimal point. There are already a number of bug reports related to this problem. On top of that all other languages in South Africa use the comma; decimal point notation. I'd love to be able to resolve this without having to make a decision :) > 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 SpelreeÃls), 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? > >> > > > > > -- Dwayne Bailey <[EMAIL PROTECTED]> Translate.org.za +27-12-460-1095 (w) +27-83-443-7114 (cell) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale data audit for af_ZA
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 SpelreeÃls), 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? > > > -- Dwayne Bailey <[EMAIL PROTECTED]> Translate.org.za +27-12-460-1095 (w) +27-83-443-7114 (cell) - 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 SpelreeÃls), 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
On Wed, 2005-04-06 at 12:51 +0100, Peter Nugent wrote: > Dwayne > I can do the conversion if you can provide fully resolved glibc files > (i.e. no "copy" directives). Thank you! I will send these privately. > However, you will still only have partial > information as there is a lot of OO specific data which is not in glibc > or CLDR Fortunately we inherit most of this from en_ZA -- Dwayne Bailey <[EMAIL PROTECTED]> Translate.org.za +27-12-460-1095 (w) +27-83-443-7114 (cell) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] Locale Data Audit: CWS localedata4 reflected
Hi, I updated http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html to correspond to the work done in CWS localedata4, which isn't integrated yet. See also http://eis.services.openoffice.org/EIS2/servlet/cws.ShowCWS?Id=2395&Path=SRC680%2Flocaledata4 Some green, and many TODOs. Would be nice if someone could take care of the "TODO: file CLDR bug" for several locales to relieve me of some burden. Attached is the current status as an outlined todo list. Thanks Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD [_] 29% done of ToDo-List of Locale Data Alignment OOo with CLDR : corresponds with : http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html : : : Main players, "Big10" + pt_BR, alignment to CLDR targeted to OOo2.0.1 : : en [_] en_BZ (TODO: clarify) [_] en_CA (TODO: clarify) [_] en_GB (TODO: clarify) [_] en_IE (TODO: clarify) [_] en_PH (TODO: file CLDR bug) : de [_] de_AT (TODO: clarify) [_] de_CH (TODO: hold it) [_] de_LI (TODO: hold it) : fr [_] fr_BE (TODO: clarify) [_] 0% fr_CA [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP [_] fr_CH (TODO: hold it) [_] 0% fr_FR [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP [_] fr_LU (TODO: clarify) [_] 0% fr_MC [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP : es [_] es_UY (CLDR Bug 580) [_] es_BO (TODO: clarify) [_] es_CL (TODO: clarify) [_] es_CO (TODO: clarify) [_] es_CR (TODO: file CLDR bug) [_] es_DO (TODO: file CLDR bug) [_] es_EC (TODO: clarify; file CLDR bug) [_] es_ES (TODO: clarify) [_] es_GT (TODO: file CLDR bug) [_] es_HN (TODO: file CLDR bug) [_] es_MX (TODO: file CLDR bug) [_] es_NI (TODO: file CLDR bug) [_] es_PA (TODO: file CLDR bug) [_] es_PE (TODO: clarify; file CLDR bug) [_] es_PR (TODO: file CLDR bug) [_] es_PY (TODO: file CLDR bug) [_] es_SV (TODO: file CLDR bug) [_] es_UY (TODO: clarify; file CLDR bug) : it [_] it_CH (TODO: hold it) [_] it_IT (TODO: clarify) : sv [_] 0% sv_FI [_] (TODO: clarify; file CLDR bug) [_] ThousandSeparator: change space to NBSP [_] 0% sv_SE [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP : ja [_] 0% ja_JPRED! not automatically alignable, only partial manual update [_] (TODO: align some items to CLDR) [_] (TODO: clarify) : : ko [_] 0% ko_KRRED! not automatically alignable, only partial manual update [_] (TODO: align some items to CLDR) [_] (TODO: clarify) : : zh [_] zh_CN (TODO: clarify) [_] zh_HK (TODO: clarify) [_] zh_MO (TODO: clarify) [_] zh_SG (TODO: clarify) [_] zh_TW (TODO: clarify) : pt_BR [_] pt_BR (TODO: clarify) : : : Additional players, alignment to CCLDR targeted to OOo2.0.1 : : nl [_] nl_NL (CLDR Bug 458) [_] nl_BE (TODO: clarify) : ru [_] 0% ru_RU [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP : pl [_] 0% pl_PL [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP : tr [_] tr_TR align to CLDR : hu [_] 0% hu_HU [_] (CLDR Bug 463) [_] (TODO: file CLDR bug) [_] ThousandSeparator: change space to NBSP : : th [_] th_TH (TODO: clarify) : : : Bugs in CLDR preventing alignment [_] az_AZ (CLDR Bug 402) [_] mn_MN (CLDR Bug 403) [_] bg_BG (CLDR Bug 459) [_] km_KH (CLDR Bug 460) [_] et_EE (CLDR Bug 462) [_] nb_NO (CLDR Bug 464) [_] nn_NO (CLDR Bug 464) [_] sl_SI (CLDR Bug 465) [_] ca_ES (CLDR Bug 494) [_] sw_TZ (CLDR Bug 498) [_] lt_LT (CLDR Bug 573) :
Re: [l10n-dev] locale data audit for Lao
Hi Anousak, On Fri, Aug 19, 2005 at 09:24:40 +0700, ? Anousak Souphavanh wrote: > First of all, thanks for your note. I have looked at this for Lao and here is > my report: Thank you for reporting. > 721 is in CORRECT form and should stay as it is for OOo. Would you like to file a CLDR bug for this? For links and how-to please see the beginning of the audit docuument. Thanks Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit: CWS localedata4 reflected
--- Eike Rathke <[EMAIL PROTECTED]> wrote: > Hi, > > I updated > http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html > to correspond to the work done in CWS localedata4, > which isn't > integrated yet. See also > http://eis.services.openoffice.org/EIS2/servlet/cws.ShowCWS?Id=2395&Path=SRC680%2Flocaledata4 > > Some green, and many TODOs. Would be nice if someone > could take care of > the "TODO: file CLDR bug" for several locales to > relieve me of some > burden. I file bug for pa-IN locale at CLDR check NO 674 thanks alam > > Attached is the current status as an outlined todo > list. > > Thanks > Eike > > -- > OOo/SO Calc core developer. Number formatter > bedevilled I18N transpositionizer. > GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 > 9E96 2F1A D073 293C 05FD > > [_] 29% done of ToDo-List of Locale Data Alignment > OOo with CLDR > : corresponds with > : > http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html > : > : > : Main players, "Big10" + pt_BR, alignment to CLDR > targeted to OOo2.0.1 > : > : en > [_] en_BZ (TODO: clarify) > [_] en_CA (TODO: clarify) > [_] en_GB (TODO: clarify) > [_] en_IE (TODO: clarify) > [_] en_PH (TODO: file CLDR bug) > : de > [_] de_AT (TODO: clarify) > [_] de_CH (TODO: hold it) > [_] de_LI (TODO: hold it) > : fr > [_] fr_BE (TODO: clarify) > [_] 0% fr_CA > [_] (TODO: clarify) > [_] ThousandSeparator: change space to NBSP > [_] fr_CH (TODO: hold it) > [_] 0% fr_FR > [_] (TODO: clarify) > [_] ThousandSeparator: change space to NBSP > [_] fr_LU (TODO: clarify) > [_] 0% fr_MC > [_] (TODO: clarify) > [_] ThousandSeparator: change space to NBSP > : es > [_] es_UY (CLDR Bug 580) > [_] es_BO (TODO: clarify) > [_] es_CL (TODO: clarify) > [_] es_CO (TODO: clarify) > [_] es_CR (TODO: file CLDR bug) > [_] es_DO (TODO: file CLDR bug) > [_] es_EC (TODO: clarify; file CLDR bug) > [_] es_ES (TODO: clarify) > [_] es_GT (TODO: file CLDR bug) > [_] es_HN (TODO: file CLDR bug) > [_] es_MX (TODO: file CLDR bug) > [_] es_NI (TODO: file CLDR bug) > [_] es_PA (TODO: file CLDR bug) > [_] es_PE (TODO: clarify; file CLDR bug) > [_] es_PR (TODO: file CLDR bug) > [_] es_PY (TODO: file CLDR bug) > [_] es_SV (TODO: file CLDR bug) > [_] es_UY (TODO: clarify; file CLDR bug) > : it > [_] it_CH (TODO: hold it) > [_] it_IT (TODO: clarify) > : sv > [_] 0% sv_FI > [_] (TODO: clarify; file CLDR bug) > [_] ThousandSeparator: change space to NBSP > [_] 0% sv_SE > [_] (TODO: clarify) > [_] ThousandSeparator: change space to NBSP > : ja > [_] 0% ja_JPRED! not automatically alignable, only > partial manual update > [_] (TODO: align some items to CLDR) > [_] (TODO: clarify) > : > : ko > [_] 0% ko_KRRED! not automatically alignable, only > partial manual update > [_] (TODO: align some items to CLDR) > [_] (TODO: clarify) > : > : zh > [_] zh_CN (TODO: clarify) > [_] zh_HK (TODO: clarify) > [_] zh_MO (TODO: clarify) > [_] zh_SG (TODO: clarify) > [_] zh_TW (TODO: clarify) > : pt_BR > [_] pt_BR (TODO: clarify) > : > : > : Additional players, alignment to CCLDR targeted > to OOo2.0.1 > : > : nl > [_] nl_NL (CLDR Bug 458) > [_] nl_BE (TODO: clarify) > : ru > [_] 0% ru_RU > [_] (TODO: clarify) > [_] ThousandSeparator: change space to NBSP > : pl > [_] 0% pl_PL > [_] (TODO: clarify) > [_] ThousandSeparator: change space to NBSP > : tr > [_] tr_TR align to CLDR > : hu > [_] 0% hu_HU > [_] (CLDR Bug 463) > [_] (TODO: file CLDR bug) > [_] ThousandSeparator: change space to NBSP > : > : th > [_] th_TH (TODO: clarify) > : > : > : Bugs in CLDR preventing alignment > [_] az_AZ (CLDR Bug 402) > [_] mn_MN (CLDR Bug 403) > [_] bg_BG (CLDR Bug 459) > [_] km_KH (CLDR Bug 460) > [_] et_EE (CLDR Bug 462) > [_] nb_NO (CLDR Bug 464) > [_] nn_NO (CLDR
Re: [l10n-dev] Locale Data Audit: CWS localedata4 reflected
Hi Eike just saw this. conflicts 224 (GRD symbol) and 1338 (UAH symbol) are due to a bug in the comparison tool , CLDR and OO are actually aligned on this data. Can you update webpage. For issues 264 (es_EC currency symbol) and 286 (es_NI symbol) there's already a CLDR bug (399) I''ll take a look at the other issues later... 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, I updated http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html to correspond to the work done in CWS localedata4, which isn't integrated yet. See also http://eis.services.openoffice.org/EIS2/servlet/cws.ShowCWS?Id=2395&Path=SRC680%2Flocaledata4 Some green, and many TODOs. Would be nice if someone could take care of the "TODO: file CLDR bug" for several locales to relieve me of some burden. Attached is the current status as an outlined todo list. Thanks Eike [_] 29% done of ToDo-List of Locale Data Alignment OOo with CLDR : corresponds with : http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html : : : Main players, "Big10" + pt_BR, alignment to CLDR targeted to OOo2.0.1 : : en [_] en_BZ (TODO: clarify) [_] en_CA (TODO: clarify) [_] en_GB (TODO: clarify) [_] en_IE (TODO: clarify) [_] en_PH (TODO: file CLDR bug) : de [_] de_AT (TODO: clarify) [_] de_CH (TODO: hold it) [_] de_LI (TODO: hold it) : fr [_] fr_BE (TODO: clarify) [_] 0% fr_CA [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP [_] fr_CH (TODO: hold it) [_] 0% fr_FR [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP [_] fr_LU (TODO: clarify) [_] 0% fr_MC [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP : es [_] es_UY (CLDR Bug 580) [_] es_BO (TODO: clarify) [_] es_CL (TODO: clarify) [_] es_CO (TODO: clarify) [_] es_CR (TODO: file CLDR bug) [_] es_DO (TODO: file CLDR bug) [_] es_EC (TODO: clarify; file CLDR bug) [_] es_ES (TODO: clarify) [_] es_GT (TODO: file CLDR bug) [_] es_HN (TODO: file CLDR bug) [_] es_MX (TODO: file CLDR bug) [_] es_NI (TODO: file CLDR bug) [_] es_PA (TODO: file CLDR bug) [_] es_PE (TODO: clarify; file CLDR bug) [_] es_PR (TODO: file CLDR bug) [_] es_PY (TODO: file CLDR bug) [_] es_SV (TODO: file CLDR bug) [_] es_UY (TODO: clarify; file CLDR bug) : it [_] it_CH (TODO: hold it) [_] it_IT (TODO: clarify) : sv [_] 0% sv_FI [_] (TODO: clarify; file CLDR bug) [_] ThousandSeparator: change space to NBSP [_] 0% sv_SE [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP : ja [_] 0% ja_JPRED! not automatically alignable, only partial manual update [_] (TODO: align some items to CLDR) [_] (TODO: clarify) : : ko [_] 0% ko_KRRED! not automatically alignable, only partial manual update [_] (TODO: align some items to CLDR) [_] (TODO: clarify) : : zh [_] zh_CN (TODO: clarify) [_] zh_HK (TODO: clarify) [_] zh_MO (TODO: clarify) [_] zh_SG (TODO: clarify) [_] zh_TW (TODO: clarify) : pt_BR [_] pt_BR (TODO: clarify) : : : Additional players, alignment to CCLDR targeted to OOo2.0.1 : : nl [_] nl_NL (CLDR Bug 458) [_] nl_BE (TODO: clarify) : ru [_] 0% ru_RU [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP : pl [_] 0% pl_PL [_] (TODO: clarify) [_] ThousandSeparator: change space to NBSP : tr [_] tr_TR align to CLDR : hu [_] 0% hu_HU [_] (CLDR Bug 463) [_] (TODO: file CLDR bug) [_] ThousandSeparator: change space to NBSP : : th [_] th_TH (TODO: clarify) : : : Bugs in CLDR preventing alignment
Re: [l10n-dev] Locale Data Audit: CWS localedata4 reflected
Hi Amanpreet, On Tue, Apr 26, 2005 at 07:10:21 -0700, Amanpreet Singh Alam wrote: > I file bug for pa-IN locale at CLDR > > check NO 674 Thanks, I'll update the document. Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit: CWS localedata4 reflected
Hi Peter, On Wed, Apr 27, 2005 at 13:08:44 +0100, Peter Nugent wrote: > just saw this. conflicts 224 (GRD symbol) and 1338 (UAH symbol) are due > to a bug in the comparison tool , CLDR and OO are actually aligned on > this data. Can you update webpage. Done. Could this be also the case for 244, 286, 290, 299, 303, 511 and 1229? > For issues 264 (es_EC currency symbol) and 286 (es_NI symbol) there's > already a CLDR bug (399) Actually the es_NI symbol is 282, 286 is es_PA, which also seems to be wrong. Added CLDR bug# to the audit document. I also left a comment in that bug about USD in es_EC. Thanks Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit: CWS localedata4 reflected
Hi Eike see below Peter Eike Rathke ha scritto: Hi Peter, On Wed, Apr 27, 2005 at 13:08:44 +0100, Peter Nugent wrote: just saw this. conflicts 224 (GRD symbol) and 1338 (UAH symbol) are due to a bug in the comparison tool , CLDR and OO are actually aligned on this data. Can you update webpage. Done. Could this be also the case for 244, 286, 290, 299, 303, 511 and 1229? No it's not a comparison tool bug. This is what CLDR is saying about these currencies. I'll file a bug on these in CLDR For issues 264 (es_EC currency symbol) and 286 (es_NI symbol) there's already a CLDR bug (399) Actually the es_NI symbol is 282, 286 is es_PA, which also seems to be wrong. Added CLDR bug# to the audit document. I also left a comment in that bug about USD in es_EC. yes, this is also what CLDR says, here's the relevant extract from CLDR's supplemenmtalData.xml : so the default is USD Thanks Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] Locale Data Audit: Fix symbol of old Greek currency
Dear All, At http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html#224 it shows that the symbol for the Greek currency is "GRD" (GReek Drachma). The current currency unit used in the Greece is the Euro. While investigating other locales, I notice that here the old symbol is used and there is a comment saying that a mechanism to detect the currency should be implemented. For example, http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html#269 http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html#589 Therefore, if the currency.symbol should show the current currency symbol, please change to "*€" (*U+20AC), if the currency.symbol should show the previous currency symbol, please change to "₯" (U+20AF). Cheers, Simos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit: Fix symbol of old Greek currency
Hi Simos, On Thu, Dec 15, 2005 at 01:12:51 +, Simos Xenitellis wrote: > At > http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html#224 > it shows that the symbol for the Greek currency is "GRD" (GReek Drachma). > > The current currency unit used in the Greece is the Euro. May be a bit confusing, but the document lists only the differences between OOo and CLDR locale data. Both also contain data for the Euro currency, whhere the symbol is identical and therefor isn't mentioned at all. Only the symbol data for the old Drachma currency differs in that position. Respectively in this case it didn't even differ but the comparison tool had a bug, which is also stated in the Solution field. > While investigating other locales, I notice that here the old symbol is > used and there is a comment saying that a mechanism to detect the > currency should be implemented. > For example, > http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html#269 > http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html#589 Same here, only the old currency symbol differs but Euro symbol is identical. So no issue with that, but thanks for investigating :-) Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[l10n-dev] Locale Data Audit - new process to submit corrections to CLDR
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. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - 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
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]
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
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. Shall I point anyone interested to you to have an account created? Does the registration form at Unicode.org work to help create a CLDR submitter ID work? 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]
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] 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]
[l10n-dev] Locale Data Audit #217 ("greorgian week min days" for de_AT) - align to CLDR
Hi *, I'm not subscribed, so please cc me. ToDo-item http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html#217 OOo lists greorgian_week min days 1 CLDR lists greorgian_week min days 4 CLDR is right, OOo is wrong. Argumentation: ISO 8601 defines the Min-days to 4 and ISO 8601 has been integrated into Euronorm EN 28601 which in turn is adapted to several national norms. for germany this is "DIN EN 28601", for austria this is "OENORM EN 28601" Links: The ISO-Norm in "plain english" - english http://www.cl.cam.ac.uk/~mgk25/iso-time.html http://en.wikipedia.org/wiki/ISO_8601#Week_dates links that clearly states what is included in the EN (including the week-regulation) - in german http://de.wikipedia.org/wiki/Datumsformat http://monitor.co.at/index.cfm?storyid=1936 link listing the corresponding national norms for ISO 8601 - in german http://www.ie.iwi.unibe.ch/services/initiativen/iso8601.php a similar listing - in english http://www.qsl.net/g1smd/isoimp.htm link demonstrating that the regulation is in use (2005-03-21 to 2005-03-27 is week 12, not week 13 as it would be the case with min-days=1) - in german http://www.influenza.at/daten/daten0405/influenza_saison04-05.htm ciao Chritsian -- NP: Jimi Hendrix - If 6 Was 9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit #217 ("greorgian week min days" for de_AT) - align to CLDR
Hi Christian, On Fri, Jul 29, 2005 at 15:29:16 +0200, Christian Lohmaier wrote: > I'm not subscribed, so please cc me. Done. Reply-To list set. > ToDo-item > http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html#217 > > OOo lists greorgian_week min days 1 > CLDR lists greorgian_week min days 4 > > CLDR is right, OOo is wrong. This will go into the CLDR alignment round for OOo2.0.1 then. Thanks for reporting! Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit #217 ("greorgian week min days" for de_AT) - align to CLDR
Hi *, On Fri, Jul 29, 2005 at 08:35:34PM +0200, Eike Rathke wrote: > On Fri, Jul 29, 2005 at 15:29:16 +0200, Christian Lohmaier wrote: > > > I'm not subscribed, so please cc me. > > Done. Reply-To list set. Wow, that's service :-) > > ToDo-item > > http://l10n.openoffice.org/i18n_framework/cldr/LocaleDataAudit_OOo_CLDR.html#217 > > > > OOo lists greorgian_week min days 1 > > CLDR lists greorgian_week min days 4 > > > > CLDR is right, OOo is wrong. > > This will go into the CLDR alignment round for OOo2.0.1 then. Thanks :-) ciao Christian PS: There are a couple of locales for which OOo lists 1, CLDR lists 4. At least for the european countries CLDR should be right.. Just compare with the "list of implementors" http://www.qsl.net/g1smd/isoimp.htm en_CA, fr_CA the following have adapted the euronorm fr_BE, nl_BE fr_FR fr_LU sv_SE -- NP: Metallica - Wasting My Hate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] Locale Data Audit #217 ("greorgian week min days" for de_AT) - align to CLDR
Hi Christian, On Sat, Jul 30, 2005 at 19:17:47 +0200, Christian Lohmaier wrote: > PS: There are a couple of locales for which OOo lists 1, CLDR lists 4. > At least for the european countries CLDR should be right.. I'm assuming this too. > Just compare with the "list of implementors" > http://www.qsl.net/g1smd/isoimp.htm Yep, thanks for pointing this out again, it slipped my attention that also the week-of-year counting is defined by ISO-8601. Eike -- OOo/SO Calc core developer. Number formatter bedevilled I18N transpositionizer. GnuPG key 0x293C05FD: 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
