[Kbabel] Full Gettext support in KBabel

[Nicolas Goutte]

On Saturday 22 October 2005 20:54, Chusslove Illich wrote:
> > [: Stephan Kulow :]
> > We will change to standard gettext before 4.0 - if kbabel 3.5 has to be
> > changed for that, be it!
>
> This sounds like a licence for "change as needed" :)
>
> I've added upon Nicolas' patch, making msgctxt a normal member of the
> internal data: proper support in Catalog and CatalogItem, and proper
> import and export in Gettext filter (patch_internals.diff).
>
> I've tried to fool around with GUI, eg. make an extra tab in msgid pane,
> but it proved too much for me just by looking for analogies :) Instead,
> for debug purposes, I put msgctxt below the msgid in msgid pane, separated
> by a "Inserted by KBabel..." sort of line (patch_interface.diff). Perhaps
> it would still not be too hard to add extra GUI element for someone who
> actually knows what to do :)

I think that I have found out what I have not liked to the interface patch:
- There is a user-visible message, so it should be translated.
- 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".

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. (You can use QString::isEmpty instead of the boolean to 
check if there is or is not a msgctxt then.) This would simplify the code 
(and avoid to have to make a copy of a QStringList).

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

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).
- when creating a new QString, you do not need to initialize it to "" if you 
do not need the difference between a null string and an empty string.

I am going to inform kde-i18n-doc that we need a new string. (Whatever we do, 
I do not thing that we cannot go around that if we want a solution that is 
not hacky.)

Have a nice day!