[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