[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#522776: debian-policy: mandate existence of a standardised UTF-8 locale

On Mon, Apr 06, 2009 at 02:06:55PM +0200, Thorsten Glaser wrote:
> Package: debian-policy
> Version:
> Severity: wishlist
> For the mksh regression tests, I need a UTF-8 locale working; most
> systems either provide “en_US.UTF-8” or “en_US.utf8” with the former
> being recommended.

Hello Thorsten,
I have some sympathy with your proposal because dgettext does not work
in the "C" locale but there are too much open question.

> The most light-weight solution would be to
> • introduce a “C.UTF-8” locale, as some other OSes did, which is
>   equivalent to the “C” (POSIX) locale in all respects *except*
>   for LC_CTYPE, where it uses UTF-8 instead of a 7/8-bit charac-
>   ter set or encoding

What about LC_COLLATE (which is a major problem with sort(1)) ?

> • deliver the “C.UTF-8” locale with the base system
> • allow Debian packages to depend on its existence, both at
>   build and run time
> A more controversial solution would be to do the second and third
> point of the above with the “en_US.UTF-8” locale, but that would
> be favouring US americanism. (On the other hand, it’s *the* one
> most widely spread UTF-8 capable locale available, and as such,
> the mksh regression tests use it upstream already.)

What about packages that run before /usr is mounted ? 
What about embedded systems with tight space requirement ?

Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Reply to: