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

Nicolas Goutte nicolasg at snafu.de
Wed Jun 29 14:05:55 CEST 2005


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

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

>
> IMO we should create a branch for KBabel for Qt4. I would like to help you
> with porting.
>
> Stano
>
> > I'll be on freenode's #kde-soc as well as #kde-devel
> >
> > cheers,
> > asgeir
> >
> > ---------- Forwarded message ----------
> > From: Asgeir Frimannsson <asgeirf at gmail.com>
> > Date: Sat, 4 Jun 2005 22:08:24 +1000
> > Subject: Bounty proposal: Implement support for OASIS XLIFF 1.1 in KBabel
> > To: bounties at kde.org
> > Cc: visnovsky at kde.org
> >
> > Hello KDE folks,
> >
> > As I'm graduating mid-July, I have a bounty proposal I would like to take
> > on for the Google Summer of Code. I propose KBabel maintainer Stanislav
> > Visnovsky (cc'd) as a mentor.
> >
> > [Name and Email]
> > Asgeir Frimannsson <asgeirf at gmail.com>
> >
> > [About Me]
> > I'm 24 years old, Norwegian, but have been living in Brisbane Australia
> > the last 4 years. Currently completing Bachelor of Information Technology
> > (Honours) at Queensland University of Technology, graduating mid-July. In
> > my final year I've been receiving a scholarship from Red Hat for working
> > on a thesis entitled 'Adopting Standards Based XML File Formats in Open
> > Source Localisation'. In this research I've been looking at current
> > localisation practices in open source, and identified ways of improving
> > the localisation process through adopting industry standards such as the
> > XML Localisation File Format (XLIFF), the TermBase eXchange (TBX) file
> > format, the Translation Memory eXchange (TMX) file format and Translation
> > Web Services. I'm hoping to continue this research as a Ph.d. student
> > starting later this year.
> > I have previous experience in open source through maintaining the XLIFF
> > Tools project [http://xliff-tools.freedesktop.org/] as part of my honours
> > project, and have previously also submitted patches and worked on KBabel
> > and GNU Gettext (KDE svn account name 'asgeir').
> >
> > [Project Title]
> > Implement support for OASIS XLIFF 1.1 in KBabel
> >
> > [Synopsis]
> > Localisation of open source (including KDE and Gnome) is in a majority of
> > projects handled by the GNU Gettext library and the associated PO file
> > format. The PO file format is a simple string table used by translators
> > to translate the English sources to their native language. Several tools
> > exists for editing PO files, and the most used (and most advanced) of
> > these is KDE's KBabel.
> > In recent years, industry standards have been developed in the area of
> > software localisation, including the OASIS XLIFF file format for storage
> > and exchange of localisable resources in the localisation process. The
> > philosophy behind XLIFF is to extract resources from native formats into
> > a common standard localisation format (XLIFF), and merge the translated
> > resources back into the native format when translation is complete.
> > Filters and specifications for converting to and from XLIFF have been
> > developed for a number of file types, including PO, HTML and DocBook.
> > KBabel has very limited support for XLIFF, and this project aims to
> > implement support for many of the rich features of XLIFF, including
> > abstraction of inline codes, viewing/approval of translation suggestions,
> > viewing of context information and the ability for translators to attach
> > notes to translations.
> >
> > [Goals]
> >  1) Contribute to making KBabel the best open source XLIFF localisation
> > tool 2) Expand KBabel's user base by implementing support for
> > localisation industry standard file formats.
> >
> > By implementing support for the industry standard XLIFF format in KBabel,
> > the KDE project will have a fully fledged native XLIFF localisation tool.
> > As we move towards and beyond KDE 4, we then have a stronger argument for
> > considering adopting XLIFF in KDE's localisation process, with its
> > inherent benefits:
> > - Better handling of context information (by not including context as
> > part of the source string)
> > - Abstraction of inline codes such as XML tags and parameters
> > - Identification and tagging of terms (better terminology management)
> > - Easy adoption of new formats in the localisation process (all you need
> > is a filter to/from xliff)
> > - Inclusion of translation suggestions (possibility of future server
> > based translation memory)
> > - Allow translators / developers to add comments to translations.
> > - Better change tracking (tracking of who translated what)
> > - All the benefits of XML based processing
> >
> > [Project Details]
> > The XLIFF file format is a very rich super-set of the PO format, and
> > hence, some of the underlying data model in KBabel may change in the
> > process, allowing support for features such as context info, translation
> > suggestions, hierarchical data structures, inline codes,
> > sub-segmentation, translator comments and other meta-data. The first step
> > of this process will be (if not already done when starting) to port
> > KBabel to QT4 (need some help here). After the initial porting to QT4,
> > XLIFF features can be added incrementally, starting with the most
> > important ones:
> > - Honouring common attributes (such as fuzzy handling, translate yes/no)
> > - Abstraction of inline codes (with some visual elements representing
> > tags) - Display of context information
> > - View / Add notes
> > - view / approve translation suggestions
> > - Workflow meta-data such as 'phase' information
> > I realize that there is also a looming usability issue here, as KBabel is
> > becoming more and more bloated with features, some serious evaluation is
> > also needed in considering how to best implement the rich features of
> > XLIFF in a way that's user friendly to translators.
> >
> > [Project Schedule]
> > June 24: Project Start (I finish exams June 23)
> > June 24- July 10: Discuss requirements / Design & port to QT4
> > July 10 - Sept 1: Incrementally implements XLIFF features in KBabel
> > Sept 1: Project deadline
> >
> > [Motivation]
> > My main motivation is to make the localisation process more user friendly
> > so that more potential translators can contribute. I see XLIFF as the
> > long term solution to many of the challenges facing open source
> > localisation, and the format provides a way of standardizing the
> > localisation processes across open source projects.
> > I am also a big KDE-fan, and would like to get more hands-on experience
> > in KDE/QT/C++ development - I want to contribute, and not just observe :)
> >
> > That's about it. Let me know if you are interested in this :)
> >
> > cheers,
> > asgeir
> > _______________________________________________
> > kbabel mailing list
> > kbabel at kde.org
> > https://mail.kde.org/mailman/listinfo/kbabel
>
> _______________________________________________
> kbabel mailing list
> kbabel at kde.org
> https://mail.kde.org/mailman/listinfo/kbabel



More information about the kbabel mailing list