[Scummvm-devel] Improving translation support in ScummVM

Eugene Sandulenko sev at scummvm.org
Thu Jun 24 08:04:16 CEST 2010


On Thu, 24 Jun 2010 01:00:18 +0200
Johannes Schickel <lordhoto at scummvm.org> wrote:
> 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.
Not only that. Also it is the standard, supported by many utilities and
programs.

> 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.
If you need some help with perl, I can do it.

> 1) Some of the locale strings use %d etc. to add numbers, strings
> etc. to the output. While that might be fine, the major problem here
> is: the order is fixed, so it might be hard for translators to take
> grammar or the like into account when doing translations for those
> messages.
As I've mentioned, those belong to _t(). Feel free to remove that
feature altogether. Originally this was implemented for the sake of
completeness, but I do not believe that we need to translate debug
output. Rather, we need to implement FR #2616463: "ALL: Display errors
in graphic display before exiting"

> 2) We definitely lost all the ability of format type checking (%d),
Same as above.

> 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:
UTF-8 will kill small devices. Also if somebody will decide to
implement it, I wish him all success with rewriting our font management
code which these days works with single byte encodings only.

> First of all our OSystem API's setWindowCaption is fixed to LATIN-1, 
> i.e. game titles will still not be translatable properly, so the user 
> might even be confused why his window title looks off, even though he 
> setup a correctly looking name in ScummVM.
This was already discussed in the past. It will be too much to
translate game names. Let's keep them in English as they are now.

> Also our input charset is not defined at all AFAIK, thus we can't
> even assume the user can properly enter save names with our GUI in
> his language. Which is also a bad thing for people who want "proper" 
> language support.
Again, proper support will be a lot of work.

> 4) I think we still only support left-to-right languages, while of 
> course that might be fine, it might feel like kind of a
> discrimination to people with a mother language, which is written
> right-to-left.
Oh yeah. What about CJK? Traditional Chinese which is top to bottom?
</sarcasm>. Again, if somebody will implement it in a clean way, I will
be all for inclusion, especially if it will be possible to turn it off
at compilation time. But I believe that it is /too/ much work.


Eugene




More information about the Scummvm-devel mailing list