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: 3.8.1.0
> 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 ?
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: