[MPlayer-dev-eng] liabf/af.c translatables to help_mp

Rich Felker dalias at aerifal.cx
Sat Mar 18 06:27:51 CET 2006


On Thu, Mar 16, 2006 at 05:51:31PM +0100, Alex Beregszaszi wrote:
> Hi,
> 
> > > > What about designing a similar system? Code is better than just ideas, I
> > > > will send a small implementation.
> > > 
> > > Attached is a lame implementation.
> > 
> > Because a good system that's completely compatible with MPlayer's
> > existing method of using #defines for messages (rather than including
> > the literal strings in the source files) already exists and is part of
> > posix and is available on every system that has gettext. It's called
> > catgets. Support for it has already been discussed and is planned for
> > the not-so-distant future.
> > 
> > (catgets also does not have the performance penalty of hashing strings
> > or strcmp'ing them to find the translated message like gettext and
> > your system do)
> 
> You wont get performance penalty once youre not hurting yourself with
> translations. If mplayer were mplayer-g2 and a library, we wouldnt even
> consider this translation mess. A player application using the library
> could do whatever it wants, including translation mess.

Huh? This is senseless flaming. Even if the code were a library we
would still have a player too, not just a stupid library. People don't
watch movies with libraries. They watch movies with players.

> Also note that "my system" was writte in 5 minutes and I dont like that
> catgets approach, it is basically the same as our macroidiotism but with
> support for external translation files.

It's the only correct way to do translations. Anything that uses the
English message as a key to lookup the translated message is both slow
(hashing plus O(log n) hash lookup at best, O(n) strcmp in your
implementation) and biased towards English-language users (since
everyone else gets the slowdown at runtime for the sake of making
things slightly easier for developers). catgets is well-designed and
stays out of the user's way and the developer's way, especially when
it comes to LC_CTYPE. gettext and other string-key-based systems are
bloated GNU stupidity.

Rich




More information about the MPlayer-dev-eng mailing list