country names translations

Andriy Rysin arysin at myrealbox.com
Thu Mar 16 00:20:20 GMT 2006


Nicolas Goutte wrote:
> On Wednesday 15 March 2006 22:00, Andriy Rysin wrote:
>   
...
>> Nicolas Goutte wrote:
>>     
>>> // Get translation
>>> translation = i18n( layoutName );
>>> if ( translation == layoutName )
>>> {
>>>  // Not translated? Try harder with a country name:
>>>  translation = i18n( layoutName.prepend("Name=") ).remove("Name=");
>>> }
>>>       
>> that's ugly, slow and non-reliable
>>     
>
> Well, we are in the middle of KDE 3.5.x, we have tocome up with compatible 
> solutions, not with the most elegant ones. (Elegancy is for KDE4.)
>   
That I would agree, but I also have a limit for uglyness level I can 
agree to :)
>> how about the case if translation==layoutName in realLife ???
>>     
>
> There would not be a translation of the "country" name.
>   
how about (en) Tuvalu == (es) Tuvalu ?? (I bet there's quite few of those)
>> in best case we impact performance, in worst we pick up wrong translation
>>     
>
> If you have an additional PO file, it would pick the "wrong" translation too.
>   
Only if we don't have translation at all. In case with workaround you 
suggest we override "primary" translation with "backup" version from 
dekstop.po which may confuse the translator
>>>> I'd rather create new *.po file with country names extracted from
>>>> kdebase_deskto.po and then insertCatalog() it leaving all i18n code as
>>>> it is now.
>>>>         
>>> The translators would not welcome again a PO file with country names.
>>> (There
>>>       
>> this will not be PO file for translation, this will be smth. like
>> geo_common.po generated from kdebase_dekstop.po by removing "Name=" ...
>> (for 3.5) or separate file for common things (like geographies) in KDE4.
>>     
>
> And how do you want to generate it in KDE 3.5.2? In the release script? And 
> who will control the result?
>   
there's Makefile in l10n, and there's rules in Makefile :)
though I am not really aware of resulting problems... so if it's too 
hard, we may have to live with untranslated layouts in 3.5.x for xorg >= 
6.9.0
> As for KDE4, the problem is another and has to be solved in the general 
> problem of duplicate country and language name translation.
>
>   
> ...
>   
>>>> It'll be cleaner and faster solution.
>>>>         
>>> I do not think so.
>>>       
>> arguments?
>>     
>
> A new PO file is not cleaner and not faster (except perhaps at runtime).
>   
and isn't the runtime is the one which matters most? :)





More information about the kde-core-devel mailing list