[MPlayer-dev-eng] Using gettext in MPlayer

[Andras Mohari]

On Wed, Jul 03, 2002 at 16:57:59 +0200, Arpi wrote:
> 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.

The _() solution is the way gettext works.  Anyway, there's
no need to use _() everywhere -- only where a translation is needed.

help_*.h to *.po conversion has to be done only once.

Users must have mplayer installed to get any messages. :)

As for installing binary catalogs: if you don't use hard-coded
messages, you have to store them somewhere, even if using a
different implementation.  Is this the problem?

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

'Cause they don't have to mess with *.h files and #ifdefs.
(Now if they want to update a translation, they have to check the
whole(!) file to make sure that everything is up to date.)
'Cause there are good tools for managing translations.  Updating
a translation is just a matter of running msgmerge (it's fast) and
checking only(!) fuzzy and untranslated messages.

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

It means that you will see non-English messages in bugreports, because
only one language is supported.  Not a serious problem, but it can
be annoying.

> 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.
                                 ^^^^^^^^^^^^^^^^^^
That's it.  If you manage to do it without the need to change all
calls to mp_msg(), then fine. If *not*, then what's the difference
between using _() and modifying mp_msg() calls?

> > * 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

Translations should not be config-sensitive.  Messages and options
should be _printed_ in a config-sensitive way.  Hmm, I admit that it
requires more work.

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

It worked rather slowly for me. (Celeron 633; no, I won't upgrade. :-))

I hope I did not offend you.  I see that you don't like gettext,
so I won't bother you with it anymore.

Regards,
-- 
Andras Mohari
mayday at mail.nagyatad.hu