[MPlayer-dev-eng] [PATCH] GTK2 support

[Rich Felker]

On Wed, Feb 22, 2006 at 01:23:18AM +0100, Torinthiel wrote:
> On Tue, Feb 21, 2006 at 05:36:09PM -0500, Rich Felker wrote:
> > > 2. Automatic MSG_NUMBER generation
> > 
> > This is bad, since message numbers might change across MPlayer version
> > and lead to printing nonsense (or even crashing) if the wrong message
> > files are used. That's why I want them to be defined once and
> > permanently in a help file.
> 
> Point taken. But who's gonna maintain them? And it still makes
> help_mp-en.h look ugly. And this is the most probable file every
> translator will look at, and TRY to guess translation format from it.
> How about we leave help/* as-is, add another file (say
> help/help_numbers) that keeps only the id's of messages (say # MSG* id)
> and make help_mp.h from these? It still takes some effort to maintain,
> but IMHO less, as text and id's can be maintained separately. Problem is
> that anyone adding a message should add it to both files, but probably
> compilation will enforce this. And it will be easier to choose if we
> fall back to English or translated messages (this way
> #define catgets(a,b,c,d) (d)
> works as previous behaviour).

Does it really look ugly to replace the lines in help_mp-en.h like
this:

old
#define MSGTR_Foo "Foo"
new
#define MSGTR_Foo _(1, "Foo")

IMO it's easiest if we can keep the canonical messages and their
numbers in one file. Otherwise using numbers is not easier than using
the gettext scheme (although still less bloated).

Alternatively to make adding new numbers easier, we could use the 'set
number' system in catgets to separate messages into different sets for
different parts of MPlayer, so that the above would be:

#define MSGTR_Foo _(1, 1, "Foo")
etc.

This way addition of new numbers would be localized to a small section
of the file.

I'm open to better suggestions. I just want a system that's not hard
to maintain and that uses the fact that we already have #defines for
the messages (so that we can avoid the gettext mess).

Rich