[MPlayer-dev-eng] New translation system

[mail at kraymer.de]

Michael Niedermayer wrote:
> Hi
>
> On Sun, Dec 03, 2006 at 07:50:59PM +0100, Roberto Togni wrote:
>> 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.
Ack. More on that below.

>> 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.>
> btw, speaking of translators, they probably should participate in the
> selection/design of a translation system ...
Ok, it might indeed be time to speak up..

>From the translators' perspective, IMO the following things are
important or at least desirable:

For maintainability, it's important to be able to check quickly if a file
is outdated/which messages are missing. At the moment, thehelp_diff.sh script provides that as well as the missing defines itself.
Currently there is now way to determine automatically if a translated 
define is up to date with the original, meaning: Consider a help file that
was translated once, then it is unmaintained for some time and there were
some changes in the English version. help_diff.sh won't show that the
translation is outdated and without going through all commits or
proof-reading the whole file you won't notice. Being able to do so would
obviously be a real improvement.
For translating it is nice to see the English original text. I guess
that's a plus for gettext implementations but speaking for me, the  define
names as they are at the moment are usually enough. Some kind of double
hash table where you would have to look up the original text at some other
place/other file (for integer based indices or such) would  be a pain, at
least if no tools are provided to ease the workflow.

Speaking about runtime language selection, I think that is a desirable
functionality. Recompiling MPlayer only for posting output (either for 
general help or bug reporting) is bad, especially considering people who 
don't compile MPlayer themselves in the first place.New packages of MPlayer could contain all languages, which is obviously 
good. Once more people start using MPlayer in their own language, they 
might be willing to report bad translations or even start to contribute.
So far my thought on this, I hope it helps.


Sebastian