[MPlayer-dev-eng] New translation system

[Michael Niedermayer]

Hi

On Fri, Dec 01, 2006 at 01:46:02AM +0200, Uoti Urpala wrote:
> 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.

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*/


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

no, there would be no 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.

you would have to break into mplayerhq first

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?)

and you first should think about and awnser the question
why should a translation file not be in mplayer svn?
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

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