Re: [Freecats-Dev] KBabel option - IMPORTANT (was: OO & Wordfast integration)

[Stanislav Visnovsky]

Hi!

Thank you for a long answer. Below find my comments.

On Tue, 18 Feb 2003, Henri Chorand wrote:

> Dear Stanislas,
>
> > I'm the maintainer of KBabel (http://i18n.kde.org/tools/kbabel) and I'm
> > following this list to find out if KBabel could use your TM server.
>
> Sorry for not reacting more quickly - I've been pushing my luck a bit too
> far in terms of late Free CATS-related homework (or should I say really
> early) and your short message deserved a strong answer...
>
> I'm sure other project team members will agree: it's good to read this.
> KBabel is on the shortlist of CAT-related free software projects about which
> we found out and which team we knew we had to contact, at one time or
> another. It's a small world :-)

Yes, it is :-)

>
> You're asking if KBabel could use our TM server.
> The answer is yes, at least we believe it would be a Good Thing(tm) ;-) and
> we would be happy to help this happen - once we have coded Free CATS server,
> of course.
>
>
> The things to consider are:
>
> 1) .PO files
> The little I've seen about KBabel is that it was designed to help
> translating KDE-style resource files (.po). Ideally, a conversion filter
> between .po format and our bilingual working document format should allow a
> translator using whatever Free CATS client available to translate .po files,
> like with a wide range of file formats.
> Good news: the resource type file formats will probably be the first ones to
> be implemented, as they are quite simple.

KBabel as of version 1.2 will support import/export filters, ATM we open
PO files and Qt Linguist files.

BTW, a PO file is a standard format of GNU gettext and de facto standard
for translation of Linux software. In opensource world I'm aware only of
two other formats: Mozilla and OpenOffice. You can even use PO files to
translate PHP (I've never done this myself though).

>
> 2) Server API & connection
> Even if I wrote out an API which certainly looks very close from what we
> will end up with, we have not accurately stated the dialog between client &
> server.
> I'm presently thinking about it and I'll try to provide a detailed document
> within a few weeks. Basically, seeing what we may be able to optimize and
> the low number of connected clients (as compared with an average HTTP
> server), I believe it will be a (simple) connected mode.

It sounds reasonable. Let's start with simpler methods and then introduce
advanced features.

>
> 3) KBabel features
> Stanislav, I think the best you could do at this stage is to provide us with
> more general design info on KBabel features (this must NOT prevent all of us
> from reading what's published online):
>
> - What does it presently do concerning translation memories?

This is probably the least advanced area of KBabel. Technically, we
support translation memory plugins with kind of simple interface (maybe
too simple, but this can be easily changed and I need a feedback what is
needed, ideally by trying to develop a new, advanced module).

ATM, we have the following plugins:
1. Translation memory based on Berkeley Database II
   - supports storing he translations on-the-fly, but without possibility
     to control what goes in and what does not
   - retrieving exact translation and also single word translation works

2. PO compendium
   - retrieving exact/partial translations from compendium

3. Auxiliary PO file
   - retrievve exact translations from other PO - used for similar
     languages, e.g. translating to Slovak could use this module
     to initialize the translation from Czech (it's not very ideal,
     but can help a lot).
   - This plugin is typically used for _searching_ the translation,
     not for automatic initialization.

4. TMX compendium
   - slight modification of (2), which roughly supports TMX 1.4 format
     The format itself should probably move to import/export filters
     making this plugin obsolete, since you could use PO Compendium then
     (the name is not that great, I know :-))

> - Does it recycle (remember) existing translations for a given source &
> target language pair, and if yes, how?

It's done by Translation memory. ATM, you can allow to store the
translation (language,file,original message,translated message) on every
change or manually let the database to read a file.

>
> - Does it allow fuzzy matching?

The plugin interface does, but what exactly "fuzzy" means is up to the
plugin. Also, only PO comendium does support fuzzy matching ATM.

>
> Let me also know if you can easily access our specification documents which
> you can find as attachments in the mailing list archive, or if you prefer me
> to send them to your e-mail address.

It seems quite easy to find them. Maybe it's time to move them outside of
the mailing list archive and put on the web page with a notice that it's
work in progress. I will speak up in case problems. Thanks!

