[MPlayer-dev-eng] New translation system

[Uoti Urpala]

On Thu, 2006-11-30 at 19:15 +0100, Michael Niedermayer wrote:
> On Thu, Nov 30, 2006 at 07:37:20PM +0200, Uoti Urpala wrote:
> > Using integer indices has practical drawbacks;
> > so far the only arguments expressed against string indices (not against
> > gettext specifically, which certainly does have valid arguments both for
> > and against) have been Rich's performance arguments which do not make
> > any difference in reality.
> 
> ok here are some arguments
> * slower (this does matter if there is alot of text output, i dunno if there
>   are any cases where there is alot of translatebale output though as higher
>   level debuging stuff generally isnt translated but still ...)

There's not that much translated output, and if the output is either
drawn on screen or printed to a terminal then the cost of that by far
exceeds the cost of translation. If you redirect output to a file and
print huge amounts of translated text then maybe you could measure a
difference (at least with simplest lookup methods) but that isn't a very
relevant scenario.

> * if the english string is used as only key then there is the serious problem
>   that the same string might depening on context need different translations

For that you'd have an optional context argument which is ignored when
"translating" to English but included in the lookup.

> * also if strings are used then these will end in the object files and
>   depening on linker and compiler ill likely get duplicated all over the
>   final binary increasing its size

Not sure what you mean by this if not the same as the following point.

> * if english isnt wanted then your out of luck space saving wise, as the
>   strings are hardcoded all over the place

Yes you do have English copies of the strings even if you only want to
use a translation. I don't consider that to be a serious problem. If you
want a "space-saving" version you can only include the common messages
in the translation and let it fall back to English for the obscure ones
(though I doubt there are many people who would want to optimize this).

> * and a pretty important one how do you actually find a turkish string from
>   an english key? do you have a table with the english and turkish string
>   pairs if so the english keys would be dupllicated once for every language

The idea is that the translations would be in separate files and only
one would be loaded to memory at a time (I think you're the first person
in the discussion who assumes a system where the binary would contain
multiple translations).

> OTOH what advantage does a string-key have?
> i cant see any, if you want the string in the source then a preprocessor
> macro or enum whos name matches the string will do too

- 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).
- 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.
- Integer indices require a central list, which becomes more problematic
  when translations can be distributed separately. With them anyone
  adding translatable messages in a custom version would face problems
  (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.
- 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).