[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Language fall-back: proposal for a solution
From:       Heiko Evermann <Heiko.Evermann () gmx ! de>
Date:       2004-05-17 20:54:44
Message-ID: 40A92694.6040103 () gmx ! de
[Download RAW message or body]

Hi Nicolas,

>>>Oops, there is probably one problem remaining: the plurals.
>>>      
>>>
>>I have had a closer look. This might be a problem indeed. At the moment
>>klocale will only remember the plural type for the main language.
>>
>>So we would have to remember the plural type for all installed
>>languages. (e.g. in an associative array that maps iso-codes to plural
>>types) And when we look up a string and find out that it contains plural
>>handling, we have a look at the language where we found the translation
>>and use the plural handling of that language. That might mean that
>>KCatalog should get a new member variable "QString : language".
>>    
>>
>
>Yes, sure, but we get to change KCatalogue too, but my solution remains 
>isolated to KLocale. So there is not any source ot binary compatibility 
>problem and you do not risk to have to wait KDE 4. 
>
>(Of course for binary compatibility, you could also put the new variable in 
>the private class and add access member functions.)
>
I have thought about it a little further. I think the language and 
plural type could be stored in KCatalog.Then KLocale can just walk 
through the catalog list, pick the first translation and could find the 
language code and plural type in the KCatalog-object where the 
translated string came from.

Concerning binary compatibility:
KCatalogue can be equipped with further member variables and accessor 
methods without changing the size of a KCatalogue-object. The only 
important thing is to keep the signatures of all existing methods 
unchanged. KLocale uses the same technique. As long as one does not 
change the list of virtual functions, adding new functions would not 
break binary compatibility. So this would still be a way one could go.

I will just try it out on my local version. I have started building cvs 
head on my computer. I need it for checking the current status of nds in 
head, anyway.

But perhaps we should discuss it on some other list, like core-devel? 
The technical part of the question does not seem to be interesting to 
too many people on this list.

Kind regards,

Heiko Evermann

[prev in list] [next in list] [prev in thread] [next in thread]