This is an upstream bug (or lack of a feature) in the configure script, mplayer will use LINGUAS for two configuration options at the same time: output message display and which man pages to build. Ideally, there would be two configuration options, one asking which language to build output message support, and one asking which languages to build man pages for. There have been related bugs to this, and I'm adding this one so we can reference it in the ebuild. A patch to fix it would be quite welcome if someone wants to take the time.
As far as my (probably limited) understanding of the issue goes I think that the root of the problem is that mplayer doesn't use gettext for l10n but it's own system. If gettext was used then any of the installed translations (what could be in turn controlled by the build system and the ebuild) of the help messages could be loaded at runtime respecting LC_* env variable. There wouldn't be any need of LINGUAS having the preferred language as the first one. Instead their build system takes the first language in LINGUAS, searches for the appropriate header with translations in 'help/', runs it through help_diff.sh (to merge it with the original English header file) and then includes it under the build process. Thus the language of the help messages once selected at build time cannot be changed at runtime. If someone could make mplayer devs to utilise gettext (I wouldn't as I'm really not the person the tell seasoned C programmers what to do) I think the problem would be solved in an ideal way. However, after some googling i found this: http://lists.mplayerhq.hu/pipermail/mplayer-docs/2004-October/003189.html which suggests that several people tried that over the years with no results... I can propose a possible workaround for the issue though. As far as I understand the ebuild just lets the build system read the LINGUAS variable and do it's own thing. However, the build system supports manual selection with --language= option which could be passed in EXTRA_ECONF. There're some problems with that though: * mplayer ebuild doesn't use econf (which supports EXTRA_ECONF) and calls ./configure directly (probably not without a good reason) * using EXTRA_ECONF in the ebuilds directly is discouraged (at least vim syntax for the ebuilds highlights it in red here) and so there may be a problem with simply appending ${EXTRA_ECONF} in the ebuild * I've heard somewhere that one shouldn't introduce new eclasses unless they are really needed and I don't know whether an eclass with single function for mplayer ./configure which will support EXTRA_ECONF to handle a corner case is important enough.
(In reply to comment #1) > As far as my (probably limited) understanding of the issue goes I think that > the root of the problem is that mplayer doesn't use gettext for l10n but it's > own system. <snip> That's true, and I'm not expecting anyone to step up and fix that gargantuan task. Simply put, the configure script is using one variable for two arguments, which can be split out.
> Ideally, there would be two configuration options, one asking which language to > build output message support, and one asking which languages to build man pages > for. I did not check the current state, but in the past both was handled by the same configure option: the language specified _first_ is used for messages and all languages specified are used for man pages/documentation.
(In reply to comment #3) > > Ideally, there would be two configuration options, one asking which language to > > build output message support, and one asking which languages to build man pages > > for. > > I did not check the current state, but in the past both was handled by the same > configure option: the language specified _first_ is used for messages and all > languages specified are used for man pages/documentation. > Reimar, Yah, that's how it's still handled. The problem we are having is that we just look at $LINGUAS from make.conf. The problem is that the ordering is arbitrary in the config file, so we are assuming that whatever is first is the one that they wanted their messages in, which is not always the case. If the configure option was separated from one into two (build messages for langauge $x, build man pages for langauges $x $y $z), it would be easier for us to pass along the specific directives. A trivial feature request, I realize, but it has been a cause of confusion for some users which is why I wanted to at least have a bug opened as a reference.
Tried just concatenating them? I _think_ having a language twice does not cause any problems. Well, you can't have the messages in a language and not the man pages in that language then, but that seems rather minor...
(In reply to comment #5) > Tried just concatenating them? I _think_ having a language twice does not cause > any problems. Well, you can't have the messages in a language and not the man > pages in that language then, but that seems rather minor... > Well, here's an illustration of what would cause the problem. Say your LINGUAS in make.conf is set to "de en". In the mplayer ebuild, we just pass that variable to the --language argument. The configuration script sees "de" as the first in the list, so that will be the output for the messages. The man pages will then be built for German and English. That causes problems is when someone didn't want their message output in the first language listed, so we have to tell them to rearrange the variable in make.conf to fix it correctly. Tweaking the configure script is the only way I can think of to get around the issue, since then we could use the system's locale settings to see which language to output messages in, then just use LINGUAS for man page support.
Fixed now in 1.0_rc2_p20090731 The language options have been split, setting one for each message output / documentation creation.
