Hi Danilo, On Wed, Aug 03, 2005 at 18:40:58 +0200, Danilo ??egan wrote:
> Sorry if I sounded too harsh. It's ok. > I just heard a lot of the same arguments before, and they only helped > delay adoption (the position of ISO 3166 has not changed). And never will, I guess. Now it would also only cause again more confusion. > >> 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 can't find anything. Care to give me a pointer or two? Hmm.. I must draw back a little, it seems all ranting and raving started shortly _after_ the final decision on 2003-07-23 because the proposal made by the "Serbia and Montenegro" government to be voted on wasn't published earlier by the ISO-3166/MA, see http://www.iso.org/iso/en/prods-services/iso3166ma/01whats-new/index.html http://www.iso.org/iso/en/prods-services/iso3166ma/03updates-on-iso-3166/index.html > I found http://www.statoids.com/w3166his.html, Thanks for yet another pointer ;) > ISO 3166 was not designed for the way it was used (basically, it > should have always been used with a date tag next to code), and it's > not a problem in ISO 3166 as it is, but that users need a different > (better) standard: one that doesn't assign codes valid only in certain > time ranges. > > Maybe ISO 3166 can evolve into such a standard, but maybe we'd need > another one. (i.e. if I remember correctly, RFC3066bis is going away > from ISO 3166 with a clause like "if a code has been re-assigned in > ISO 3166, don't use that in RFC3066") Sort of. RFC3066bis sets out an IANA registry where conflicting codes must not be entered, this for ISO 639, ISO 15924, and ISO 3166. > >> 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. > > Aren't they? ICU seems to use them, and maybe I'm mistaking RFC 3066 > with... OOo doesn't support script codes yet. > > Looking forward for new challenges that will surely arrive with RFC3066bis > > http://www.inter-locale.com/ID/why-rfc3066bis.html > > where I'm sure ISO 15924 script identifiers ARE supported Yes, they are. > (it's easy > to define them, since any alpha-4 key in a language tag positioned > right after language key is a script identifier). It's easy to define, but most old code is not prepared to parse them, it might even confuse them with a 4 character region tag ... > Or I'm completely > confusing this with "tags for identification of languages draft": > > > http://www.simpleweb.org/ietf/internetdrafts/complete/draft-phillips-langtags-03.txt No, it's the same, just that now they're at version 10 and not 3 anymore. For matching alone there exists yet another draft that excludes all the other aspects that were covered in the 3066bis draft. The 3066bis emerged into the following three drafts grouped under the Language Tag Registry Update (ltru) http://www.ietf.org/html.charters/ltru-charter.html http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-03.txt A list of all valid subtags for language tags created under RFC 3066bis: http://www.unicode.org/cldr/data/tools/java/org/unicode/cldr/util/lstreg.txt 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]
