[MPlayer-dev-eng] New translation system

[Rich Felker]

On Thu, Nov 30, 2006 at 11:40:37AM -0500, Rich Felker wrote:
> On Thu, Nov 30, 2006 at 06:04:01PM +0200, Uoti Urpala wrote:
> > On Thu, 2006-11-30 at 16:13 +0100, Attila Kinali wrote:
> > > You should strive to use a good performing design whenever
> > > you do something.
> > 
> > Yes - but not without understanding what is a "good performing design",
> > which doesn't equal neglecting everything but performance. What Rich
> > advocates seems to be a system where all design decisions are based on
> > performance considerations only, even when performance is irrelevant and
> > there are other much more important factors.
> 
> No, I advocate excellence in all areas. gettext is SHIT IN ALL AREAS.
> Performance is the least of my concerns here.

Just to give some clarification on this:

- code size: about 75% of the code size of my whole *@#$@#% libc to
  solve a problem that can be solved in less than 1k of code.

- complexity: interaction with locale, charset encoding, and all sorts
  of other nasties. also leads to ifdef hell.

- performance: O(log n) at best, plus cache thrashing. compared to
  O(1) with trivial constant and no cache-thrashing.

- build system nastiness: if you include gettext you need to either
  use autoconf or make sure you make a suitable config.h.

- requires building a tool at compile-time for the compiling message
  catalogs. this makes for more build system issues since there's
  another host/target system issue.

- portability: hey it's from the modern-day GNU folks. need I say
  more? i don't feel like analyzing it right now...

...? let's not stop there, extend this thread with your own reasons
why gettext sucks! oh here's one more that's key:

gettext was not designed from a standpoint of competent developers
looking at internationalization from an international perspective. it
was designed to aid english-centric developers in modifying their
programs to support translations with 'minimal effort'. thus the whole
thing with the _() macro around strings (almost invisible), with cheap
fallback for the english-only case at the expense of nasty bloat for
the non-english case. of course it was _not_ an easy drop-in because
of charset issues and locale issues and the fact that most sane
developers don't want to set locale due to bugs like the turkish i.
also, nowadays even english users pay the price of gettext due to the
use of 'translation files' to add utf-8 smartquotes and other gimmicks
to messages...

ok i'm rambling but the point: gettext was an ugly hack designed to
quickly port legacy apps to an international environment, rather than
to facilitate internationally-oriented development from the start.
it's outgrown its shorts, become a monstrosity, and we shouldn't be
taking any part in it.

Rich