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

Nicolas Goutte nicolasg at snafu.de
Wed Jun 29 21:15:19 CEST 2005


On Wednesday 29 June 2005 17:25, Asgeir Frimannsson wrote:
> 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.

Except if something is missing. But something missing for KOffice does not 
necessarily means that there is not enough for KBabel.

Have a nice day!

>
> cheers,
> asgeir



More information about the kbabel mailing list