Date: Fri, 12 Jun 1998 11:03:12 +0900 From: Jun-ichiro itojun Itoh <itojun@itojun.org> To: Terry Lambert <tlambert@primenet.com> Cc: joy@urc.ac.ru, kline@tao.thought.org, hackers@FreeBSD.ORG Subject: Re: internationalization Message-ID: <953.897616992@coconut.itojun.org> In-Reply-To: tlambert's message of Thu, 11 Jun 1998 22:36:57 GMT. <199806112236.PAA28653@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Handling bare iso-2022 string is some hard to implement because it >> is variable length (yes I agree). If we can provide a good library >> for iso-2022, then there's no reason for us to migrate to Unicode. >Except that 85% of the computer systems in the world and 90% of the >computers in the Western world are going to be running Unicode by the >year 2010 because of Microsoft Windows and JAVA. By the year 2010 FreeBSD rules the world, as you know :-) >And we would like to be able to interoperate with them without paying >a very high conversion overhead when we do it. I've never wanted people in US to use iso-2022-jp/kr/whatever. If I got 32bit wchar_t, runelocale library can support Unicode encoded data source and iso-2022 (incl. EUC) encoded data source just by setting environment variable LANG. There's also standardizing effort (or it maybe already done, I dunno about the current status) for stateful encodings support with wchar_t, as ANSI C extension standard so this is not just me wanting such as support for runelocale. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?953.897616992>