media-video/smplayer have "en_US" as a linguas variable, but no "en_GB", "en" or any other english variable. Therefore, when installing it with, for example, LINGUAS="en en_GB es es_ES", it won't install any english language, only spanish. Reproducible: Always Steps to Reproduce: 1.Install smplayer with some english LINGUAS variable except for en_US and some other LINGUAS in another language Actual Results: smplayer doesn't have any english language installed Expected Results: smplayer should have an english language pack installed Maybe I'm wrong, but I think that there should be some kind of "rule" in the devmanual or something that makes mandatory to have the general language before having the local languages, i.e., if a package only have "en_US", it should have "en" (in addition to or just that one), so an user that wants to install that program would have the language he/she wants, if not the exact local variant. There are more programs with this problem, like media-video/smplayer2 or media-sound/clementine (this one have the opposite problem, it has "en_GB" and "en_CA" but neither "en" nor "en_US").
In fact, smplayer (and other packages like it) *does* respect your LINGUAS. You do not have en_US specified, so it doesn't install that. You should either add en_US to your LINGUAS as a fallback option, or review the linguas use flags for packages you install and add linguas_en_US to your package.use for those packages that need it.
(In reply to comment #0) > Maybe I'm wrong, but I think that there should be some kind of "rule" in the > devmanual or something that makes mandatory to have the general language > before having the local languages, i.e., if a package only have "en_US", it > should have "en" (in addition to or just that one), so an user that wants to > install that program would have the language he/she wants, if not the exact > local variant. This could be done in l10n.eclass. Patches welcome!
(In reply to comment #2) > This could be done in l10n.eclass. Patches welcome! I'm not a dev, and I have minimal knowledge of bash scripting and portage. I could try to do this, though. The question is, will it be accepted? For me is an obvious bug (or a malfunction of portage, if you don't want to consider it as a bug, since technically everything works as expected), but if it's not going to be accepted, I'll rather save the effort.
(In reply to comment #3) > (In reply to comment #2) > > This could be done in l10n.eclass. Patches welcome! > > I'm not a dev, and I have minimal knowledge of bash scripting and portage. I > could try to do this, though. For me > is an obvious bug (or a malfunction of portage, if you don't want to > consider it as a bug, since technically everything works as expected), but > if it's not going to be accepted, I'll rather save the effort. l10n.eclass is maintained by Ben, and he says 'Patches welcome!', so, yes, if it will be proper solution - it will be accepted
