[Scummvm-devel] Translations of the About text in ScummVM

Max Horn max at quendi.de
Fri May 13 10:15:06 CEST 2011


Am 12.05.2011 um 22:07 schrieb Thierry Crozat:

> 
> Le 12 mai 2011 à 18:41, Simon Sawatzki a écrit :
> 
>> Hi everybody,
>> 
>>> Actually I think most of these will not be translated since they occur in
>>> engine names or people names and I don't think we are going to translate
>>> those. Actually I would even prefer if we could filter in credits.pl the
>>> string we make translatable and exclude engine names and people names for
>>> example, because having many strings in the po file that we do not
>>> translate make it difficult to follow the status of the translations.
>> 
>> I disagree here. I think it should be possible to translate engine names because in German I would like to have "AGOS-Engine" instead of "AGOS Engine" - the latter one looking like the translator would have inserted a "fool's space" (Deppenleerzeichen). I also think it would be "Moteur de AGOS" in French, wouldn't it?
> 
> Except that the credits themselves do not use the word "Engine" (i.e. you have "AGOS", "AGI"...). And I really can't see the point of translating that.
> 
> I guess you though of the available engine list that is displayed before the credits (it lists the engines compiled in). And here yes I agree, we might want to translate that, or remove Engine from the name. As it is now some engine names in this list are called "Foo Engine" (e.g "Tinsel Engine") others are called "Foo engine" (e.g. "Saga engine") and sometime even "Foo" (e.g. AGOS") . Maybe we should make that consistent. If we make that consistent by removing Engine from the name, then again I don't think they would need to be translated.

These come from the MetaEngine::getName() implementations in each engine. It would indeed be good to slightly unify those. I guess the "engine" should just be dropped from each. Easiest solution and IMO the result in the about dialog looks good, too. Please feel free to go ahead and make that change to all engines.


> 
> 
>> Moreover, I think we should move the credits into another po(t) file or at least into another section like at the ending after everything else was translated, because I think it is a should-have but not a must-have. It is professional to translate the credits, but other (s)t(r)hings have a higher priority.
>>  We could for example make a scummvm_credits.pot and create translation files like FR_fr_credits.po. What do you think about that?
> 
> That's an interesting idea. Generating a separate pot file for strings extracted from credits.h and credits.cpp is easy enough. Then we would also need to modify the create_translation tool to handle that (e.g. take translations from all fr_FR_*.po files to generate the french translation block). That shouldn't be too hard either.

Well, if you think, feel free to implement it. But I for one don't really see why this is a useful idea. A good PO tool should allow a translator to mark strings as "won't translate", or you could just auto-populate them (with identical copies of the msgstr), no harm done (except for the ö etc. business, possibly, but I'll talk about that in another email). 

In another idea, the idea of selectively loading the credits translations only when the about dialog is showing was mentioned. This doesn't sound that appealing to me either, because the about dialog can be shown *while* a game is running anyway, and then loading it dynamically just adds to the heap fragmentation. But we sure could try it, but it would require deeper changes to the translation code to allow multiple translation.dat files, so the code size would also grow... 

I could understand if you were arguing .po file for each engine -- after all, they can be built as loadable modules, and so we could only add those engines into translation.dat that are actually enabled. And maybe also one .po file for each backend? Same reasoning. 

But all of this is really way beyond what I intended to work on, so just to make it clear: I won't be working on any of this ;).


Cheers,
Max



More information about the Scummvm-devel mailing list