[MPlayer-dev-eng] New translation system

[Ivo]

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.

MPPATH=`pwd`
NLSPATH=$MPPATH/help/help_pl.cat
export NLSPATH
./mplayer

Or if we decide to split it up in directories, just like /usr/share/locale, 
you can do:

NLSPATH=$MPPATH/help/pl/%N
export NLSPATH
./mplayer


> > I disagree strongly with this condition. They're not in the current
> > source, and adding them only bloats things up. If we've lived this
> > long without English getting the special treatment of being in the .c
> > files we can live with it in the future.
>
> 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).

> > Unreasonable requirement. The translation system cannot be responsible
> > for knowing what a random function that processes format strings will
> > do with the string. Special-casing printf type would be possible but
> > would require nearly a complete printf reimplementation in the
> > translation system which is idiotic ridiculous bloat. Translation
> > files should be treated as part of the source/binary; as a user you're
> > responsible for ensuring that you don't download and use malicious
> > ones just like you're responsible for making sure you don't download
> > MPlayer from randomwarezsite.biz...
>
> 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.

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

> OK, here's a rough draft of my proposal using catgets. Someone better
> knowing catgets interface tell me if it's reasonable.
>
> We have our current .h files. Some processing tools (custom) do several
> things with them.
>
> First, create a single help_mp.h, as now, only now with unique
> identifiers (more on that below).
>
> Second, it creates a .c file with a table of all English strings
>
> Third, for each translation it creates a catalog, with translated text
> and unique ID.

As I see it, help_mp-en.h has to be converted to a msgfile:

$quote "
$set MSGTR_
...
ExitingHow "Exiting... (%s)\n"
...

Now you have help_en.msg.

Create catfile and header file:

gencat -H help.h help_en.cat help_en.msg

and for translations:

gencat help_pl.cat help_pl.msg
etc...

Or put everything into separate directories directly (avoids the need to 
rename all help_*.cat files when doing make install), called by their 
locale name as they will be installed in /.../locale and all files are 
named help.cat and help.msg, i.e.

mplayertrunk/help/en/help.{cat,msg}
mplayertrunk/help/C --> en
mplayertrunk/help/pl/help.{cat,msg}
etc...

#Include help.h in mp_msg.h, open catalog (help.cat) when mplayer is started 
and everything should run smoothly.

The above is just an example. It's probably better not to choose help.cat as 
the generic name, as the files will be put somewhere globally and might 
collide with other help.cat files. Better call it mplayer.cat or something.

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.

--Ivo