[Kbabel] Fwd: gettext and contexts

[Nicolas Goutte]

On Thursday 20 October 2005 22:30, Chusslove Illich wrote:
> >> [: Chusslove Illich :]
> >> What's the big problem of simply loading and storing msgctxt in the
> >> same way as anything else (eg. msgid_plural), and writing it back out
> >> upon saving? It is anyway what has to be done at some point, and
> >> currently it would just be invisible to the user (no feature changes).
> >
> > [: Nicolas Goutte :]
> > The problem is how to show it to the user, without having tons of new
> > code (which nobody seems to have the time to write. (I mean in KDE 3.5
> > of course.)
>
> Oh :) It's just that I was coming from the position of this context stuff
> being to new to get into the field use quickly, so I went only into the
> don't-choke direction... 

Well, if translators translate a phrase badly, it is not much useful for KDE 
either.

> We'll use it in KDE 4.0 (hopefully :), and on
> Translation-i18n there was also an estimate of two years for this to sink
> into the Gnome camp, by a fellow translator from that tribe.

Yes, but if KDE4 use old KDE3 PO files, it means that new PO files will be for 
KDE5 and that will be in 3 or 4 years only. (Not that I think that being 
before or after GNOME is so important. I feel it more important that the 
Gettext used by KDE gets maintained again. Using the normal Gettext is a very 
good way of getting it maintained again.)

As for KBabel for KDE4, sure it is really mandatory that it would support the 
new PO file format and if possible in a correct and user-friendly way.

>
> Anyway, thinking in this direction, 3.5 KBabel is feature frosen, but what
> exactly constitutes a feature freeze? 

Well, sure KDE 3.5 is in feature frozen. But the matter is strategically 
important for KDE4. (So it is one "high good" against another.)

Normally a "feature freeze" is that you do not introduce new features. It is 
not entirely clear what a "feature" is, especially compared to fixing a bug.

(So for example is fixing the XLIFF export a feature ("Yes, we have finnaly 
XLIFF export working!") or fixing a bug ("Yes, XLIFF export finally 
works!")?)

But more realistically "feature freeze" means avoiding to make large change, 
especially where/when you do not overview the consequences of the code 
changes. (That is especially true for KBabel, which must work.)

> I had this idea: currently, if the
> msgid_plural comes, the msgid pane is going to split into two tabs to show
> both; could this GUI easily be upgraded to show another tab if msgctxt is
> present? And all this comes into play only if msgctxt appears, so there is
> no real new feature to talk of :) I myself could probably make the msgctxt
> load where it should and write out back, but as I said, I'm blank with
> GUIs.

I would avoid GUI changes. (But that is more my personal experience.)

Have a nice day!