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

List:       kde-i18n-doc
Subject:    Re: translations on kde 3.3
From:       Heiko Evermann <Heiko.Evermann () gmx ! de>
Date:       2004-07-17 22:30:03
Message-ID: 40F9A86B.4030704 () gmx ! de
[Download RAW message or body]

Hi Diego,

>áSaturday 17 July 2004 07:49, ðëúá òì éãé Heiko Evermann:
>
Oh, so You DO speak Hebrew? After some digging in the cvs logs I found 
out that You are also active in
the KDE translation into Hebrew. OK. So my assumption was wrong.

>  
>
>>>
>>>Heiko?
>>>
>>>I guess, making a special exception for English would do the trick. So
>>>only if you got translations into the given list, you will get the
>>>kauderwelsch. That is if you set Hebrew:German:English and got an app
>>>that has all catalogues in at least Hebrew or German, it will be used,
>>>otherwise it will fall back directly to English.
>>>
This proposal from Stephan will not work as English would always be the 
last fall-back.

>>>      
>>>
>yes, hardcoded decisions from one developer which does not speak 20 languages 
>is alaways a good idea (lol).
>
One does not have to speak 20 languages to make decisions about languages.
Besides I do have a basic understanding of 13 languages, so I would 
consider myself to be at least
partially qualified in this regard. :)

>Don't hardcode a thing in the code. Don't makde decitions for the user. Let 
>him decide.
>
Right. At present the user can pick his languages and he will get the 
translations in that order. The current situation is a lot better than 
the old one where all gaps in the translation were filled in English, 
which is unacceptable for Low Saxon and Upper Sorbian and I guess also 
for quite some other languages.

>>The translation strings are drawn from the application's po-file
>>(usually appname.gmo, sometimes some more like in konqueror) plus
>>kdelibs.gmo and kio.gmo. kdelibs.gmo and kio.gmo should be in good shape
>>as they are central to KDE. The old way was that translations were not
>>shown at all, unless kio.gmo and kdelibs.gmo were present.
>>    
>>
>There it is. I will quote you again:
>
>"The translation strings are drawn from the application's po-file.... plus
>kdelibs.gmo and kio.gmo"
>
>But what if that app does not have a po-file to begin with? This is the 
>situation at the moment.  Me as a translator decided to keep that app in the 
>original state, since I cannot work on it (for example lack of terminology in 
>that language, or lack of time).
>
The good news about it is that you do not have to worry about it. If 
appname.gmo is not present you will only get strings from kdelibs.po and 
kio.po which you had already translated and checked. They contain 
standard strings like
* open file
* help
* about {appname}
* date chooser in your most favourite language
* file chooser in your most favourite language
* search and replace dialog in your most favourite language
I see no reason to withhold these dialogs from the user. He will get 
them in his favourite language once the translation of appname.po is 
begun, anyway. Why should you present these dialogs to the user in two 
different languages?


>
>Please note that some application in KDE do no have po-files in Hebrew and I 
>still see that some translation is made. This is the issue, all other parts 
>are things that come with this bug.
>
Frankly, this is just what we indended with the language fall back. It 
is not a bug, it is a feature. (And here this phrase is not a joke.) 
This is exactly what we wanted. We had first talked about this feature 
in May in this list. Some people were indifferent, some liked it, an 
*NOONE* objected against this feature. Thus it was implemented.

>  
>
>>The idea was that we should present to the user as many translated
>>strings as possible.
>>    
>>
>*If* the translator wants it and it decides that this application should be 
>translated.
>
No Diego, if the *user* wants to see something translated, he will get 
it translated. All the discussion about language fall back started when 
someone in our Low Saxon mailing list pointed us to the problem that he 
got Low Saxon filled up with English instead of German, even though 
German was his second choice language. (I had not noticed that as I am 
fluent in English and often even do not notice English as English anymore.)

>>It is a bit unfortunate that such problems appear so long after the
>>checkin, but at least there is still some time till the release of 3.3
>>to solve the problems.
>>    
>>
>he...
>I could not compile  CVS until a few weeks ago (i could not compile kdesdk at 
>all untill 2 weeks). 
>
How comes that? I had checked the fall back specifically in HEAD. At 
that time I was able to build it.

>>Possible solutions
>>1) revert to the old way (highly undesirable for several languages where
>>the new feature is important)
>>    
>>
>Not an option.
>
I think so, too.

>>2) solve the RTL/LTR problem (How is displaying an English string done
>>so far? What happens in Hebrew when a single string is not translated
>>and the English string is displayed? What is the trick to display that
>>string left-to-right?)
>>    
>>
>this is irrelevant, since the BIDI algorithm will be applied always, 
>regardless of the UI direction, or desktop locale.
>
After writing that mail I tried Hebrew. As I said, I do not see a 
problem in presenting a mostly English program RTL.

>
>  
>
>>3) Add a switch to kcontrol, so that the user can choose, whether or not
>>to merge languages.
>>    
>>
>This is a good idea, but we are in DEEP freeze. Again, this is a good idea, I 
>like it :)
>
Right, it is DEEP freeze.

>
>I think that you have just to fix this:
>if no app-name.po file is loaded, do not use kdelibs.po and whatever, and do 
>not translate at all.
>
Well, we are very happy about always loading kdelibs.gmo for Low Saxon 
and Upper Sorbian. But we could get around that by adding empty 
translation files for all apps. Quite some work...
One would have to change KLocale::setLanguage(const QStringList & 
languages) and filter out all languages that do not have appname.gmo, 
but I fear that even then you would not be happy, as still languages 
would be mixed.

>This means that if the translator decided not to translate the program, it 
>will be 100% "c" aka English+ltr. 
>
>What do you think?
>
I am not in favour of that.

>
>  
>
>>Any comments are welcome.
>>
>>My problem is: our second baby is due any moment. (Calculated birth date
>>is Friday 23rd.) So I can not promise to code anything. I can try to
>>have a look at all this, but once the baby is there, I will have to take
>>care of my wife and our (then) two children. So I urgently need Your
>>help to get this problem solved.
>>    
>>
>Don't worry, physics test this Monday... I have many more soon :)
>
>(Heiko: what do you think about we making the next technical discussion 
>offlist? we are making too much tech noise IMHO).
>
This is not a technical discussion. This list is the central list for 
translators and so I think it is the right place to discuss HOW strings 
should be handeled. Another question would be how to *implement* that. 
That might be a bit boring to this list.

I noticed that you posted the problem to 
http://groups.yahoo.com/group/kde-il/message/845 and to the arabic 
mailing list. I think that we should wait for some responses from there.

Kind regards,

Heiko Evermann

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