On Wed, Feb 01, 2006 at 07:58:58PM +0100, Danilo Segan wrote: > Yesterday at 15:42, ???????????? wrote: > > > You can prevent just by only having UTF-8 locales on the machine. > > GNU systems allow users to install their own locales wherever they > wish (even in $HOME) by setting environment variable LOCPATH (and > I18NPATH for locale source files themselves).
Yes, this is unfortunate. :) You may be interested in the C library replacement I'm working on. It provides only UTF-8 through the multibyte/wide character interface (although iconv is of course available for explicit conversions) and has highly optimized UTF-8 processing to minimize/eliminate the performance problems of using UTF-8 on older machines. I don't have regex working yet but my estimate is that pattern matching will be at worst 5% slower than 8bit locales, and probably not measurably slower at all. Unlike other similar projects it's under LGPL and designed with long-term ABI stability in mind so that it's actually a viable replacement for glibc on non-embedded systems. It's about 80% done as of now. I'll be sure to post announcements here when it's ready for testing since serious UTF-8 users and LFS/DIY types are my main target audiences. Rich P.S. Apologies for trashing the non-ascii characters in my reply. This is why I'm working on making a viable UTF-8 platform for myself... -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
