From keld@dkuug.dk Sat Dec 8 14:27:52 1990 Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8) id AA10339; Sat, 8 Dec 90 14:27:52 +0100 Date: Sat, 8 Dec 90 14:27:52 +0100 From: Keld J|rn Simonsen Message-Id: <9012081327.AA10339@dkuug.dk> To: i18n@dkuug.dk, xotginter@xopen.co.uk Subject: Re: (i18n 32) japanese xopen locale with general charnames X-Charset: ASCII X-Char-Esc: 29 > [From "(i18n 32) japanese xopen locale with general charnames" dated Dec 6] > > I have modified the xopen japanese locale to use names in the form of > > giving the decimal row and columns of X0208. Also I changed the date formats > > to follow ISO rules (yyyy-mm-dd instead of yyyy/mm/dd). here it is: > > Keld, > > I'd welcome some rationale for what might otherwise be seen as > gratuitous editorial changes. Why did you do these things? > > My suggestions: > > 1. Character names: changed to facilitate future international > harmonization of national profiles. (Just a guess -- I'd really like > to know why you consider the new form to be preferable.) Yes, that is the reason. I am trying to do something which can be used as a model for harmonized locales. That means that each character have to be uniquely named . I am using 10646 as a base for the repertoire and for the naming. 10646 has official names for the Japanese characters on the form JIS-X0208-1984-27-55 where the 27 is the row and 55 is the column. The decimal notation is quite convenient as the Japanese, Chinese and Korean standards are all tabled with easily readable decimal row and column numbers. For compatibility with 10646 and conveniency I thus prefer the decimal notation over the hex. There are only some 5 ideographic character sets in 10646 so that can conveniently be represented by just one letter: j Japanese JIS X0208:1990 (basic Japanese) J Japanese JIS X0212:1990 (extended Japanese) c Chinese GB 2312:1980 (basic Chinese) C Chinese GB 7590:1987 (extended Chinese) k Korean KS C5601-1987 (basic Korean) Thus the beforementioned character can be uniquely and conveniently represented by the name . > 2. Date format: Note that the changes do not affect the external date > representation defined by d_fmt: only the format of dates within the > X/Open era extension definition has been changed. Assuming that > this or a similar extension is adopted by WG15, it is reasonable > that the dates should be represented in a format compatible with ISO > 8601. Indeed, taking this further, one could argue that the 8601 > representation of a period of time, where a solidus (slash) > separates the beginning and ending dates should be used. (Thus, > 1989-01-08:1989-12-31 would become 1989-01-08/1989-12-31.) Agree. > -- > Dominic Dunlop Keld Simonsen