From kde-devel Tue Jan 28 17:03:19 2003 From: Andras Mantia Date: Tue, 28 Jan 2003 17:03:19 +0000 To: kde-devel Subject: Re: i18n questions X-MARC-Message: https://marc.info/?l=kde-devel&m=104377360503023 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 <<