Hi Danilo, On Tue, Aug 02, 2005 at 08:29:58 +0200, Danilo ??egan wrote:
> How come nobody noticed such "short-sightedness" Many people did, and also urged the ISO maintenance agency to reconsider, even during the process before the final decision was made. Do a research on the net. > (I agree it sucks, but look at how ISO 3166 was defined ages ago) No reason for bad practice in presence. > [... pre-1991 "YU" and 1991-2003 "YU" differences deleted ...] > > All applications now need to cope with another such change, and it's > even simpler in practice, since the timeframe between the change is > some 12 years (pre-1990 "CS" and 2003-now "CS"). Still, since a simple "CS" you encounter doesn't say which year it originated from, there is no clean way to differentiate between those two. You could only _assume_ that the data is not older than 15 years.. may be valid for an office application, but not for mainframe database applications where data can be much older. > Of course, nobody bothered with the former change, because nobody > seemed to care, but suddenly it's important for those data > applications? It's all hipocrisy to me. Software evolved much, especially in the last 10-15 years. Some years ago there weren't many applications that were internationalized to at least some degree. Only a few could handle data from different regional origin, and even fewer did it by using ISO-3166-1 alpha-2 codes, some did by using ISO-3166-1 numeric-3 codes that developed later (interestingly in this case the number was reassigned, previously 891 was Yugoslavia and now is Serbia and Montenegro). International data use spread much faster with general public access to the internet. RFC 1766, the predecessor of RFC 3066 that nowadays specifies language-region tags, came into existence only 1995. Both specify that for countries/regions ISO-3166-1 alpha-2 codes are to be used. > For those that don't know, ISO 3166 has *FOREVER* been defined as > the following: > - two letter country code resembling country name > - may be changed in accordance with the country name change > - may be reused They may not be reused for 5 years. It still is short-sighted to reuse them after 5 years. > Now, everybody's broken applications which didn't follow the specs Which specs? > are ISO 3166's fault? In this case IMHO it is. They don't even follow their own goal. Citing from the bottom of http://www.iso.org/iso/en/prods-services/iso3166ma/04background-on-iso-3166/iso3166-past-present-and-future.html | With the growing integration of the Internet into many aspects of | (business-)life the need for coded information related to geographical | concepts like country or place names will continue to rise. ISO 3166-1 | is going to be one of the ISO standards which help facilitate this | integration process - today and tomorrow. With reused codes there is no tomorrow. > > | - Almost all already existing software only knows about YU, not CS. Not > > | using YU in the file format would result in unrecognized locales in > > | interoperability. > > This has changed. GNU libc in 2.3 and HEAD branches knows only about > sr_CS, and not about sr_YU. Yes, but it changed only recently. > > | - ICU, the i18n library OOo uses, has YU entries, using CS instead would > > | only lead to error prone mappings at all times. > > In a list of countries (as translated in each ICU locale), I see "CS" > for Serbia and Montenegro. Please bear in mind that the mail I cited is from February 2004. sr_CS is only since recently known to the ICU. > There is no "YU": > > > http://www-950.ibm.com/software/globalization/icu/demo/locales/en/?_=sr&SHOWCountries=1#Countries > > "Region" is not otherwise specified for "sr" in ICU. There is an alias defined: http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu/source/data/locales/sr_YU.txt > CLDR also uses CS already: > > http://www.unicode.org/cldr/data/diff/main/sr_CS.html > > > | - WIPO recommends the use of YU until the ISO 3166/MA has taken a final > > | decision, see > > | http://www.wipo.org/scit/en/meeting/sdwg/4/pdf/scit_sdwg_4_6.pdf > > | section 5. > > I don't understand why everybody thinks nobody knew about the problems > in ISO 3166 commitee? Who said so? They knew perfectly well, but they didn't really care. > It's been two years since a change. It took 5 months to finally agree > on a code change from YU to CS (as I said, country name was changed in > early February 2003, ISO 3166 changed code only in late July 2003), > after *several* meetings without a decision. In my eyes, I see this > only as an indication that it was hard to come up with ANY solution, > and that CS was the best solution possible. I won't talk about politics here right now, but the entire story why it took so long and why in the end they used CS and not something else IMHO was a political decision, maybe because Serbia And Montenegro insisted on using nothing else or whatever, I don't know. There is no real other reason why it had to be CS. > I should probably pull out a random multinational organisation (uhm, > how about ISO?) which recommends using "CS" over "YU". Oh yeah, it's > a sensitive topic, but lets not put out statements from someone we > agree with as "look, they agree with me as well" as any more objective > than others. Or, what is current situation in OOo: lets wait until > they change a decision to make it align with my own opinion. For OOo in the end it was simply a technical decision: back in 2003/2004 the situation was a complete mess, and no library supported CS. This changed, and one of the next OOo versions will support sr_CS. > As I said, the problem is that everybody was expecting to use ISO 3166 > in a different way than it was defined. And there is NO chance of > collision in OpenOffice.org: there was never sr-CS meaning Serbian in > Czechoslovakia, so you need not worry. That's not the point. I could even come and define and use en-CS if I wanted to have locale data for English language for use in Serbia And Montenegro. > > Of course we can consider re-evaluation of how OOo will handle this, but > > in this special case it is not simply "follow the standard". > > If you're into exceptions and special cases, then just use "SCG". Using alpha-3 code wouldn't comply with RFC 3066. > At the same time, I'd recommend removing sh-* stuff, because it's a > hack. Yes, it's a hack. It's a hack because ... > For GNU libc, I have [EMAIL PROTECTED] locales ("Latn" is ISO 15924 script > identifier). ... script identifiers aren't supported. Looking forward for new challenges that will surely arrive with RFC3066bis http://www.inter-locale.com/ID/why-rfc3066bis.html 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]
