Steve Langasek [2013-06-05 13:29 -0700]:
> By what mechanism do we currently ensure locale availability, except for
> langpacks?
d-i and ubiquity create some default locales (like en_*.UTF-8) and
also install the langpack for the language choosen at install time,
plus -en.
In cloud-config you specify the locale in the userdata file ("locale:
en_US.UTF-8"); I don't know whether there is a default there.
But NB that even in a case where we do not build any locale in the
system and do not set any in the environment, PostgreSQL will install
fine (and then just use C).
Things just go haywire if you set a locale which does not actually
exist; but then not just PostgreSQL will break, but you'll also get
tons of errors from other programs.
I'm willing to make the package installation work without a dpkg
failure and just not create any cluster in that case, if that's
considered an improvement. I will NOT make postgresql do guesswork and
create and use some random locales.
> There's a big difference between wanting your database server to be
> able to handle arbitrary localized data, and wanting translations
> for all languages installed on your database server. Langpacks
> allow the former, but only at the cost of the latter.
You can create more locales without the corresponding langpacks.
(sudo locale-gen de_AT.UTF-8 fr_FR.UTF-8 [...]). If you also want
messages from postgresql itself translated, then you need to install
the langpack, of course.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
