[MPlayer-dev-eng] New translation system

[Uoti Urpala]

On Thu, 2006-11-30 at 12:08 -0500, Rich Felker wrote:
> On Thu, Nov 30, 2006 at 11:40:37AM -0500, Rich Felker wrote:
> > No, I advocate excellence in all areas. gettext is SHIT IN ALL AREAS.
> > Performance is the least of my concerns here.

I am certain that the translation system should work by lookup based on
the English strings; I'm not sure whether gettext specifically should be
used. I could write a relatively simple system that I'd be happy using
from the code side, but I'm not going to write a replacement for all
gettext functionality and related tools. And if translators prefer those
and as a result there are more translators/better quality translations
then that would be more important to the people who use translations
than any gettext "bloat" problems. I'm not familiar enough with gettext
to decide for sure whether I'd want to use it.

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

I'm assuming the interaction with locale can be avoided even with
gettext (dcgettext() seems to do that). What "ifdef hell" are you
talking about? Everything directly related to gettext should be doable
in one file, and I don't see how even that would have many ifdefs.

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

There's no significant performance difference. Hashes give O(1), and
calling even O(log n) "different big O" is disingenuous when there's no
chance n will ever exceed a million.

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

I haven't looked at gettext build issues myself, but I don't consider
your word on this too reliable either...

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

Aren't the catalogs in gettext platform independent? It shouldn't be
necessary to regenerate them at build time if you don't want to.

> 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

As opposed to developers who use all languages equally in the middle of
developing the program???

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

gettext doesn't require using the '_' macro name. Using English as the
default is the only sane choice (or generally picking one language as
the default in the sources, maybe you could use something else in a
national project).

If you want a "non-english-centric" project which doesn't discriminate
against all those poor oppressed people who think it's not fair for
English to be a special default then I can start using Finnish in
variable/function names and comments...