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

[Henri Chorand]

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

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.

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.

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?

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

- Does it allow fuzzy matching?

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.


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

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

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.


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
- translation memory technology (fuzzy matching)
- Unicode
- 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.

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

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.

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


Henri