[MPlayer-dev-eng] New translation system

[Roberto Togni]

On Thu, 30 Nov 2006 03:05:47 +0200
Uoti Urpala <uoti.urpala at pp1.inet.fi> 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.
> 

Probably we have different reasons, but I also agree that the
current system may be better.
Please note that my comments are from a developer point of view (even
if I mantained the Italian messages for some time); translators may have
different priorities.

> Some features I consider important:
> 1 Must allow selecting language at runtime (as above).

Ok, even if i don't care much. May be useful to let people send
bugreports with English messages.

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

Very important, that's what i dislike most about our current system.
Messages in the source make understanding the code easier, without
adding redundant comments, "remind" you to update the text if you
change functionality, and let you quickly check that format strings
and variable types match.

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

Agree.

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

Hmm, I  still think that translation files should be compiled for the
right target together with the code, ie I don't care if the compiled
translation for linux-ppc is different than the file for windows-mingw.

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

Complex.
Ok for outdated files, both compiled or in source form. Probably
checking that the format specifiers match with the English source
(type, number and order) is enough.
Overkill for intentionally harmful, else the same should be true
also for binary codess, dlopened libs, fonts, ...


Other important features:
- must work at least for English messages (or for the selected
language if we allow to compile without english) without requiring
external files at runtime
- should have some versioning of compiled translations, so that if I
have an installation of mplayer but i run a newer development binary it
doesn't try to load old translation files

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

I don't care what is used for it as long as the files are in a format
that is ok for the translators (easy to translate, possibility to
update only new/changed strings, ...).
If all conditions are equal, I prefer a native implementation so that
it can easily work on all supported system.

Performance is not a problem imho, most messages are printed before
playback starts, and the policy is that everything that is printed
every frame/packet/... must be above V level (V level and above are
untranslated anyway).

Ciao,
 Roberto