[Kbabel] Google Summer of Code: Implement support for OASIS XLIFF 1.1 in KBabel

[Asgeir Frimannsson]

On 6/29/05, Nicolas Goutte <nicolasg at snafu.de> wrote:
> On Wednesday 29 June 2005 13:33, Stanislav Visnovsky wrote:
> > Dňa Wednesday 29 of June 2005 02:10 Asgeir Frimannsson napísal:
> > > Hi folks,
> > >
> > > I've been accepted for the Google Summer of Code program, and will be
> > > working heavily on KBabel over the next two months... ..So I thought
> > > I'd start off by introducing the project :) See below for my proposal.
> > >
> > > KBabel currently has some support for QT TS files and XLIFF, but the
> > > underlaying datamodel is very strongly built around the PO format. In
> > > order to support a rich format such as XLIFF we need to refactor the
> > > data model (KBabel::Catalog).
> > >
> > > Now, changing a data model for an application is never trivial, and
> > > I've only got 2 months to do the initial work. To make it doable, I
> > > would like to limit the scope of the project to the Kbabel Editor, and
> > > exclude Catalog Manager support and KBabelDict.
> >
> > It's enough to fix the editor. Catalog Manager does not depend on the model
> > that much. For KBabelDict, it really depends. I think the basic idea of
> > original and translated texts is fine - so not too much work in there as
> > well.
> 
> Good, so if you are going to modify KBabel, then I restrict myself on
> modifying the catalogmanager only. Anyway I am not sure about the time I can
> use (probably not much) and the SVN support is needed for KDE 3.5 but that
> change is limited to the catalog manager.
> 
> >
> > > I would like, if feasible, to do the development in a QT4 environment,
> > > so I'll spend a few days now first trying to port it to QT4. If that
> > > works, I'll branch it from there and start working on implementing
> > > XLIFF support. If however the porting is too complicated (I'm not
> > > *that* familiar with QT yet..) I'll go with QT3..
> > >
> > > Any thoughts or help (KDE4 porting anyone?) on the above issues would
> > > be greatly appreciated!
> >
> > Basically, QTextEdit API has changed completely again. That will be the
> > biggest problem.
> 
> Yes, but you have still Q3TextEdit. So for now, it could be kept.
> 
> Of course if for supporting XLIFF, it would be better to switch, then that
> would be another problem. (That is why I think that the change has to be done
> under QT4/KDE4, as working on Qt3/KDE3 for a major change would be to do only
> half of the work.)

Yepp, I fully agree. And that's my motivation for working with QT4/KDE4. 

> (Also I am not sure if the whole replacement for QTextEdit has been
> implemented in Qt 4.0, so perhaps we must be a little careful, before we know
> what will be added in Qt 4.1.)

But in any way, porting from 4.0 to a possibly changed 4.1 api is a
trivial task compared to porting from QT3 to QT4.

cheers,
asgeir