[Kbabel] Full Gettext support in KBabel

[Nicolas Goutte]

On Thursday 20 October 2005 13:24, Chusslove Illich wrote:
> Hi,
>
>
> What would it take for KBabel to fully support Gettext PO features? 

Well, it is quite (too) late now, as KDE 3.5 is in message freeze. Therefore 
KBabel cannot be changed where it would matter.

(KDE 4 will not be translated with its own KBabel but with the KBabel of KDE 
3.5. We had that experience already with KDE2 to KDE3 switch.)

> Since
> few days ago, Gettext has full support for what we need in KDE: formal
> contexts (new msgctxt field) and xgettext extractor updated accordingly
> (will also work for overloaded ordinary, context and plural calls). So I
> think there is no reason to fiddle with custom stuff for KDE 4, providing
> that all tools are updated to handle standard Gettext POs, KBabel being
> primary.

Well, it also depends how fast such a Gettext is officially released, so that 
it can be really used.

(Do not forget! KBabel is a tool for translators. That are not people that can 
jump on every new software tool, either because they do not have the 
knowledge how to compile or because downloading is cost-intensive (not to say 
prohibitive). You can look at how many people we have lost with the change 
from CVS to SVN.)

>
> I've browsed a bit through KBabel's Gettext import/export code, and
> couldn't find anything explicitly left to be done, but I've been said that

msgid_plural and msgstr_plural are not correctly handled 
(only loaded as far as I understand the code).

> it doesn't function perfectly. So, is it just buggy, or something else? I
> could devote some time to get these internals done, but not the required
> GUI updates (needed for context), as GUI stuff is out of my comprehension
> currently.
>

> Is there a reason not to go for Gettext's own libgettextpo for
> import/export of PO files?

As far as I had understood Stanislas, the problem is that those functions 
cannot recover from syntax errors in the file. KBabel's editor (not the 
catalog manager) tries to be error tolerant at load.

As for the catalog manager, as far as I know, its PO loading code is from 
Gettext. (However at least change to support CR+LF endings.)

>
> On a side note, regarding GUI, I am also interested why are the message
> storage specifics left in it? Like escaped characters, non-newline line
> breaks, comments, plurals. 

> It seems to me that it would be better if
> KBabel had a consistent user-side representation, so that it doesn't
> matter what the underlying translation file format is. 

That what is planned for KBabel of KDE4. That is why the change to XLIFF (or 
XLIFF-like) internal representation is planned. (As for who will do what and 
when, that seems to be a totally open question. I am not sure that there is 
even any people following this mailing list who are trying to compile KBabel 
on KDE4 regularly.)

>It should only
> decide which of representation features to use, depending what the loaded
> format supports.

Have a nice day!