[Scummvm-devel] Proposal for translation

[Max Horn]

On Fr, Juni 15, 2007 13:25, Jordi Vilalta wrote:
> Hello,
>
> I've been thinking about making ScummVM localizable. I remember seeing
> a discussion about it here:
> http://forums.scummvm.org/viewtopic.php?t=3734 but maybe I missed some
> other threads or sources of information.

https://sourceforge.net/tracker/index.php?func=detail&aid=887623&group_id=37116&atid=418823


>
> There are two big fronts here: the internal messages translation and
> the way to show them.
>
> As I understand it, it seems the current GUI implementation isn't
> capable of showing different character sets, so it would need work on
> the font rendering code to be able to show any translated text. It
> would probably need to integrate freetype or something like that
> (while allowing better looking fonts with antialiasing and being able
> to show internationalized game names and file paths).

Indeed. And so that we do not just restrict to listing the positive points
(which I all agree with), here are some of the other effects this has:
* Added  dependencies (FreeType, and maybe more, like libicu)
* Increased resource requirements (memory, CPU) for advanced rendering
* Increased code size (added libs, new binding code, code to deal with the
localizations internally)
* increased data size (localized texts, additional fonts)
* added maintenance work (you can't just quickly add a message dialog box
anymore, you have to worry about doing it properly "localizable")
* you need lots of localizers
* additional Q&A work needed to test localizations.

Of course all of these can be dealt with, in some fashion or the other; I
just ask that none of those are forgotten or downplayed. Esp. the resource
requirements could pose a serious problem when it comes to some of our
ports. Hence any code change in this direction needs to be carefully
evaluated and coordinated with our porters. Ideally, the code&data changes
would be slim enough to work everywhere, but if not, the old smaller code
would have to be kept around (and maintained!) just for these ports.


> I have no idea about font rendering, so what I'm really asking here is
> someone who could work on this stuff, or at least someone who could
> guide me with this when I got to step on this.

Good luck with that.

>
> For the messages translation I got some basic ideas. I've been
> thinking on using the gettext system as a base. It's very wide spread
> and well tested in open source projects. It handles character set
> conversions, and uses the widely known .po file format for
> translations. It would help a lot the translators since they probably
> are familiar with translating .po files.

While I am not that fond of gettext, what you say about it certainly is
true. Of course portability has to be kept in mind. Can one build binaries
with gettext on all our targets, or only on those which provide sufficient
command line tools? How much does it increase our binary size? What impact
does it have on memory/CPU usage?


>
> The gettext library could also be linked statically, but it would
> still need the external translation files.
>
> For embedded systems, I've found a tool that may be useful:
> http://www.triptico.com/software/po2c.html
> It would allow to create a C file which contains all the translations,
> needing no external files at runtime and giving a similar api to
> gettext.

There are *many* more tools out there for both localization and
translation needs. It would probably be a good idea to first compile an
overview over some of them and then carefully evaluate the list.

[...]

 So my idea is to implement the translation system as two different
> backends, one based on gettext, for desktop usage, and another one
> based on the po2c conversion for limited systems, so it could be
> chosen for each platform.

That would be possible, but I would *greatly* prefer if there was only a
single system to use -- if that's sanely possible, that is. Maintaining
two systems like that means a lot of work. You always have to check all
your changes against both systems for example. Q&A gets harder, too,
because you have to perform all tests at leat twice now.

>
> This is all for now. I know I'm a bit biased towards gettext and
> utf-8, but it's the best I know for these purposes. Please let me know
> about your opinions and correct me if I'm wrong with something.


If I didn't have to worry about small ports, I'd jump for freetype 1/2,
libicue and UTF-8 at any time. As it is, though, if I have to choose
between localization, and support for lots of ports, my choice is crystal
clear w/o even one second hesitation...

If can have both, that would be nice, but only if the solution is
maintainable. I am scared of something like the "SDL OpenGL backend"
happening again -- somebody writes a quick patch, it works "good enough",
but doesn't really scale well, problems start accumulating, but nobody is
around to properly maintain and enhance the system overtime, so it start
rotting until we have to pull it again one day.

So, let me stress it one final time: I'd *love* to have localization -- if
we can afford it sanely.

Bye,
Max