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

List:       kde-devel
Subject:    Re: i18n questions
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-01-28 15:15:14
[Download RAW message or body]

On Tuesday 28 January 2003 14:45, Andras Mantia wrote:
> On 2003. January 28., Tuesday 15:30, Nicolas Goutte wrote:
> [...]
>
> > > {
> > >         font-weight: Grassetto marcato;
> > > }
> > >
> > > Is there a way to tell that I don't want to translate those listbox
> > > elements (or revert the translation when I retrieve the currentText
> > > from the listbox), or the only solution is to add one by one the
> > > elements from code, without using i18n(...)?
> >
> > What I do not understand is why you want the strings untranslated despite
> > being user visible.
>
> Because their are "fixed" strings, and in the resulted document they should
> appear untranslated (just as the keywords in programming languages).

Only the result has to be a fixed string. That does not mean that these fixed 
strings have to be user visible in exactly this way. 

>
> > It seems to be against KDE translation policy. It would
> > be to the I18N team to decide if they want to keep the CSS names or if
> > they want to translate them. (Remember: many people in the world cannot
> > read latin letters.)
> >
> > The proper solution would to check the return result. For exasmple if the
> > variable result has what the user has selected:
> >
> > QString CSSProperty;
> > if (result==i18n("bolder"))
> > 	CSSProperty="bolder";
> > else if (result==i18n("bold"))
> > 	CSSProperty="bold";
> > // and so on
> >
> > It might look as being boring code, but it would be i18n friendly.
>
> Ok, this may be more user friendly, then just providing the untranslated
> strings in the dialog box. Altough I agree that there are people who cannot
> even read latin letters, do you think that those people are able to write a
> HTML/PHP or whatever document? ;-)

Ah, sorry, I had not missed  the context in which you needed the dialog box. I 
have seen it s KWord developer and maintainer of KWord's HTML export filter. 
In my context such a dialog would need to be translated.

In this case, I would suggest something else.

Do not feed the QListBox in QDesigner but by "hand". The advantage is that you 
can define the i18n strings as:
i18n("CSS Property","bolder")

So you give a chance to the i18n teams to translate it for example in Italian 
"bolder (grassetto marcato)" and you will still be inside KDE translation 
policy. That way, you could help HTML/CSS beginners by having the meaning 
additionall in their own languange.

The context "CSS Property" is in my opinion important so that the i18n teams
know about what you are talking and that keeping the English name is important 
too.

So a code like:

QStringList cssBoldList;
cssBoldList << i18n("CSS Property","bolder") << i18n("CSS Property","bold") << 
i18n("CSS Property","normal"); // And so on;

And then you use QListBox::insertStringList

(An example is in koffice/filters/kword/html/export/ExportDialog.cc, however 
with a QComboBox.)

Then the code at the end would change into:

QString CSSProperty;
if (result==i18n("CSS Property","bolder"))
 	CSSProperty="bolder";
else if (result==i18n("CSS Property","bold"))
	CSSProperty="bold";
 // and so on

>
> Thanks for the hint.
>
> > > 2. I would like to read some strings from external files. What is the
> > > recommended way to get those strings translated?
> > >   a)  use I18N_NOOP to tell that those strings should be translated and
> > > use i18n(QString_variable) in code (bad if the external files are from
> > > 3rd party) b) Read the translated strings from the external files (like
> > > in case of .desktop files). In this case how should it done? Read the
> > > correct string from the file by checking the current language of KDE
> > > and use the read string in code without i18n?
> >
> > Defining the string would not go with I18N_NOOP, as the strings are not
> > in the C++ source file but somewhere else.
>
> Right, it would not go for 3rd party extra files, and it would be a mess.

I do not understand what you mean here. 3rd partoes do not use KDE's system 
for extracting the strings to be translated.

>
> > I think they are a few ways to do it correctly but currently I am not
> > remembering the examples.

I have finally found an example in kdeprint (in the directory 
kdelibs/kdeprint/cups/cupsdconf2) Here a Perl script generates an intermidate 
file for extracting the strings to be translated.

The general idea seems to be that you must transform the external file in 
something like a C source so that you can run the program gettext on it.

So you have to transform your external files to have a file like 
kdelibs/common_texts.cpp, like for example:

i18n("Text 1");
i18n("Text 2");
i18n("Text 3");

Now you have to choose if you prefer to have a pseudo-C file or your external 
file in CVS. 

In case that you will have the pseudo-C file in CVS, Makefile.am file needs to 
be modified to call gettext in this way:

messages:
	$(XGETTEXT) yourfile.cpp

For an intermediate file, see the example of the file 
kdelibs/kdeprint/cups/cupsdconf2/Makefile.am

> >
> > However using i18n for using the translated version is fine, for example:
> >
> > kdDebug() << "Text:" << QString_variable << " Translation" <<
> > i18n(QString_variable.utf8()) << endl;
> >
> > (QString_variable being a QString)
>
> I don't understand you. I know that it is find to use translated strings
> inside i18n, but if the string is already translated, I believe the i18n is
> not needed. What I would like to know if is there a standard method to deal
> in such cases? I should grep the kde sources to see how it is done in case
> of .desktop file, but I don't have a clue where to start (ok, kdelibs or
> kdecore...)

But how would you fetch the translated string? QString itself cannot do it, it 
is the job of i18n()

Additionally i18n() marks were strings have to be fetched to get translated. 
If there is no string (like in our case), nothing is fetched.

As for .desktop files, there are a bad examples, as the processing of those is 
done "automagically."

>
> Andras

Have a nice day/evening/night!

>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]