Date: Sat, 19 May 2001 14:38:41 +0900 (JST) From: Noriyuki Soda <soda@sra.co.jp> To: i18n@FreeBSD.ORG, audit@FreeBSD.ORG Cc: bsd-locale@hauN.org Subject: Re: CFR: ISO_* -> ISO-* locale renaming Message-ID: <200105190538.OAA01191@srapc342.sra.co.jp> In-Reply-To: <20010519075333.C83245@nagual.pp.ru> References: <20010518203702.B79058@nagual.pp.ru> <20010519050946U.tshiozak@din.or.jp> <200105182238.HAA29872@srapc342.sra.co.jp> <20010519031612.B83245@nagual.pp.ru> <200105182356.IAA00242@srapc342.sra.co.jp> <20010519075333.C83245@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Sat, 19 May 2001 12:53:45 +0900, "Andrey A. Chernov" <ache@nagual.pp.ru> said: > On Sat, May 19, 2001 at 08:56:54 +0900, Noriyuki Soda wrote: >> >> The existing standard (ISO8859-1) is reasonable. >> There is no reason not to use the name. > Yes, there _is_ that reason. In your case nl_langinfo(CODESET) returns > _illegal_ and unusable MIME character set so you can't use it f.e. in mail > exchange or any other MIME format compatible application. So, you need > conversion table between illegal and legal character sets in case you > suggest. I am strongly against such practice. Compatibility reasons > weights very small comparing to that. You are missing point. It is existing practice that the return value of nl_langinfo(CODESET) is not usable for MIME charset name. So, *ALL* existing programs are using conversion table to convert nl_langinfo(CODESET) to MIME charset name. Interestingly, this is true on even Linux. Because Linux uses "ANSI_X3.4-1968" as nl_langinfo(CODESET) for ASCII as I already pointed out, and many programs only knows "US-ASCII" as MIME charset name for ASCII, programs usually have to convert "ANSI_X3.4-1968" to "US-ASCII" on even Linux. If a program depends on the fact that an OS retruns MIME compatible value as nl_langinfo(CODESET), such program is just not-portable. So, avoiding conversion table has no real gain at all. All programs are using such conversion table already. And all future programs also should use such conversion table in the future, because all commercial UNIX and even Linux returns unsable value as MIME charset name. >> That avoids benefit to use IANA registry. >> >> If MIME charset name can be just used as codeset name like Linux, >> certainly it has its benefit. But if it cannot be used, why do you >> want to use IANA registry at all? I said "benefit" above, but it is not *real* benefit, because portable code cannot rely on such behavior. > Currently IANA registry codeset can be used in MIME applications as is and > it is main benefit of choosing IANA and main X11 disadvantage. > About case insensitive and aliased names at whole as you ask: this must be > implemented in one direction only, i.e. ideally locale code must > understand _any_ codeset, including X11 one, That is very problematic approch. The codes which understand locale names are not only locale functions in libc, but also many userland programs. For example, look at charset.c in "less" program. "less" certainly parse locale name, and the way that "less" currently use is case *sensitive* (of course). If any locale code must understand _any_ codeset, there are really many programs that FreeBSD should modify. And most importantly, there is no real benefit to implement such complex rule (because the way is not portable at all). In contrast to your proposal, using X11 (or OpenGroup) locale name requires almost *no* code change at all, because they are already standard and already supported. >> So, your proposal is not only incompatible with commercial UNIXes, >> but also incompatible with Linux. Mmmm, how about using X11 name instead? > I explain my position about multi-names a bit earlier in this > message. Currently such code is not implemented. The way I proposed is same with what commercial UNIXes are already do, and it is already implemented on FreeBSD, and waiting for approvement for merging to FreeBSD. In contrast, your proposal is incompatible with commercial UNIXes, and incompatible with even Linux in some points. Why do you have to create yet another incompatiblity, even there is no real benefit? -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-i18n" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105190538.OAA01191>