[MPlayer-dev-eng] New translation system

[Uoti Urpala]

On Thu, 2006-11-30 at 19:10 +0100, Reimar Döffinger wrote:
> It may have much less weight, but it does have a weight. My main reason
> is the "experience" that string handling in C almost always results in a
> mess which should be avoided.
> I somewhat prefer "you can't code it wrong" solutions, and Michaels idea
> is quite similar to what I had in mind first...

If you mean the string handling for translation lookup I can implement
that part myself (and it won't be a mess).

> > so far the only arguments expressed against string indices (not against
> > gettext specifically, which certainly does have valid arguments both for
> > and against) have been Rich's performance arguments which do not make
> > any difference in reality.
> 
> Not really, he also mentions that it might make hard keeping the current
> systems as a fallback, the problems of extracting the to-be-translated
> strings,

I don't remember him mentioning those arguments in the current
discussion... Anyway gettext's tools should be usable to extract strings
(even if gettext itself is not used in MPlayer), and even without tools
I don't see how extracting them would be worse than in the proposed
alternatives. Translators seem to "extract" most strings even now, it
just requires more work now than adding the English text to a file. At
worst the difference would be that the source doesn't directly show
whether the string has already been added to the template list of
strings one might want to translate.

> and (I think) that messages in the code means that 1) code will
> be cluttered with overlong strings or 2) developers make the strings
> extra-short and thus the messages hard to understand for users.

Of course developers would still be free to have strings as defines
elsewhere, but I doubt many would really prefer that. Looking at current
help_mp-en.h there are quite a few strings that have names longer than
the strings themselves.