Re: Full Gettext support in KBabel

On Sunday 23 October 2005 17:31, Chusslove Illich wrote:
> > [: Nicolas Goutte :]
> > I think that I have found out what I have not liked to the interface
> > patch:
>
> Actually, I wouldn't even regard that one as a serious patch, just a very
> temporary makeshift in case proper GUI element support is not viable in
> the short term (next week). Nevertheless...
>
> > - There is a user-visible message, so it should be translated.
>
> It was in msgid, so I somehow went with the flow :) But having it
> translated is indeed advantageous, as the chance for confusion (someone
> actually translating it) will be smaller.

In your new text "Context inserted by KBabel, do not translate:" I see a 
potentential misunderstanding, as the context is very well in the PO file.

>
> > - You are using "not" "and" and "or". They are not used in KDE. (Not
> > sure why, probably because it is to complex to support them for all
> > compilers.)
> > So please use ! instead of "not", && instead of "and" and || instead
> > of "or".
>
> Check. Habit, forgot to browse the code for that.

The new patch still uses "not"!

>
> > Also for the member function void setText(QStringList texts, bool
> > hasctxt = false) would it not be easier to have a QString as second
> > parameter to avoid to mess with the plural forms.
>
> Right, makes a lot less changes. That's what happens when I try several
> variants and drop onto one, dragging the direction of thinking from the
> others :)

Instead of
void setText(QStringList texts, QString msgctxt = "");
it would be better:
void setText(QStringList texts, QString msgctxt = QString::null);

(As you do not need the difference between a null string and an empty string 
so better make QString fast.)

>
> > I have noticed that with the current KDE context, the context is in
> > front of the translated text. I am wondering if we should not prefer a
> > solution where the Gettext context would be shown first too. (However
> > I do not know exactly how.)
>
> That was my first idea as well, but then we would need another separator
> (perhaps even some text in it again). Also, I don't know how is the diff
> highlighting working, but if it has something to do with positions in
> msgid, appending context to the end shouldn't hurt it.

I would think that the difference function will use the msgid, not the view. 
(But I do not know, as it is really a part of the code taht I do not know 
yet.)

>
> > Also there are a few little details of the code:
> > - please use ++var instead of var++ (as var++ creates a new object and
> > is therefore slower).
>
> Yep, trying to get into that habit.
>
> Updated interface patch attached.

If there was not the problem with the user-visible string, I would tell you to 
commit the patch. But with the string we have to agree about a text and see 
the feedback of the translators on kde-i18n-doc (if there is any feedback to 
my email).

-

So I suppose that with this patch the change needed for KBabel's editor are 
clear, now we need to see about the catalog manager...

Have a nice day!