[FFmpeg-devel] GSoC with FFMpeg waht a combination!

[Uoti Urpala]

On Sat, 2008-03-22 at 13:29 +0100, Michael Niedermayer wrote:
> On Sat, Mar 22, 2008 at 12:37:39AM -0400, Ronald S. Bultje wrote:
> > Will you accept patches that add internationalization-support to
> > ffmpeg/lav*?
> > 
> > It's high on my fairy-list.
> 
> Sure just keep in mind that you will be flamed if this is done with gettext :)
> The reason being
> * gettext duplicates english strings all over the place

I'm not sure exactly what gettext duplicates, but how much space would
this waste? It'd need to have many copies of every string to make a
difference for FFmpeg.

> * gettext uses strings as keys (very inefficient requireing O(log n) lookups)

O(log n) is NOT inefficient for text lookups! Also your claim that using
strings as keys would necessarily require O(log n) lookups is not true.
Hash tables require O(1) on average, and your own suggested method needs
an equal lookup. The only calculation your suggestion can save is
calculating the hash at runtime, which is O(length of string) and thus
cannot affect O() behavior (assuming the result is of similar length and
has to be output).

> Requirements:
> * getting a string must be O(1)

Nonsensical requirement. Being so fast that further speedups make no
difference is more than fast enough, and for translations that does not
require O(1).

> * no duplicate strings in the final binary files

I assume you mean that the English strings are not used at all when
using a translation. This is also a nonsensical requirement, as the
total amount of translated text is not large enough to justify it. There
are easier ways to reduce FFmpeg binary size (and by a larger amount)
than the complexity required for this.

> * uncoordinated additon of new keys
> * uncoordinated additon of new translated strings
> * easy to use for both devels and translators

These are fulfilled by doing lookups based on the English string.

> The requirement of no duplicate strings leads to integers as keys.
> The requirement of O(1) and uncoordinated additon of new keys leads
> to the use of a hash table and 64bit hash values of 
> default (english/in source) strings as keys.

But you chose those requirements incorrectly, so these consequences are
wrong too.


You really need to learn that concentrating obsessively on performance
alone is not the right way to solve all development questions. Other
factors are much more important for a translation system.