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

List:       kde-devel
Subject:    Re: i18n questions
From:       Andras Mantia <amantia () virtualartisans ! com>
Date:       2003-01-28 17:03:19
[Download RAW message or body]

On 2003. January 28., Tuesday 17:15, Nicolas Goutte wrote:
[..]
> > 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.

Yes, I agree now. I already implemented it this way. ;-) 

> 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

Yes, this make sense.

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

I found a little boring using such "if .. else if .. else if" structures, so 
my solution was to create a static method which returns the non-translated 
version for a translated string. E.g for the translated "italics" it will 
return literaly "italics". This way when I read the selected text from a 
list/combo box, I translate it back to English, so I can handle it. But the 
idea is the same as yours.


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

Here I was talking about some Quanta DTD definition files. They contain some 
DTD releated texts which appear on the screen. You can use your own DTD 
definitions, and this is what I call "3rd party files". Of course, the texts 
from such files will be translated only if they provide/include the 
translations, just like in case of .desktop files. Waldo wrote me that 
KConfig should handle this, and this is great news, as those definitions 
files are created/read with the help of KConfig.

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

This is also a way to go. Thanks for digging out, it may help in the future!

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

Ok, I understand this. First I thought that i18n is used only when grepping 
for "to be translated" strings.

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

I also need that magic. ;-) For me they were good examples, as they are also 
processed with the help of KConfig.

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