[MPlayer-dev-eng] New translation system

[Uoti Urpala]

On Thu, 2006-11-30 at 23:25 +0100, Michael Niedermayer wrote:
> On Thu, Nov 30, 2006 at 09:40:38PM +0200, Uoti Urpala wrote:
> > - Having the actual string in the source is better (showing printf format
> >   letters readably in macros or enums would at least require inventing
> >   some custom syntax).
> 
> inventing that syntax need ~1minute so this point is IMO void and we dont
> even agree that using the english string be it "foobar" or FOOBAR as key 
> is a good idea to begin with i for one disagree, and IIRC there where
> others who disagreed ...

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.

> > - Doesn't require special steps to make a string translatable (as long as
> >   it's printed normally) or necessarily even agreement about what should
> >   be translatable. A translator could even provide translations for some
> >   "debugging" output if desired without adding lots of constants to
> >   the central repository.
> 
> well such a design would cause noticeable slowdown, because the slow string 
> key matching would have to be done for debug messages, think of some bitstream

No it wouldn't. There's no need to write the call as
msg(level_debug, translate("Debug message here"));
A better way is to write it as
msg_translate(level_debug, "Debug message here");
and the function would of course check the message level first.

> parsing or similar stuff which generates on the order of gigabytes of output
> per minute

Making mp_msg calls for that much unshown output is probably bad even
without any translation...

> so actually string based keys make the decission what should be translatebale
> more critical due to the slowdown potential if its done everywhere, OTOH

Not true as explained above. In the case you actually want to produce
gigabytes of _visible_ untranslated output and want to absolutely
maximize performance you can turn translation off.

> >   (or cause them to others). You can't even make a safe patch that adds
> >   a message and makes it translatable with an integer index.

> as long as these patches arent in svn no translation file will contain them

Yes they will if the files are indexed by the integer index. If the
patch adds the message at the next free index (which most patches mean
for inclusion in svn would do) it then collides with whatever message
that is added next.

> and IMHO we should not try to make it overly easy to fork mplayer, the
> more painfull it is to keep large changes in your private mplayer tree the
> more patches will get contributed back, we shouldnt shoot ourselfs in the foot

None of these changes make forking easier overall than it is now. This
doesn't seem like a very relevant concern.

> > - String keys don't accumulate cruft like integers which require leaving
> >   new holes in the index whenever messages are removed or significantly
> >   changed (or old translation files would break badly).
> 
> strings always have holes between them unless you use "a","b","c", ... and

Not "holes" since they're not supposed to form a consecutive list. Of
course you could claim the integer holes don't matter either if you
treat them as arbitrary hash keys in the translation files, but then
what advantage would they have? They'd just be a more obfuscated form of
key.

> using mplayer with old translation files opens a can of worms security
> wise, so iam definitly against that unless all strings are checked for 
> validity at runtime and this check gurantees that no secholes remain ...

I think they should be checked.

> furthermore my suggestion was
> static tabel[]={
> .[MSGID_FOOBAR]= "Foobar",
> ...
> }
> 
> so there are no numbers directly in the translation files and no holes

Are you now talking about translation files used at runtime? Note that
we were talking about translations that are loaded from separate files
at runtime with a system that allows the files to be replaced without
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.

Distributing translations as object files would be a bad idea IMO. It
would make the files completely architecture-dependent and unsafe from
security standpoint. If you mean distributing files in the above textual
form then that looks like it's just using an arbitrary string key like
'MSGID_FOOBAR' where using the English version of the message as the key
instead would make more sense.