[MPlayer-dev-eng] Sample translation lookup implementation

[Uoti Urpala]

On Wed, 2006-12-06 at 22:57 +0100, Michael Niedermayer wrote: 
> On Wed, Dec 06, 2006 at 09:53:00PM +0200, Uoti Urpala wrote:
> > It can not have "significantly lower" space and complexity requirements
> > unless the string key implementation first has such "significant"
> > requirements which could then be lowered. 
> 
> no you dont need something to be significnat to reduce it significantly
> and if i make some code 10% faster or make it use 10% less memory then
> thats significant for me

Are you being serious? You're saying that printf("OK\n"); is
significantly more efficient than printf("Success.\n"); ?
Of course that is true in a trivial sense but if you use such
"significant efficiency" claims as arguments about design then they
should better be about some real effects on program behavior.

> , you dont seem to want to accept that you are
> wrong

Performance differences between integer and string keys are irrelevant.
That's a fact.

> , and that string based keys have their price that fine but dont
> twist the facts please, duplicating the strings all over the place needs
> more space like it or not

They do use some more memory when translations are used, but not so much
that it'd be a problem. Your claims about complexity are just false.

> > Can you really honestly claim
> > the sample implementation I gave was that complex?
> 
> your sample implementation doesnt conform to the coding rules besides that

Could you try to find some real arguments instead?

> its not useable (= its incomplete) unless you expect people to use a hex
> editor to write the translation files so the question of complexity is
> unawnserable (what you send has medium to low complexity but it is not
> a complete system ...)

It does implement a complete string lookup mechanism. If something would
create integer-indexed translation files then it can easily create
string-indexed ones in this format, so string keys cannot have higher
complexity. The complexity of practical translator tools depends on how
much translator work they try to automate; minimum complexity probably
isn't a good goal for those (external) tools.

> [...]
> > > simply replace every string by a unique integer, 64bit if needed, a simple
> > > compare is O(1) instead of O(strlen), space too is 1 vs strlen, and its of
> > 
> > This is all completely irrelevant. 
> 
> why dont you just say that every argument anyone says is irrelevant before
> he even says it?

I judge the arguments based on their content, and I don't always know
what they're going to say in advance.

> > practice. When only printed strings are translated the cost of printing
> > them dominates anything done during the translation step.
> 
> then why not just call grep to find the matching string?

Very funny. Now are you seriously trying to dispute this fact or not?

> > > course simpler as its constant length
> > 
> > Using macros everywhere a translatable string occurs is "simpler" than
> > the example code I posted? That code included everything needed for
> > string lookup.
> > 
> > > now how to assign integers so they are no conflicts?
> > > random will do, its unlikely that a conflict will happen before we use
> > > 2^32 different messages and if thats not good enough then simply using
> > > the IP address of whoever adds the message + the time or such would
> > > gurantee that no conflicts can happen, and conflicts are trivial to
> > > resolve anyway just detect and select another integer ...
> > 
> > If you use random integers what advantage do those have over the English
> > strings? 
> 
> ive said that already a few times, O(1) vs O(strlen) space and time and

Time for printing messages is dominated by output for both translation
systems; any differences in translation lookup do not matter. Space is
O(strlen) in both cases (unless you intend the system to somehow work
without having the strings for ANY language...).

> furthermore ive also said that this is just an example which is supperior
> to string keys not that it would be a good choice its just better then
> what you propose

As (again) explained above the "advantages" are insignificant and do not
matter in practice. The disadvantage of requiring integers or macros for
them in every single translatable mp_msg call matters a lot more in
practice.

> > Lookup is similar, the trivial performance differences do not
> > matter at all in practice. On the other hand you need to do extra work
> > generating those integers for all translatable messages, and the sources
> > become less readable when you use those integers or macro names for them
> > instead of the real messages.
> 
> MSG("error file %s not found\n", 0)
> the 0 is needed to take care of the case where the same string needs to be 
> translated differently

You do need a version which takes a "context" argument, but of course
you do not need to use that for every single message (and it would not
be used for the above message). There are currently 3 messages which
have more than one translation in German: "Hue", "Play" and "No stream
found.\n". Using a separate with-context version for those is enough.

> vs.
> 
> MSG(MPMSG__ERROR_FILE_s_NOT_FOUND_n)
> 
> or a million other ways to design it ...
> i really dont see how thats less readable

I do find that significantly less readable, and I would be surprised if
I was the only one with that opinion. Besides readability you have the
requirement to move the strings to a different file to make them
translatable and writing the macro there to replace them (plus if your
earlier suggestion is used then also extra work to generate the integer
index). Both of those issues matter a lot more in practice than the
"advantages" of integer indexes.