gnucash respects the LINGUAS variable of /etc/make.conf, but does not support it with IUSE. My system language is English, but I prefer for the desktop applications German. Therefore my LINGUAS variable is set to "en" and I can add German individually with use flags. This works perfectly for the most applications (KDE stuff, firefox, opera, cups, avidemux, ...), but unfortunately not for gnucash. Before compiling a new version, I have to modify manually the LINGUAS variable in /etc/make.conf to get German support otherwise it is simply missing and I get English only. Reproducible: Always Steps to Reproduce: 1. Set LINGUAS in /etc/make.conf to "en" 2. emerge gnucash 3. Start gnucash with "LANG=de_DE.UTF-8 gnucash &" Actual Results: Application menu is in English Expected Results: Support for linguas in IUSE, to set "+linguas_de" in /etc/make/portage.use for gnucash. German application menu after starting the application with German locale.
Why don't you set LINGUAS specifying both langs?
Because I don't want German locales for most of the applications. For me it does not make sense to have German man pages for the command line tools and it is annoying if Konqueror always presents an alternative for "man:/bash" instead of displaying the English one directly.
Most (if not all) gnome ebuilds do not support linguas through IUSE_EXPAND variable. We could maybe have an eclass add support for this automatically but this would change quite a lot of ebuilds so please bring this up to gentoo-dev mailing list as it is unlikely that we will modify ebuilds one by one to satisfy such a specific need. Please note that you can achieve the same result with portage package.env file.
LINGUAS is a standard GNU variable for this, and integration with USE flags does not make much sense at this point of time without some sort of heavy PM support. We can not reasonably somehow peek into tarballs which languages are supported and deal with getting LINGUAS IUSE_EXPAND updated all the time on each bump, with changes in your global LINGUAS setting causing recompiles of everything (while you could just localepurge if trimming it up or something). The LINGUAS USE expand is primarily used for ebuilds to be able to do conditional downloads of language packs in their SRC_URI declaration, but with gettext translations included in the main tarball this is not necessary. I vote WONTFIX or CANTFIX.
Well, since I use normally KDE, this behavior was simply surprising. I have no problems to maintain a package.env for some view desktop applications/packages I'd like to have an additional language and which expect LINGUAS to be set in the environment.
Closing wontfix per comments and (old) -dev ml discussions.
