[MPlayer-dev-eng] New translation system

[Rich Felker]

On Thu, Nov 30, 2006 at 07:01:21PM +0100, Michael Niedermayer wrote:
> > There are the
> > XSI extended format strings (%1$d etc.) as well as issues like
> > specifying the width and/or precision as arguments (%*.*s). Anyway the
> > greater problem is that this is a _runtime_ issue, not a compiletime
> > issue.
> 
> and where is the problem with checking all strings during init at runtime?

Well, there's still the complexity of matching the printf behavior,
and you don't even know which strings will be used with printf and
which will be used literally, etc. without extra flagging.

> > What you described is just the obvious implementation of catgets,
> > except that the translations are in a mmapped binary file containing
> > those data structures instead of in the mplayer binary.
> 
> hmm i dunno catgets except 5min RTFM, but it apparently lacks a requirement
> for using consecutive numbers so its more complex (=needs hashtab or binary

It doesn't require consecutive numbers, but it allows the system to
place an upper limit on the number. NL_MSGMAX is only required to be
at least 32767 and NL_SETMAX is only required to be at least 255. IMO
the intent is that it be implemented as an array of offsets, at least
with a little cleverness.

> search) it also if non consecutive numbers are used doesnt seem to support 
> enumerating strings and iam unsure how to actually use it, TFM seems to

There's no intentional support for enumerating strings. As long as
your project has reasonable policy for assigning numbers you can just
iterate all numbers in the assigned range, but I agree this is
somewhat suboptimal.

> suggest that every translation file either needs hardcoded numbers or needs
> to have a entry for every translatable string, both obviously are problematic
> ....

catgets returns the default string passed as an argument if the lookup
in the message catalog fails.

> also ive a few questions about catgets
> can it support sane fallbacks? i mean if theres no de_at then de would be
> used and if that isnt available too then en?

This is an implementation quality issue. Generally I would expect
implementations to fallback to de if de_AT is missing entirely, but
not to fallback for individual messages/merge catalogs.

> do all systems support catgets? cygwin? mingw?

It's in SUSv3. mingw probably doesn't have it. We could surely provide
a fallback implementation.

> and what for example about something like
> printing the translated message with the untranslated in () when --debug or
> --bugreport is used?

This is quite problematic because you can't duplicate the args for
format strings... at least not without some major changes to all the C
files.

> with my suggestion it would be trivial to change
> the strings from C, with catgets this doesnt seem possible, a macro and
> a complete recompile would be needed ...
> and most important, why use catgets if plain ansi C can do the job?
> we also dont use a database or xml if we dont have to?

Largely I agree with you. If someone can write a clean light
implementation roughly the same as a good catgets (in terms of
simplicity, big-O [including cache lines touched], etc.) that's
probably better than just using catgets. I also like your idea of
having the translations in the binary, but I'm sure some users would
prefer them to be external...

BTW ansi C alone can't do it efficiently unless they're in the binary
since it lacks mmap.. :)

Rich