[Scummvm-devel] Improving translation support in ScummVM

[Jordi Vilalta Prat]

Hi,

2010/6/24 Johannes Schickel:
> On 06/24/2010 12:25 AM, Thierry Crozat wrote:
>> Hi all,
>>
>> The introduction of translations is a great step forward, but with it some issues have crept up. I am looking for ideas or suggestions on how to solve some of these.
>>
>> The first one is the language selection in the GUI. The current list of language locale (e.g. ru_RU, de_DE, fr_FR) is not very user friendly. I can work on changing this, but before that we need to decide what we want to see in the GUI.
>> * Can we drop the country and just list language names (e.g. "Russian", "German", "French") or do we want to accept translations in the same language but different countries (e.g. "French (France)" and "French (Canada)")? I would be in favor of displaying only the language.
>>
>
> We should at least definitely keep the language codes as internal data,
> else it's hard to auto setup the language based on the setup locale for
> example. What could be done on the other hand is to extract the language
> string from the .po file in tools/po2c and store it in the same
> structure as we also do currently with the charset. That will require
> some perl knowledge (and I also propose to update to the development
> po2c script, which also uses a code formatting more similar to ours),
> but I guess that's not too hard to achieve.

I've just looked at my local changes from the last time I touched the
translation patches (many months ago) and I see I already had this
implemented, but I just didn't complete it since I was told po2c was
not the way to go. I'll try to merge it with the current code, because
it seems there have been some changes to the version I last uploaded.
I'll have a look at the development version too.

> Along with it all the tables in the po2c script's output could be made
> const too....

I'll change it too.

>> * In which language should we display the language string? Always in english (e.g. "English", "French", "German") or in the native language for that string (e.g. "English", "Français", "Deutsch")? Maybe we would have an issue with the later as it means we might need characters that are not supported by the encoding of the currently set languages (e.g. the 'ç' character for french or the cyrillic characters for Russian). Maybe we can suppose everybody will know english just well enough to find the language he wants if the list is in english.
>
> I guess English would be best due to our font limitations, of course for
> external translations we can't assume what they specify in case we do as
> I proposed above :-).

I think the English name should always be there. An alternative could
be showing the ASCIIfied translated name (as Max proposed) together
with the English name. Example: "French / Francaise". Anyway, this
should be specified by the translators.

> 2) We definitely lost all the ability of format type checking (%d), due
> to the use of the "_(x)" etc. macros.

When USE_TRANSLATION is undefined, the _(x) macros are defined as x. I
think that will allow the normal type checking. If we want to keep an
eye on this type of errors we could setup a new buildbot target to
build with translation disabled.

> Related here: In case someone wants to use "%" in his strings he *might*
> require to use %% in case we pass it directly as format argument OR just
> use "%", in case we use it this way: sprintf(output, "%s",
> _("translation here"));

Since most (all?) uses of the "%" literal will be used to express a
percentage, that will also appear in the original English message, and
the translator will only have to copy the original formatting.

> 3) The whole charset idea. Personally I'm not a fan of letting every
> translation use its own charset, which I stated on one of the patch
> tracker items back in the days too, but either nobody cared or nobody
> noticed that (and/or I forgot about the replies I got ;-)... Anyway my
> major problem with that is:
>
> Now we have an even greater mess with charsets:

I completely agree here, and I never liked the idea of each language
coming with his own fonts, but as it's already been told, it's a lot
of work.
Showing filenames also would benefit from a charset conversion.

Regards,
Jordi