On Tue, Feb 10, 2015 at 06:36:58PM +0100, Federico Beffa wrote: On Tue, Feb 10, 2015 at 6:13 PM, Ludovic Courtès wrote: > Federico Beffa skribis: > >> Guile-ncurses was fixed by adding a new phase to generate the >> "en_US.UTF-8" locale during the generation of the package, but wouldn't >> it be better to keep the "en_US.UTF-8" locale? That appears to be the >> default used by most packages. > > That’s an open question. The vast majority of packages is happy with > just the C locale, and some need something more. > > So far the approach has been to fix these one by one (that’s 4 packages > so far) but if it happens to be frequent enough or cumbersome, we can > change that in the next core-updates to have en_US.UTF-8 available by > default. (i) we already are at 7 (4+3) packages requiring an UTF-8 locale Then that is a bug which should be filed against those pacakges. (ii) This is another small step in making maintenance easier by providing an environment setting that sometimes helps. It sounds like a slippery slope. If we shovel in everything into the defaults, that might possibly help somebody do something, someday we'll end up with a very bloated system. The C locale is the canonical locale. UTF-8 is not the only characater encoding in the world. English is not the only language in the world, and US English is not the only dialect of English. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.