[MPlayer-dev-eng] New translation system

[Rich Felker]

On Thu, Nov 30, 2006 at 02:05:30PM +0100, Ivo wrote:
> On Thursday 30 November 2006 11:11, Torinthiel wrote:
> > On Wed, Nov 29, 2006 at 08:51:49PM -0500, Rich Felker wrote:
> > > On Thu, Nov 30, 2006 at 03:05:47AM +0200, Uoti Urpala wrote:
> > > > The most important reason to replace the current translation system
> > > > is that the language must be chosen at compile time. This makes the
> > > > translations very impractical for binary distributions, eliminating
> > > > much of the potential audience for translated versions.
> > > >
> > > > Some features I consider important:
> > > > 1 Must allow selecting language at runtime (as above).
> > >
> > > Agree.
> >
> > Without having to 'make install' anything.
> 
> You can set NLSPATH to point to the catfile of choice and you won't need to 
> make install.

Yes, this is standard and specified in the SUSv3 docs.

> > Right now ONE language resides in binary, and something quite similar to
> > English text resides in sources. IMHO it should be that sources stay the
> > same, and English messages reside in binary (so that it's usable w/o
> > installing).
> 
> That is more or less what happens when you use catgets(cat, set, num, 
> message). If there is no catalog or the number num is not present in the 
> catalog, message is printed (which resides in the binary).

Indeed. My idea was just that the English strings would remain in the
help header files only rather than the .c files. It would allow us to
continue supporting the current system of hardcoded translations, and
_also_ could allow the user to select which default translation is
hardcoded in the binary rather than always forcing English.... _if_
some minor scripting is done to support that at build time.

> > But then, there has to be any protection against accidental using of
> > wrong files. Say I change a string to use two %s instead of one (for
> > whatever reasons), than mplayer has to be save while translators update
> > their strings.
> 
> I do not think that would be feasible. If somebody changes the format of a 
> message (adds %s, %i, whatever) he must assure all translations are updated 
> accordingly, if only by adding the field if the person does not speak the 
> language; the translation maintainer can format/translate it properly 
> later.

No, the situation is just like now. If you change the format strings
in a message, you must ensure that old translated strings are not
used. Currently this is done by removing the old strings. With catgets
it would be done just by retiring the old message number and choosing
the next new message number (so that installed catalogs could not be
dangerous).

> > There's a serious problem with using numbers as indices: you need two
> > separate mp_msg-like functions. One for translated strings (that passes
> > numbers as indices), another for strings not meant for translation
> > (because we pass string then).
> 
> I don't see a problem here. Assume there is a global catd and one set of 
> messages:
> 
> nl_catd catd;
> 
> #define CATMSG(n, m) catgets(catd, 1, n, m)
> 
> ......
> /* random snippet from mplayer.c */
> 	if(how)
> 		mp_msg(MSGT_CPLAYER,MSGL_INFO,
> 				CATMSG(MSGTR_ExitingHow, "Exiting... (%s)\n"),how);
> 	mp_msg(MSGT_CPLAYER,MSGL_DBG2,
> 				"max framesize was %d bytes\n",max_framesize);
> .....

No, my intent was that it should be done without ANY changes to the .c
files. All calls to catgets should be in help_mp.h. :)

> One problem though, the gencat -H <headerfile> syntax is not portable. For 
> example, Solaris does not support the -H flag and neither does AIX. AIX has 
> runcat catfile msgfile though. Perhaps we should rely on our own 
> implementation of gencat. The msgfile syntax is pretty simple.

This is impossible because the binary format for catalogs is
implementation-specific (and this is a very good thing!). What we can
do is write our own preprocessing script.

Rich