>
>
> > In case you think KBabel UI could be adapted for your project,
> > I would be glad to do that (if time permits - it's a free software
> > project after all :-).
>
> Not all of us have a Linux computer at hand, but I've seen that KBabel is
> provided on my Red Hat 8.0, so I'll definitely have a look at it within this
> week.

Yes, it is. I would be happy if you could test KDE 3.1 (contains KBabel
1.0 with a lot of enhancements, but mostly editor-wise, not for plugins).

All the latest releases are available on the KBabel homepage in source
form.

>
> And... PLEASE, project team, DO have a look at KBabel's home page and DO
> provide feedback.
> http://i18n.kde.org/tools/kbabel/
>
>
> Your proposal may be the most positive one we heard yet. My first thought
> is, let's take the time to assess KBabel and possible enhancements to it if
> we want to make it the "ideal" standalone translation client we are hoping
> to see.
>
> The thing is, while we definitely want to have a Linux GUI client, we do not
> want to forget poor translators running M$ Winstuff & Apple OS X - for a
> variety of reasons, all software that professional translators need for
> their daily work may not be available on Linux. So, a KDE-only translation
> client would be a very good thing, but it would be even better if it was
> portable.
>
> So, I would like to know:
> - How close or how far KBabel is from being able to be ported on Win32 and
> Mac OS X platforms

Mac OS X support is pretty close, since an effort to port KDE to Mac OS X
progress nicely. Win32 support is a problem, since KBabel relies on KDE
libraries heavily.

> Our initial idea was something along the lines of Python + wxPython, C/C++
> or whatever similar. I see on KBabel's home page that it uses and/or plans
> to use:
> - Qt (Qt Designer IS a portable GUI designer, and it's free to use for GPL
> software)

On X11

> - BerkeleyDB (which I thought about as an option for our TM server, also
> GPL'ed and portable)
> As far as I can tell with a first look, it really looks feasible.

It's portable, but we have identified the following problem which hunts us
pretty hard: it is not source/binary compatible between major versions. So
if the application is developed for version 2 (as is the KBabel plugin),
one needs to adapt it for different versions with a need of dtabase
rebuild. We plan to rewrite the module using generic SQL and allow to
connect to any SQL database (there is also SQLite, which is nice for
personal use without too much hassle).

>
> Let me be clear. KBabel's present aim is to help KDE team localize its
> software and it must of course remain as such, but it may not be an
> exclusive option. If I believed, one way or another, that my suggestion
> would hamper KDE team's ability to deal best with KDE's own localization
> goals, I would not propose it.
>
> Of course, this would require extra development work, but I believe it would
> attract enough interest and we would definitely want to help.

My key point, why I responded in the first place is, that KBabel could
provide an almost ready to go client with support for network transparency
and other nice stuff of KDE. It is in fact more a translation editor (no
fancy fuzzy/automatic translation support). And I can help to adapt KBabel
to test/prototype the server etc. This is a win-win situation IMHO.


 >
>
> So, Stanislav, if you believe KBabel is an option for us - if KBabel team,
> which you manage, sees the following features as a Good Thing:
> - GUI client portability

A bit of problem. You really need KDE libs, available on Unix-like
platforms only ATM (there is KDE 2.2 port to windows, but newer KBabel
versions need a more recent libraries).

> - translation memory technology (fuzzy matching)
> - Unicode

Qt and KBabel works in Unicode internally.

> - adding as many different file formats as possible by building up the
> required conversion filters
> Maybe OmegaT team (Keith Godfrey & friends) can also help for the XML / OO
> Writer file formats.

XML is pretty easy, Qt provides nice support for that.

>
> then I'm sure we'll all want to join and help to:
> - Immediately elect KBabel as our translation client of choice for Free
> CATS, which scope would be reduced to building up a server component and
> helping to enhance KBabel

No need to elect something, you should provide as much flexibility as
possible.

> - Build our Free CATS TM server on top of Berkeley DB in close cooperation
> with what you already did for KBabel.

As I've already mentioned, this is probably not a good option.

>
> While few of us can directly contribute to code (and it also depends on the
> language used), we can still do an awful lot in terms of documentation,
> interface localization & public relations (how to make a free software
> developers localization tool into the best tool available for professional
> translators & free software localization volunteers alike.

But the goals fo FreeCATS are so ambitious, that it's necessary to do a
small steps and KBabel could provide a foundation/replacement for missing
parts while developing other.

>
> If it can happen, wouldn't all this be a most promising future ?

;-)

Have a nice day!

Stanislav