From owner-freebsd-hackers Thu Jun 11 19:04:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA03235 for freebsd-hackers-outgoing; Thu, 11 Jun 1998 19:04:58 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from coconut.itojun.org (root@coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA03221 for ; Thu, 11 Jun 1998 19:04:49 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id LAA00957; Fri, 12 Jun 1998 11:03:12 +0900 (JST) To: Terry Lambert cc: joy@urc.ac.ru, kline@tao.thought.org, hackers@FreeBSD.ORG In-reply-to: tlambert's message of Thu, 11 Jun 1998 22:36:57 GMT. <199806112236.PAA28653@usr09.primenet.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: internationalization Date: Fri, 12 Jun 1998 11:03:12 +0900 Message-ID: <953.897616992@coconut.itojun.org> From: Jun-ichiro itojun Itoh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> 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