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

[Ronald S. Bultje]

Hi,

On Sat, Mar 22, 2008 at 7:19 PM, Michael Niedermayer <michaelni at gmx.at>
wrote:

> On Sun, Mar 23, 2008 at 12:33:04AM +0200, Uoti Urpala wrote:
> > 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.
>
> I would estimate that gettext needs roughly twice as much disk space as a
> integer based system and about 3 times as much in memory
> (english string in _() and as key as well as the translated string)
> The disk space matters only for embeded systems of course. There it can
> matter a lot though, especially with few codecs and many languages.


As you no doubt know, embedded systems ship only a few languages, i.e. those
within the region in which that particular regionalized version of the
product is sold. For the same reasons, your DVD player did not ship with a
Thai, Greek or Tunesian manual, but only a German and an English one.

Shipping is easy, you simply pick the .po/.gmo files that you want.

As for the .gmo file size, why don't you fix gettext() upstream? I suppose
it's the same reason you're not fixing upstream gcc, libc, etc.? Please, be
reasonable. If this were for a pixel operation, I'd agree, but this is for
UI strings, it's not at all performance-critical.

Ronald