[Scummvm-devel] ScummVM translations for small devices

Thierry Crozat criezy at scummvm.org
Mon Aug 2 21:15:55 CEST 2010


Hi Team,

I was wondering if I need to change the way translations are handled by ScummVM. Currently the po2c script is used at compile time to generate C code and this means all the translations are included as static arrays in the executable. I evaluate the current size to be about 50 Ko in total and as new translations are added this will grow.

I suppose this might be an issue with small devices where the amount of memory is limited, but I am not familiar with such devices. So my first question is: are translations currently enabled for these devices or do we want to enabled them? If the answer is yes, do we need to change the way translations are handled?

One possibility would be to ship the po files with the executable (together will all the data files) and to replace the parsing done by the po2c script by a parsing at run time (e.g. when starting ScummVM) to list the available translations and load the one currently selected. Therefore there would be at most only one translation loaded in memory at any time.

An intermediate solution would be to keep the po2c script to generate the static arrays of available translations (which is small) but not the translation arrays. Therefore there would be no need to search for and parse all the translation files at startup (to list the available translations). Only the current translation would be loaded if the translation file can be found. This translation file might be either directly the po file or a data file in a format easier to read and generated by po2c. This solution implies that the list of translations is fixed at compile time (I am not sure if this is an advantage or an inconvenient), but startup might be faster on devices where looking for files and/or reading files is slow. Also translations listed in the static array might actually not be found if they have not been installed in the correct place (is distribution a problem on some platforms?).

What do you think? Do you have better ideas?

If I don't hear from anybody I will understand it as meaning that memory is not an issue and the current implementation is fine. So if it is not, please reply.

Thierry



More information about the Scummvm-devel mailing list