[MPlayer-dev-eng] Using gettext in MPlayer

Arpi arpi at thot.banki.hu
Wed Jul 3 16:57:59 CEST 2002


Hi,

> > IIRC, the discussion about gettext in the archives ended in Arpi et al
> > deciding gettext wasn't portable enough and they didn't like the
> > interface, or something, so whoever was working on this stuff was
> > going to write their own gettext-like code. Read the archives though
> > -- I may be remembering incorrectly.
> 
> The last thing I found was posted by A'rpi on June 26 (mplayer-users):
> > > And another question: Arpi, do you mind against GNU gettext usage
> > > instead of hard-coded strings?
> > no
> > there was even some work on gettext support, but no one was interested
> > enough to do it well... anyway i'm not sure in that we really need it.
              ^^^^^^^^^^
the problem is here...

i don't like the _() solution, a sit requires the whole source code to be
converted to use _() everywhere _AND_ converting all help_*.h files to *.po
files _AND_ user must have the .po (or it's binary form) installed to get
any messages. these are big disadvantages and issues.

> True, developers don't really need it. Translators do. :)
why?

there were 2 issues with the current system:
- adding new messages was problematic, as it needed immediate update of
translated files. it has been solved by help_diff.sh
- switching between languages isn't possible in runtime, just in compiletime
imho it isn't a big problem, since mplayer is compiled from sources by most
users. anyway i have plans to simple implementation of runtime language
switching with the current system - just needs a simple (scriptable)
conversion of help* files, and extending mp_msg() a bit.

> Also, I found A'rpi's suggestion for a gettext-replacement. While
> better than the current help_mp-??.h stuff, it still has some
> problems:
> * Updated translations can't be used without recompiling MPlayer.
i don't think it's a problem

> * Translators have to edit source files, paying attention to
>   #ifdefs and the like...
same... and with ifdef's we can do config-sensitive messages/translations,
like error messages depending on runtime cpudetect en/disabled, not listing
not available options (-dvd etc) and so on

> * You might need to develop some tools to aid translators
>   (something like help_diff.sh).
help_diff does the job


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu



More information about the MPlayer-dev-eng mailing list