[MPlayer-dev-eng] New translation system

[Michael Niedermayer]

Hi

On Thu, Nov 30, 2006 at 09:40:38PM +0200, Uoti Urpala wrote:
[...]
> 
> > 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).

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


> - 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
parsing or similar stuff which generates on the order of gigabytes of output
per minute
so actually string based keys make the decission what should be translatebale
more critical due to the slowdown potential if its done everywhere, OTOH
a simple O(1) array lookup or id==MSGID_DONT_TRASLATE can always be done if 
we want ...


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

huh?
person1 adds mp_msg() adds entry to the enum adds english entry
no problem

person2 adds mp_msg() adds entry to the enum adds english and german entry
no problem

as long as these patches arent in svn no translation file will contain them
if they are applied to svn their position in the enum list becomes official
again no problem


and about custom versions, they can and should use their own range of numbers
for their private messages
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


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

furthermore my suggestion was
static tabel[]={
.[MSGID_FOOBAR]= "Foobar",
...
}

so there are no numbers directly in the translation files and no holes

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is