country names translations

[Andriy Rysin]

Nicolas Goutte wrote:

>On Monday 06 March 2006 02:54, Andriy Rysin wrote:
>  
>
>>David Faure wrote:
>>    
>>
>>>On Sunday 05 March 2006 19:07, Nicolas Goutte wrote:
>>>      
>>>
>>>>For KDE3, you surely can prepend "Name=" to the string and remove that
>>>>name later after the translation is returned.
>>>>        
>>>>
>>>Yes, that's what I was thinking about.
>>>      
>>>
>>There's little problem with that: currently in xorg 6.8.2 and earlier
>>the name for layout would be "Ukrainian" but in xorg 6.9.0 and later
>>it'd be "Ukraine"
>>And I don't think doing this something like the code below is acceptable:
>>if( xorgVersion >= 690 )
>>    translation = i18n( layoutName.prepend("Name=") ).remove("Name=");
>>else
>>    translation = i18n( layoutName );
>>    
>>
>
>// 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
how about the case if translation==layoutName in realLife ???
in best case we impact performance, in worst we pick up wrong translation

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

>are already many PO files containing some country names.)
>  
>
that's what I am trying to get rid of - it'd be nice to have common 
translation for common things. AFAIK there's no such thing currenlty. 
The country translation is duplicated (in non-reusable way because of 
"Name=" prefix) in kdebase_desktop.po and some non-kdebase packages

>>It'll be cleaner and faster solution.
>>    
>>
>
>I do not think so.
>  
>
arguments?