[MPlayer-dev-eng] New translation system

[Rich Felker]

On Thu, Nov 30, 2006 at 07:28:10PM +0200, Uoti Urpala wrote:
> 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;

Well Michael and I both seem to be rejecting this, so good luck
pushing 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.

I mean in the gettext source. Standard procedure for using gettext is
to include it in your program since it is NOT standard except on GNU
systems.

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

I have no idea.

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

There's a difference between using english as your language and being
english-centric in that you design your program to make it the most
efficient for english-language use at the expense of nasty bloat or
other issues for non-english.

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

I know this, I was just pointing it out as evidence for the original
purpose of gettext.

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

With my proposed system, the user could in principle select the
compiled-in default at build time.

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

I wouldn't mind too much; however, using a language that the rest of
the developers don't understand probably isn't a good idea for
cooperation. The language of the source is unrelated to the language
of the messages however..

Rich