some packages(especially some older ones dates back to pre-unicode days) use "zh_CN.GB2312 zh_TW.Big5" for Chinese locales, specifying "zh_CN zh_TW" will not install the proper locales. in the case of gtk+-1.2*, emerge with LINGUAS="zh_CN zh_TW" will simply fail. Reproducible: Always Steps to Reproduce: 1. 2. 3.
*** Bug 94835 has been marked as a duplicate of this bug. ***
My locales: # locale -a C de_AT de_AT@euro de_AT.utf8 en_US en_US.utf8 POSIX zh_CN zh_CN.gb18030 zh_CN.gbk zh_CN.utf8 And build attemp: [ebuild N ] x11-libs/gtk+-1.2.10-r11 USE="nls -debug" 0 kB [...] checking for xgettext... /usr/bin/xgettext checking for catalogs to be installed... de zh_CN [...] make all-recursive make[1]: Entering directory `/var/tmp/portage/gtk+-1.2.10-r11/work/gtk+-1.2.10' Making all in po make[2]: Entering directory `/var/tmp/portage/gtk+-1.2.10-r11/work/gtk+-1.2.10/po' PATH=../src:$PATH /usr/bin/xgettext --default-domain=gtk+ --directory=.. \ --add-comments --keyword=_ --keyword=N_ \ --files-from=./POTFILES.in \ && test ! -f gtk+.po \ || ( rm -f ./gtk+.pot \ && mv gtk+.po ./gtk+.pot ) make[2]: *** No rule to make target `zh_CN.gmo', needed by `all-yes'. Stop. Probles is that gtk+-1.2 doesn't contain zh_CN.po (i.e. chinesse catalog in UTF-8). So, I created one, modified Makefile, run "make all-yes". It ended successfuly. So I continued using ebuild {compile, install, qmerge}. Could any one fix it?
does this happen with all packages that do not have those .po files? is there no fallback, or is this a bug with gtk+-1.2 that it doesn't detect/filter the correct linguas out?
(In reply to comment #3) I don't know. I met this problemy only once with gtk+-1.2. In the source code there are all PO files in UTf-8 (i.e. lang_COUNTRY.po with proper enconding). Only the zh_CN is missing and instead of it there is PO in GB2312 encoding (zh_CN.gb2312.po). But the make all-yes target has as a dependency only lang_COUNTRY.gmo files. These files are created from PO files. The detection of presence of these files is done by simple sed cutting /po/gmo/ extensions. BTW, recent gettext can recode messages from gmo files on the fly, therefore it doesn't matter which charset/endoding is used at runtime and which encoding is catalog saved in. So storing concurent catalogs has no sense. If you are asking for make fallback, then yes, in case of gtk+-1.2 it is missing. But as I know every package has its own algorithm of PO files detection.
LINGUAS support in auto* tools was broken for a long time, it was the main reason we never promoted using it.
I don't see anything left to track here.