Bug 1321930

Same happens in Czech. Reassigning to setroubleshoot.

I'm not even able to run ls with czech locales:

$  LC_ALL=cs_CZ.UTF-8 ls a
ls: cannot access 'a': No such file or directory

$ rpm -qa | grep glibc
glibc-langpack-cs-2.23.1-5.fc24.x86_64
glibc-devel-2.23.1-5.fc24.x86_64
glibc-debuginfo-common-2.22-11.fc23.x86_64
glibc-headers-2.23.1-5.fc24.x86_64
glibc-debuginfo-2.22-11.fc23.x86_64
glibc-all-langpacks-2.23.1-5.fc24.x86_64
glibc-2.23.1-5.fc24.x86_64
glibc-common-2.23.1-5.fc24.x86_64


Is there something else needed after https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging ?

(In reply to Petr Lautrbach from comment #2)
> I'm not even able to run ls with czech locales:
> 
> $  LC_ALL=cs_CZ.UTF-8 ls a
> ls: cannot access 'a': No such file or directory
> 
> $ rpm -qa | grep glibc
> glibc-langpack-cs-2.23.1-5.fc24.x86_64
> glibc-devel-2.23.1-5.fc24.x86_64
> glibc-debuginfo-common-2.22-11.fc23.x86_64
> glibc-headers-2.23.1-5.fc24.x86_64
> glibc-debuginfo-2.22-11.fc23.x86_64
> glibc-all-langpacks-2.23.1-5.fc24.x86_64
> glibc-2.23.1-5.fc24.x86_64
> glibc-common-2.23.1-5.fc24.x86_64
> 
> 
> Is there something else needed after
> https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging ?

No, the installation of glibc-langpack-cs should be sufficient.  You need to provide more information (strace output, for example).

Created attachment 1141574 [details]
strace ls

$ locale
LANG=cs_CZ.UTF-8
LC_CTYPE="cs_CZ.UTF-8"
LC_NUMERIC="cs_CZ.UTF-8"
LC_TIME="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
LC_MONETARY="cs_CZ.UTF-8"
LC_MESSAGES="cs_CZ.UTF-8"
LC_PAPER="cs_CZ.UTF-8"
LC_NAME="cs_CZ.UTF-8"
LC_ADDRESS="cs_CZ.UTF-8"
LC_TELEPHONE="cs_CZ.UTF-8"
LC_MEASUREMENT="cs_CZ.UTF-8"
LC_IDENTIFICATION="cs_CZ.UTF-8"
LC_ALL=cs_CZ.UTF-8

$ strace -o ls.strace /usr/bin/ls asdsadasdsad

I'm not sure if it's related but 

# build-locale-archive --install-langs=all       
build-locale-archive: cannot read archive header

I still can't reproduce this.  Can you show your entire environment (output of “env”)?

Setting LANGUAGE almost has this effect, but is not reflected in the “locale” command:

sh-4.3# LANGUAGE=en ls -l a
ls: cannot access 'a': No such file or directory

But even with that, I see still an access to the LC_TIME locale information (for “en”), which is missing from your strace output.

“rpm -Va” output might reveal something, too.

I wasn't aware that I have LANGUAGE variable set and it apparently overrides other settings. Thanks for hint!

sealert browser is run via your session DBUS daemon. If you want to run it with other locales, you either need to change it for the whole session or use -S option

$ LANGUAGE=czech sealert -S

works as expected.

Observing the same issue for Russian locale: 
GUI is partially in English, although some of the strings which appear in English were translated as early as 20/02/2015. Current GUI requires resync with most up-to-date translation in zanata.

Similar issue as described above for Brazilian Portuguese. Application is mainly in pt-BR, but there are strings in English that were previously translated in zanata.

For ko-KR, Some strings (eg: delete, previous, next) still appear in English but could find it in Zanata.