Re: [l10n-dev] NEW Locale Data Audit - please participate!
Hi Samphan, On Wed, Mar 01, 2006 at 18:49:24 +0700, Samphan Raruenrom wrote: I've used CLDR Survey Tool to enter the data. Is this OK? Or should I file a bug? No, everything fine, the survey tool is the new way of submitting data and changes to the CLDR. When I started the audit the tool wasn't ready, but now it is. Thanks! 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] NEW Locale Data Audit - please participate!
I've used CLDR Survey Tool to enter the data. Is this OK? Or should I file a bug? Eike Rathke wrote: Hi Samphan, On Wed, Feb 01, 2006 at 08:17:22 +0700, Samphan Raruenrom wrote: OK. I have consulted this issue with other Thai developers. We all agree that almost all of the data in OOo is right. Only CurrencyID discussed below has to be changed to 'THB'. For other entries, CLDR should be aligned to OOo locale. Fine. Would you mind filing a bug against the CLDR and when done reporting its number back here? See pointers in the audit document. What made me wonder though is, that OOo's TimeAM and TimePM are said to be AM/PM and not some localized expressions as listed by the CLDR. Eike -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [l10n-dev] NEW Locale Data Audit - please participate!
From: Eike Rathke, Thanks, I added that to the audit document and hope my editor didn't introduce any errors when copying the utf-8 characters. Would you mind filing a bug against the CLDR for those items that now have a TODO in the gu_IN audit? Please see the audit document for pointers, and when done please report the bugID back here. Thanks Eike Hi Eike, Thanks a lot. I have filled a bug #969 against CLDR data. Please check and comment of anything is wrong. Regards, -- ,_ , Kartik Mistry kart_ (O,O) GNU/Linux Developer ( ) http://kartikm.blogspot.com - -GPG Key : 0xD1028C8D
Re: [l10n-dev] NEW Locale Data Audit - please participate!
Hi Tomislav, On Thu, Feb 09, 2006 at 14:27:03 +0100, Tomislav Randjic wrote: I will add EUR to the used currencies for *_CS, just that it opens the question which would be the default. CLDR lists EUR as default. Is that correct? For now, default for sr_CS should be CSD, and EUR should be there also to overcome current situation with Euro in Montenegro. Please allow me one question: is that a voice from Serbia, or a voice from Montenegro? 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] NEW Locale Data Audit - please participate!
Hi Eike, Today at 18:39, Eike Rathke wrote: On Thu, Feb 09, 2006 at 14:27:03 +0100, Tomislav Randjic wrote: I will add EUR to the used currencies for *_CS, just that it opens the question which would be the default. CLDR lists EUR as default. Is that correct? Nope, CSD is correct, read below for some elaboration. For now, default for sr_CS should be CSD, and EUR should be there also to overcome current situation with Euro in Montenegro. Please allow me one question: is that a voice from Serbia, or a voice from Montenegro? You can count it as voice from people: at least 90% of population of Serbia and Montenegro lives in Serbia-proper (not counting Kosovo in, it's 8 million vs 0.8 million [and note that it's probably more than 8 million, and less than 0.8 million, so I am not being gentle on Serbia, but rather vice versa]). Generally, it's politically a very sensitive question, and you avoid most of the fuss by setting CSD as default currency (there's more: Kosovo with 1.2+M is nowadays probably using EUR as well, even if it's part of Serbia [or isn't, I am not going into political discussion here]). Note that also some day names would be spelled out differently in Montenegro (eg. for Wednesday: сриједа instead of среда, or in Latin transcription srijeda instead of sreda), so generally, sr_CS is a locale more suitable for Serbia part of the union. That's why I designed a [EMAIL PROTECTED] locale for GNU libc (which is usable in both Montenegro and Bosnia [in Serbian areas]), basically for Jekavian dialect as used in Balkans, yet it never garnered enough interest (the number of people that might use it is really small). Note that each dialect is as much Serbian as the other, so if we bring this into discussion, we'll never achieve anything: the voice from Serbia is going to be more useful to a MAJORITY of people, and that should be the only criteria. Cheers, Danilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] NEW Locale Data Audit - please participate!
Hi Danilo, On Sat, Feb 04, 2006 at 01:30:51 +0100, Danilo �?egan wrote: 318 LC_CTYPETimeAM Yes, uppercase AM/PM is as good as am/pm. Good, another one sorted out. I assume this is the same for Serbian Latin script then. 326 CurrencyCurrencySymbol TODO: file CLDR bug Agreed. I am not really familiar with how that goes, but I've seen another post from Peter Nugent on how to report any omissions for the upcoming CLDR 1.4, so I'll check that one. Ah, yes, CLDR started the vetting for 1.4 Another thing: I know the confusing fact that, although being a state union, Montenegro severed its economy from Serbia, and while Serbia uses the Serbian Dinar (CSD) as currency, Montenegro uses the Euro (EUR). I will add EUR to the used currencies for *_CS, just that it opens the question which would be the default. CLDR lists EUR as default. Is that correct? Thanks 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] NEW Locale Data Audit - please participate!
Hi Kartik, On Fri, Feb 03, 2006 at 21:24:05 +0530, Kartik Mistry wrote: Here is what I have missed! Thanks, I added that to the audit document and hope my editor didn't introduce any errors when copying the utf-8 characters. StartDayOfWeek - mon should be સોમ which is similar to CLDR day of Monday. Note that there in item #964 it is an ID, not to be localized, so 'mon' would be correct. This changes will make Gujarati Perfet in OO.o! Would you mind filing a bug against the CLDR for those items that now have a TODO in the gu_IN audit? Please see the audit document for pointers, and when done please report the bugID back here. Thanks 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] NEW Locale Data Audit - please participate!
Hi Samphan, On Wed, Feb 01, 2006 at 08:17:22 +0700, Samphan Raruenrom wrote: OK. I have consulted this issue with other Thai developers. We all agree that almost all of the data in OOo is right. Only CurrencyID discussed below has to be changed to 'THB'. For other entries, CLDR should be aligned to OOo locale. Fine. Would you mind filing a bug against the CLDR and when done reporting its number back here? See pointers in the audit document. What made me wonder though is, that OOo's TimeAM and TimePM are said to be AM/PM and not some localized expressions as listed by the CLDR. 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] NEW Locale Data Audit - please participate!
Hi Yury, On Tue, Jan 31, 2006 at 11:57:50 +0200, Yury Tarasievich wrote: It is safe. Just what do people expect if, for example, they have a Calc value cell and click the currency format icon? Do they want to see some sort of symbol or abbreviation, even if more than one charater or glyph, or the ISO code? If not seeing there one of the traditional symbols, they'd expect to see something comprehensible. Let's leave ISO code there, then. Ok, will align to CLDR then. Tarrifs are something different, in telephone calls we can have a tarrif of 0.0099 Euro per minute, but the smallest coin is 0.01 Euro (== 1 Cent) so decimals are 2. What is the smallest amount of money you can have in your pocket? Okay, 0 decimal places, then. Will align also that. Thanks 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] NEW Locale Data Audit - please participate!
OK. I have consulted this issue with other Thai developers. We all agree that almost all of the data in OOo is right. Only CurrencyID discussed below has to be changed to 'THB'. For other entries, CLDR should be aligned to OOo locale. Eike Rathke wrote: Hi Samphan, On Thu, Jan 26, 2006 at 08:27:53 +0700, Samphan Raruenrom wrote: What should be used for CurrencyID? http://l10n.openoffice.org/nonav/i18n_framework/cldr/LocaleDataAudit_OOo202.html#219 I see inconsistencies between locales. - bank symbol - currency symbol - translated currency name - currency name in English I see all cases in the OOo locale. Should we have a standard? Yes ;-) it's simple: - CurrencyID should be the ISO 4217 code, the element is currently not used in OOo, but may in future for a real ID, instead of BankSymbol that currently serves that purpose. Currently the content is a wild mixture of names, symbols and IDs, I'll adjust that in all locale data over time. - BankSymbol is the ISO 4217 code as well, that one is used for display purposes for example in bank exchange. In future it _might_ differ from ISO 4217, but I doubt it will. - CurrencySymbol is the display symbol used with amounts. - CurrencyName is the name the currency is called in the native language. -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [l10n-dev] NEW Locale Data Audit - please participate!
Hi dwb, On Mon, Jan 30, 2006 at 14:51:09 +, dwb wrote: I didn't seriously think my suggestion would fly! :-O Glad to see you give in ;-) So, on behalf of the British I hereby declare that the first day of the week for en-GB is Monday, as stated in BS EN 28601:1992. Accepted. Should I file an issue to align OOo with the CLDR? No, not necessary. I'll file a collective issue for all those small bits that will arrive over time and just align them according to the findings. For now I'll just record it in the audit document. Thanks 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] NEW Locale Data Audit - please participate!
Hi Yury, On Sat, Jan 28, 2006 at 11:53:34 +0200, Yury Tarasievich wrote: #1387 CurrencySymbol // BYR руб. or бел.руб. ... The string length doesn't matter technically, it should be a choice of usage if there is no national standard. I guess few people write long terms for the currency symbol when pricing goods, for example. Don't know though how the CLDR regards this. Maybe because as long as there is no standard they use the ISO code instead. In fact, I think such record is of almost no meaning outside the several countries where such cultural artifacts exist traditionally. Abbreviation doesn't equal symbol, after all. Perhaps, we should leave ISO code there? Safe choice? It is safe. Just what do people expect if, for example, they have a Calc value cell and click the currency format icon? Do they want to see some sort of symbol or abbreviation, even if more than one charater or glyph, or the ISO code? Otherwise, I think the primary setting should be бел.nbsp;руб., to avoid ambiguity. Ambiguity to what? My Cyrillic parser is broken ;-) Note that it is fine to have identical symbols for different currencies of different countries. For example, the $ symbol is not only used for USD. You don't have to make up symbols just to prevent ambiguity. What about #1395, decimal places of the currency? CLDR states that there are only integer amounts, OOo includes 2 decimals. Well, trivial currency data here doesn't include decimal places, indeed. OTOH, decimal places (kopecks) are still fairly commonly used, e.g., in tariffs. Tarrifs are something different, in telephone calls we can have a tarrif of 0.0099 Euro per minute, but the smallest coin is 0.01 Euro (== 1 Cent) so decimals are 2. What is the smallest amount of money you can have in your pocket? Bit of over-eagerness on part of CLDR here? CLDR tries to be as correct as possible. It's the only way to go when you want to create a reference database. 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] NEW Locale Data Audit - please participate!
Hi Yury, On Fri, Jan 27, 2006 at 12:38:53 +0200, Yury Tarasievich wrote: Done. CLDR bug #962 (audit issues #1378 and #1379). Thank you. 3. gregorian:MonthsOfYear.Month.MonthID // may Formally, both variants are permissible. Bit of ambiguity here. Let it be? If it really doesn't matter, I'd align to CLDR then. Well, I'd still say current ooo setting is marginally better, w/r to cultural tradition. It isn't too uncommon for CLDR to err somewhat in such matters, after all. If that is the case, then please add it to your CLDR bug report. Our goal isn't only to have correct OOo data, but also to get correct CLDR data. In future we want to be able to semi-automatically update OOo's locale data with CLDR content. Differences prevent us from doing so. To get changes in to the CLDR easier it helps to provide some evidence like official government websites or references to books. Even cultural tradition may be documented somewhere, for example in dissertations. If CLDR doesn't accept it, it was at least worth the try. If there aren't any official rules, I doubt there's justification to keep the old data. Btw, when reporting CLDR bugs it may be helpful to include an URL of the item as a pointer to our audit document, such as http://l10n.openoffice.org/nonav/i18n_framework/cldr/LocaleDataAudit_OOo202.html#1378 What about the other month name differences that seem to differ in capitalization? Also both permissible? ... 4. gregorian:DaysOfWeek.Day.DayID // tue Irrelevant, as there is no standard here on such abbreviations. Same here, capitalization differences of other day names? *All* capitalisation-only differences in be_BY section of this audit are just a matter of different presentations. Speaking *strictest*, Belarusian grammar doesn't regard names of days and months as proper nouns, so CLDR is possibly bit more correct here, disregarding that names are often capitalised in definitions like this, with no consideration for grammars' rules. Your decision, I think. I'll align that to CLDR then. I assume OOo's BYR CurrencySymbol р. instead of BYR is correct? Please include that in your CLDR bug report then. Well, after re-checking with CLDR tables and ooo locales, what ought to be here is (numbers of audit issues): #1383 CurrencyID // BYR BYR (as per ISO 4217 and per National Bank regulation) Already marked to be aligned. #1387 CurrencySymbol // BYR руб. or бел.руб. (there really is no such symbol at the moment, but the above abbreviations are the ones commonly used for that purpose. I have no idea whether these are acceptable w/r to string length, however. If not, then previous choice of р. would be acceptable, too.) The string length doesn't matter technically, it should be a choice of usage if there is no national standard. I guess few people write long terms for the currency symbol when pricing goods, for example. Don't know though how the CLDR regards this. Maybe because as long as there is no standard they use the ISO code instead. #1391 CurrencyName // BYR беларускі рубель (if name is to be in national language, then CLDR is right here) Also marked to be aligned. What about #1395, decimal places of the currency? CLDR states that there are only integer amounts, OOo includes 2 decimals. Thanks for the detailed answers. It seems that be_BY is quite a difficult locale.. 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] NEW Locale Data Audit - please participate!
Hi Rail, On Fri, Jan 27, 2006 at 02:03:56 +0300, Rail Aliev wrote: I filed an issue with patch. Thanks 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] NEW Locale Data Audit - please participate!
Hi dwb, On Fri, Jan 27, 2006 at 08:57:24 +, dwb wrote: Regarding en-GB (British English), and probably the same applies to en-IE, the only issue is over the first day of the week. I wrote to Dr Stockton at Surrey University - he has done research on the subject and can offer arguments and historical perspectives supporting both views. Nice :-/ There are some things in the UK for which, overall, we really do not use a standard, and this is one of them. Also: Certainly we have historically started the week on Sunday (unlike, it seems, the Creator who apparently chose Monday); Well, that just depends on the religion in use.. ;-) but the working week starts on Monday. which also derived from religion.. so not much helpful either. He cites BS EN 28601:1992 which is based on ISO 8601 first edition, which states that the first day of the week is Monday and adopts the ISO algorithm for week numbering. I think we can sort that out to be Monday. I have also written to the BSI, but have not had a response yet. From previous discussions I remember that the BSI defined it to be Monday, which apparently is the reason that CLDR lists Monday. Given that both Sunday and Monday appear to be in common usage, why don't we consider making the first day of the week user configurable within the options settings? We could then default to the ISO standard (Monday) and those who prefer Sunday could simply set their choice under options settings? That could be an option, but honestly, I strongly doubt that anyone would spend resources on it. Maybe the British should simply make up their mind ;-) 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] NEW Locale Data Audit - please participate!
On Wed, 25 Jan 2006 22:22:40 +0200, Eike Rathke [EMAIL PROTECTED] wrote: I created a new locale data audit document, 320kb http://l10n.openoffice.org/nonav/i18n_framework/cldr/LocaleDataAudit_OOo202.html that does a comparison between locale data as of OOo m151 and CLDR 1.3. For details and description please see the document. ... Mismatches for be_BY: 1. gregorian:Eras.Era.EraID // ad, bc Locale data is correct in this matter, and CLDR is incorrect. 2. LC_CTYPE // ThousandSeparator Non-breaking space is preferred, so CLDR is more correct in this. 3. gregorian:MonthsOfYear.Month.MonthID // may Formally, both variants are permissible. Bit of ambiguity here. Let it be? 4. gregorian:DaysOfWeek.Day.DayID // tue Irrelevant, as there is no standard here on such abbreviations. -regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [l10n-dev] NEW Locale Data Audit - please participate!
Hi Dwayne, On Thu, Jan 26, 2006 at 00:50:26 +0200, Dwayne Bailey wrote: Out of curiosity do you have a list of locales that are in Microsoft but not in OOo? No, but you may compare with http://msdn.microsoft.com/library/en-us/intl/nls_238z.asp I didn't check yet if that's complete though, they have several lists of LCIDs, you may find the most important ones at my developer's page http://www.erack.de/bookmarks/D.html#GIL_MS Note that one of them, Values as Assigned by Microsoft, also includes locales that are not supported by MS, but just have a value assigned. 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] NEW Locale Data Audit - please participate!
Hi Rail,
On Thu, Jan 26, 2006 at 17:00:16 +0300, Rail Aliev wrote:
127 az_AZ (Azerbaijani_Azerbaijan)
Currency name was changed after beginning of this year (denominated
1:5000). Old one is AZM and new one is AZN. AZM will be used till the end
of this year. So we need to have both in az_AZ.xml
Ok. Please file me ('er') an issue of type ENHANCEMENT for this and
include the following information:
- I assume the new currency uses 2 decimal places?
- What about the currency symbol, is it identical to the old one?
- The native name of the curreny.
I cannot find the right source describing these changes, but
http://www.nba.az (National Bank of Azerbaijan) shows AZN as main
currency symbol now.
Please file also a CLDR bug and inlude all information you have, see the
audit document for pointers. Please report back the CLDR bug ID when
done.
Thanks
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] NEW Locale Data Audit - please participate!
Hi, I created a new locale data audit document, 320kb http://l10n.openoffice.org/nonav/i18n_framework/cldr/LocaleDataAudit_OOo202.html that does a comparison between locale data as of OOo m151 and CLDR 1.3. For details and description please see the document. Again, I would like to ask as many people as possible to take a look at his/her locale whether s/he can spot and name a difference and tell which one is right. Please use the [EMAIL PROTECTED] mailing list to discuss your findings, or if you have any questions regarding the document. Thanks 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] NEW Locale Data Audit - please participate!
Hi Eike, 1413: This was reported under #645 to CLDR 1414: align to CLDR. LC_CURRENCY is inherited from en_ZA. en_ZA should also be corrected to have CurrencyName=Rand. So CurrencyName in both CLDR and OOo for en_ZA is incorrect. The other South African languages I assume are listed because there is no CLDR data? On Wed, 2006-01-25 at 21:22 +0100, Eike Rathke wrote: Hi, I created a new locale data audit document, 320kb http://l10n.openoffice.org/nonav/i18n_framework/cldr/LocaleDataAudit_OOo202.html that does a comparison between locale data as of OOo m151 and CLDR 1.3. For details and description please see the document. Again, I would like to ask as many people as possible to take a look at his/her locale whether s/he can spot and name a difference and tell which one is right. Please use the [EMAIL PROTECTED] mailing list to discuss your findings, or if you have any questions regarding the document. Thanks Eike -- Dwayne Bailey 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] NEW Locale Data Audit - please participate!
What should be used for CurrencyID? http://l10n.openoffice.org/nonav/i18n_framework/cldr/LocaleDataAudit_OOo202.html#219 I see inconsistencies between locales. - bank symbol - currency symbol - translated currency name - currency name in English I see all cases in the OOo locale. Should we have a standard? Eike Rathke wrote: I created a new locale data audit document, 320kb http://l10n.openoffice.org/nonav/i18n_framework/cldr/LocaleDataAudit_OOo202.html that does a comparison between locale data as of OOo m151 and CLDR 1.3. For details and description please see the document. Again, I would like to ask as many people as possible to take a look at his/her locale whether s/he can spot and name a difference and tell which one is right. Please use the [EMAIL PROTECTED] mailing list to discuss your findings, or if you have any questions regarding the document. -- _/|\_ Samphan Raruenrom. Open Source Development Co., Ltd. Tel: +66 38 311816, Fax: +66 38 773128, http://www.osdev.co.th/ smime.p7s Description: S/MIME Cryptographic Signature
