[MPlayer-dev-eng] New translation system

[Rich Felker]

On Thu, Nov 30, 2006 at 03:05:47AM +0200, Uoti Urpala wrote:
> The most important reason to replace the current translation system is
> that the language must be chosen at compile time. This makes the
> translations very impractical for binary distributions, eliminating much
> of the potential audience for translated versions.
> 
> Some features I consider important:
> 1 Must allow selecting language at runtime (as above).

Agree.

> 2 Should leave the English versions visible in the source and find the
>   translation based on those (plus optional context argument for non-unique
>   strings that might need to be translated differently in different places).

I disagree strongly with this condition. They're not in the current
source, and adding them only bloats things up. If we've lived this
long without English getting the special treatment of being in the .c
files we can live with it in the future.

> 3 Should allow loading translations from separate files and replacing them
>   without recompiling, both to make updating them easier and because including
>   all possible languages in the main binary would make it noticeably bigger.

s/Should/Must/.

> 4 Should work without extra work with formats that might differ between
>   machines such as PRId64.

This can be a preprocessing step when compiling the translation files
to binary format.

> 5 Outdated, broken or intentionally harmful translation files should not
>   cause crashes or security holes.

Unreasonable requirement. The translation system cannot be responsible
for knowing what a random function that processes format strings will
do with the string. Special-casing printf type would be possible but
would require nearly a complete printf reimplementation in the
translation system which is idiotic ridiculous bloat. Translation
files should be treated as part of the source/binary; as a user you're
responsible for ensuring that you don't download and use malicious
ones just like you're responsible for making sure you don't download
MPlayer from randomwarezsite.biz...

> It might be possible to wrap gettext in a way that achieves these (at
> least it seems setting the locale should be avoidable by using
> bind_textdomain_codeset() and dcgettext() instead of plain gettext()).

Iabsolutely and unconditionally object to anything involving gettext.

> Writing basic text lookup functions fulfilling the above conditions from
> scratch would be relatively easy too, and would avoid a dependency on
> gettext and any problems with its API. OTOH if a similar code-side
> interface can be implemented by wrapping gettext then all the details
> and tools it implements would probably make life easier for translators.

Using strings as keys for looking up strings is idiotic and plain
wrong, both semantically and in terms of implementation sanity.
Indices are numbers not strings. We code in C not PHP.

Rich