[Scummvm-devel] Improving translation support in ScummVM

[Johannes Schickel]

On 06/24/2010 11:23 PM, Jordi Vilalta Prat wrote:
> Hi,
>
> 2010/6/24 Johannes Schickel:
>    
>>
>> 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.
>    


I did commit quite a few formatting etc. changes to po2c right now, 
hopefully that's not too bad for your merge efforts.


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


Too late :-).


>> 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.
>    

I would rather prefer ASCIIfied OR English names here.


>> 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.
>
>    

True. On the other hand we still have problems with bad %n uses. Of 
course that's only really an issue if we allow external .po files.


>
> Showing filenames also would benefit from a charset conversion.
>    

True, though as far as I know the filename charset stuff is a other nice 
issue on its own. :-).

// Johannes