Atomic hosts currently only include en_US.   There is no mechanism at present to extend the locale set post-installation.

This would require downstreams to create custom composes.

Additional: after a rollback to 7.0.0 there are no errors on a root login.
There are still no LC_* environment variables.

*** Bug 1166544 has been marked as a duplicate of this bug. ***

Future work may include non-US keyboard input but not translations.

One issue here is that ssh by default will propagate locale environment variables.  It might be nice to change ssh itself to detect whether a locale is available - Atomic is not the only system that comes locale-less.

That said it might be possible to tell ssh on atomic to always set en_US.UTF-8, but I'd prefer a solution in ssh as that would then support dynamic locale installation.

This also affects the Centos Atomic rebuild that was recently released - http://lists.centos.org/pipermail/centos-devel/2015-June/013542.html

> During installation, if you select a language other than American English
> as the default keyboard type, it is not reflected in the installed system
> afterwards. The locale is still set to `en_US` and error messages about
> locales missing are displayed. This could be problematic for programs that
> require other locales, or for example when you have a password in another
> language, the system will not recognize it.
All correct, I think, just as a comment: having environment variables set to request a different locale does not require selecting at install.  I am using ja_JP.UTF-8 on my workplace system and these variables are by default also transferred into remote systems (ssh) and docker containers.

Jeremy - is it sufficient to disable alternate local selection on install for this BZ?

Yes, but only if there is a documented method for obtaining a specified locale.

Is there a workaround for this issue that I can include in the release note?

*** Bug 1302342 has been marked as a duplicate of this bug. ***

Any update on this?

This installer counterpart of this bug (rhbz#1235726) is now verified. Is there anything else to do/test here? If not how about we close it?

I think my vote is to add all the locales by default.  If we look at this from the axes of:

 1) General purpose, potentially single machine OS
 2) Clustered kube/other host

Locales are a case that are important in #1, but not #2.  I'm pushing for a model where Atomic Host works in #1 too.  The cost to the #2 case is relatively small.

This comes up in the Docker base image case as well obviously.  The calculus there is a bit different, but if we follow out the thread of the "centosmin" vs "centos" style, I'd say min would only have C.UTF-8, and centos would have systemd and all locales.

(In reply to Colin Walters from comment #22)
> I think my vote is to add all the locales by default.

OK that works. I wasn't sure how hard we wanted to try to avoid shipping locales for the sake of size.

As a test, I just did a 7.3 tree compose in which we keep all the locales. The additional locales increase the size of the tree by almost exactly 100 MB. However, they compress to less than a quarter of that. So I'd expect the shipped qcow2 images, which are internally compressed, to increase by ~23 MB. Overall seems like an acceptable trade-off here given the benefits.

Should we target this for 7.3.1 or 7.3.2?

Has any thought be given to only shipping the "Supported" locales?  Can we do that?

(In reply to Daniel Walsh from comment #26)
> Has any thought be given to only shipping the "Supported" locales?  Can we
> do that?

How much space does that save?

(In reply to Daniel Walsh from comment #26)
> Has any thought be given to only shipping the "Supported" locales?  Can we
> do that?

I'm not familiar with what "Supported" means in that context. Is there a list of locales somewhere we consider supported?

Perhaps I am mistaken, I see Locales, and I am thinking languages.  But we currently support 22.  

Here is the RHEL6 list.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.6_Technical_Notes/ch-international_languages.html

Haven't figured out where the list is for RHEL7.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/7.0_Release_Notes/Red_Hat_Enterprise_Linux-7-7.0_Release_Notes-en-US.pdf

OK, that brings it down to on-disk 8.9M and compressed 1.9M. So in other words, negligible. Not to mention it actually makes sense to support the same set other variants do.

https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2016-October/msg00081.html

Hum...but there's no such definition of "supported" locales for Fedora AFAICS.  I guess though we could take the same list, and say that any changes to it would require the same process as RHEL?

OK, if we're ready to give this a try in Fedora, I created some PRs:

https://pagure.io/fedora-atomic/pull-request/30
https://pagure.io/fedora-atomic/pull-request/31

On the latest rawhide tree compose:

-bash-4.3# localedef --list-archive
as_IN.utf8
bn_IN.utf8
de_DE.utf8
en_US.utf8
es_ES.utf8
fr_FR.utf8
gu_IN.utf8
hi_IN.utf8
it_IT.utf8
ja_JP.utf8
kn_IN.utf8
ko_KR.utf8
ml_IN.utf8
mr_IN.utf8
or_IN.utf8
pa_IN.utf8
pt_BR.utf8
ru_RU.utf8
ta_IN.utf8
te_IN.utf8
zh_CN.utf8
zh_TW.utf8
-bash-4.3# LANG=fr_FR.utf8 date
mar. nov. 15 20:36:57 UTC 2016
-bash-4.3# LANG=ru_RU.utf8 date
Вт ноя 15 21:16:52 UTC 2016

Anaconda fix for RHEL AH installer:
https://github.com/rhinstaller/anaconda/pull/871

As mentioned in the PR above, one issue is that Anaconda currently shows all possible locales, rather than only the available ones. We could wait to put it back in the installer GUI until this is done properly. At least until then, users can specify one of the supported LANGs in their kickstarts.

Going to close this now.

Starting with 7.3.3, Atomic Host ships with all the officially supported locales. This however requires the use of a kickstart since the GUI installer for now only allows en_US. Though note that this will be fixed in 7.4 (see https://bugzilla.redhat.com/show_bug.cgi?id=1429576).