Bug 458266 – media-video/smplayer should respect LINGUAS

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description [e-mail] 2013-02-19 11:02:27 UTC]

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").

[Comment 1 Ben de Groot (RETIRED) 2013-03-02 05:19:04 UTC]

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.

[Comment 2 Ben de Groot (RETIRED) 2013-03-02 05:21:46 UTC]

(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!

[Comment 3 [e-mail] 2013-03-02 18:45:19 UTC]

(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.

[Comment 4 Sergey Popov (RETIRED) 2013-03-02 19:01:06 UTC]

(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