[MPlayer-dev-eng] New translation system

[Uoti Urpala]

On Wed, 2006-11-29 at 20:51 -0500, Rich Felker wrote:
> On Thu, Nov 30, 2006 at 03:05:47AM +0200, Uoti Urpala wrote:
> > 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.

They're needed anyway to support translations which do not exactly match
the binary (to display the English version). With separate translation
files supporting that is important.

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

Invalid argument. We've lived with all kinds of known-broken things;
that doesn't mean they should not be fixed. Also having the translations
in separate files means there should now be a non-translated fallback
version.

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

If by "compiling" you mean something done before runtime, no; the
translation files used at runtime should not be architecture-dependent.

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

It is doable without too much trouble and a useful property to have, so
in no way an unreasonable requirement.

>  The translation system cannot be responsible
> for knowing what a random function that processes format strings will
> do with the string.

Since printf is the most likely source of problems handling that in the
translation system is enough. For those (rare) cases where the code
relies on other assumptions about the strings it's reasonable to say
that it must check them directly. Are there any such cases in current
MPlayer? I guess assumptions about maximum length would be most likely.

>  Special-casing printf type would be possible but
> would require nearly a complete printf reimplementation in the
> translation system which is idiotic ridiculous bloat.

It requires recognizing formats, not reimplementing their behavior.
Calling that "idiotic ridiculous bloat" is itself ridiculous.

>  Translation
> files should be treated as part of the source/binary; as a user you're

"should" why?

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

Completely baseless drivel.