Christian Perrier wrote: > Quoting Arne Goetje (a...@linux.org.tw): >> Christian Perrier wrote: >>> Damn. This is one of those cases where we suffer from the silly trick >>> of using zh_CN and zh_TW to differentiate between two different >>> *scripts*. I really dream of different ISO-639 codes for the two >>> different written versions of Chinese: Traditional and Simplified. >> Err, no. Just use RFC4647 for the whole locale system. >> zh-Hans = simplified >> zh-Hant = traditional > > > Which, if I'm correct, would mean having zh-Hans_CN and > zh-Hant_TW|zh-Hant_HK locales, right ?
Almost. :) RFC4647 uses hyphens instead of underscores. The format is: langcode-script-territory-variation-x-usertags where: langcode = ISO 639-{1|2|3} script = ISO 15924 territory = ISO 3166 variation = a predefined list of variation tags x = separator between "official" tags and "user defined tags" (literally 'x') usertags = user defined tags and everything except langcode is optional. So, we would have locales zh-Hans-CN, zh-Hans-SG, zh-Hant-TW, zh-Hant-HK and zh-Hant-MO. These of course could be shortened to what we have today (zh-CN, zh-SG, zh-TW, zh-HK, zh-MO), but we would lose the ability to have a simple fallback mechanism. RFC4647 has been designed to provide a simple fallback mechanism, means zh-Hant-MO would fallback to zh-Hant, which would fallback to zh. <nitpick> Given that zh is actually a meta tag for "any Chinese language", it would probably even make sense to finally define what we mean with "zh", namely "Mandarin Chinese", which has the ISO 639-3 language tag "cmn". Means, the locales should actually be cmn-{Hans|Hant}-{CN|SG|TW|HK|MO}. </nitpick> ;) I'm just convinced that upstream glibc won't want to walk that path. > Also meaning renaming PO files progressively as well. > > > It would be nice if we could implement this. Yes, I'm still dreaming... ;) Cheers Arne -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org