Yesterday at 15:29, Eike Rathke wrote: >> Also, sr-YU should be renamed to sr-CS, since country code for Serbia >> and Montenegro has changed to CS from YU along with the name change >> from Yugoslavia in February 2003 (code change has been done in ISO >> 3166 in July 2003). > > Which was rather short-sighted to put it mildly, as CS before was used > for Czechoslovakia. Reusing the code was a very bad idea. We had > a discussion about that in 2003/2004, see my mail > http://l10n.openoffice.org/servlets/ReadMsg?list=dev&msgNo=2976 > and the thread it appears in; for those with a local mail archive, it's > Message-Id: <[EMAIL PROTECTED]>
How come nobody noticed such "short-sightedness" (I agree it sucks, but look at how ISO 3166 was defined ages ago) when similar happened in 1991: country of Bosnia and Herzegovina, Croatia, Macedonia, Montenegro, Serbia, Slovenia used the code "YU", and then that code was assigned to country of Serbia and Montenegro. Technically speaking, this change was very similar: applications which misused "YU" to refer to pre-1991 Yugoslavia would either mistake old data (eg. Croatian) to be Serbia and Montenegro only, or would mistake new data to be former Yugoslavia data (eg. it might be relevant to Slovenia). So, all data applications unable to cope with this change (i.e. differentiating between pre-1991 "YU" and 1991-2003 "YU") were broken in meaning and sense, and they're only ones affected by this change. 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"). 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. 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 Now, everybody's broken applications which didn't follow the specs are ISO 3166's fault? > Citing from that mail: > > | As there is no real solution to this problem, and still no decision made > | by any authority, especially not the ISO 3166 maintenance agency, we'll > | stick to YU for the following reasons: > | > | - 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. > | - 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. 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. 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? 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. Complaint was sent right away, but it's been two years without a resolution, so I don't see anything changing here. "CS" is now already widely used. For instance, bank SWIFT codes (used in electronic money transfers) all use "CS". The same is everywhere else (currency code is now "CSD"). Not to mention that I can't see WIPO as relevant here. Anything using term "intellectual property" (I can understand term "intellectual creation", but as soon as I publish and/or make available a certain intellectual creation, there is no way to insist that it's still my own "intellectual property" [property of my intellect/mind], since others will be able to understand it, intellectually process and recreate it) is not the source I'm going to trust. 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. 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. > 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". Serbian people would prefer that (country name in Serbian with Latin script is "Srbija i Crna Gora"), it's ISO 3166 alpha-3 code (so it's still standard), and I can't see anyone complaining. Now, we could also claim "C" in "CS" to come from "Србија" (Serbian for Serbia) ;-) I actually would hate using "SCG" here (even more than I hate the "CS" code, because it's completely inappropriate), because we either follow the rules or we don't. If we don't, lets just use "SR" (Suriname, I haven't yet seen a locale for that, so who cares, right?), because once Yukon become a country, it's probably going to take "YU" ;) At the same time, I'd recommend removing sh-* stuff, because it's a hack. It's not ISO 639-1 code (it's deprecated), it's not Serbo-Croatian but Serbian language (lets leave this discussion to linguists), and it's not indicating the difference that it should (a different script in use). For GNU libc, I have [EMAIL PROTECTED] locales ("Latn" is ISO 15924 script identifier). Cheers, Danilo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
