[MPlayer-dev-eng] New translation system

[Uoti Urpala]

On Fri, 2006-12-01 at 02:22 +0100, Michael Niedermayer wrote:
> On Fri, Dec 01, 2006 at 01:46:02AM +0200, Uoti Urpala wrote:
> > Of course you can invent some syntax in 1 minute but how readable will
> > it be? You can debate the readability of some macro/enum naming scheme
> > but claiming it will be so readable that there is _no_ advantage at all
> > in having the real string there isn't believable.
> 
> your suggestion: "Audio: %d:%d,%f Video:%d:%d:%d foobar:%8d %s"
> 
> my suggestion:   MSGID_StatusLine /*Audio: %d:%d,%f Video:%d:%d:%d foobar:%8d %s*/

Your suggestion leads to clutter and significantly worse readability if
you try to actually use that in the sources.

mp_msg(MSGT_CPLAYER, MSGL_STATUS, "SUB: Removed subtitle file (%d): %s\n",
       v + 1, subd->filename);

vs

mp_msg(MSGT_CPLAYER, MSGL_STATUS, MSGTR_RemovedSubtitleFile, v + 1,
       subd->filename); /*SUB: Removed subtitle file (%d): %s\n*/

Plus you've now further increased the work needed to make strings
translatable.

> > recompiling - do you not want to support that functionality? If you mean
> > distributing translations as compiled object files produced from files
> > like the above then they would have hardcoded numbers and holes.
> 
> no, there would be no holes

Seems you're thinking of a more limited system where translation files
must always be compiled together with the binary used. Yes in that case
you can avoid the holes at the cost of other functionality (more about
that below).

If you want to use object files for the translations how would they be
selected? Remember that one of the primary reasons for wanting to change
the system is that compiletime selection makes the translations mostly
unusable for binary distributions. Would every language always be linked
in the binary? Or would you try to use some dynamic object loading for
them?

> no seriously i see no sense in custom translation files which are portable
> between all mplayer versions and secure (its basically lots of bloat and
> work or is there some big advantage iam unaware of?)

Separate translation files are desirable to allow users to load just the
one they want, and it's better not to have total failure if the version
of the translation file and binary aren't identical. I think it also
makes sense to allow translations for released versions to be updated
later and distributed separately.

The "lots of bloat and work" claims aren't true. I'll probably make a
sample system so that can be discussed more objectively.

> and you first should think about and awnser the question
> why should a translation file not be in mplayer svn?

Eventually good translation files probably should end up there. However
that does not mean they should be created in svn, or that compiling svn
versions should be the only way to update translations.

> should users go and hunt down a uptodate translation file for their
> native language? and to make that penalty for the user possible
> we should bloat up the system and then try to patch up the secholes this
> design causes?
> 
> personally id say either go with a simple design like i suggested or catgets

I think you're mixing up different issues here. You're using the extra
complexity of secure and distributable translations to argue for
integer-based translation indexing even though those are separate issues
(except that integer indexes fail worse in the distributable case).

You can have a very simple system using the English strings as keys.
Compared to catgets or other integer-indexed methods it gives more
readable sources, no special steps to make strings translatable and more
freedom for translators to choose what to translate.

Your remaining objections in this thread seem to be against the part
making the translation files safely distributable individually. I think
it's not as complex as you claim.