Hello Helmut, Helmut Grohne [2013-02-13 8:49 +0100]: > Both /etc/default/locale and /etc/environment are empty on the system in > question. This likely represents the setting "C" that I usually make > during installation to avoid translation of messages.
Note that this also means that you cannot use any non-ASCII characters anywhere, including file names, shell commands, etc. and get a rather odd-looking date, printer papersize, and whatnot. locale is a lot more than just translations. > > In fact would postgresql have used my system setting the database > encoding should have been ASCII, right? Correct. > Side question: Is there a way to ask for UTF-8 without translation? Sure, set LANG=de_DE.UTF-8 and LC_MESSAGES=C . That will still use UTF-8 character encoding/sorting (LC_CTYPE, LC_COLLATE), and region settings (LC_PAPER, LC_TIME, LC_PAPER, etc.), but display the plain C (untranslated) strings. > I sshed directly into the root account. In this case ssh will take the > LANG and LC_* variables from the client system, which in this case yes, > plausibly was responsible for the latin1 choice. Indeed. > > As a compromise, pg_createcluster (and thus apt-get install) could > > show the locale of the generated cluster. Would that help? > > Yes. That would likely have solved the issue in my case, because I would > have been wondering over latin1 in a database. I think that this > shouldn't target wheezy though. > > The conclusion appears to be: > > retitle 700271 mention database encoding used during installation > tags 700271 - wontfix Agreed, thanks! Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
