Translation tools and GNOME (was: gtk+ based translation tool)

[Sean Burke <leftmostcat gmail com>]

    It's kind of looking like to me like some effort needs to start
being put into coordination. From what I can tell, there are three
different tools underway. To me this seems like an unnecessary division
of effort, especially considering the lack of good tools out there now.
I think the first thing that needs to happen is that the current state
of things needs to be spelled out. Perhaps this can all be worked into
the wiki.

    There are a number of currently available tools. First, there's
KBabel. KBabel seems to be a well-maintained and mature project, though
written for KDE. As has been mentioned in the thread a few times, this
may be a good place to start looking for ideas. There's poEdit, though I
personally find certain facets of its interface confusing and am
entirely unclear on how exactly its TM is supposed to work. Its basic
interface setup isn't great but isn't horrible either, so that could go
either way. (I'll say more about this if anyone cares.) Additionally,
poEdit uses wxGTK for its interface. I upgraded to unstable gtk+ earlier
(yes, I know I should expect problems) and all applications using wxGTK
have since broken. This has happened with previous gtk+ upgrades, so I'd
say we should steer away from anything too abstracted like this. Finally
(to my knowledge) there's gtranslator. The last actual release of
gtranslator seems to choke on any sort of complex Plural-Forms entry, so
I can't provide much feedback on it at all. I briefly tried out the
subversion copy of gtranslator, but I found that there were a large
number of problems that need to be addressed before it's usable. Again,
I'll expand upon this if asked.

    That covered, I think the next thing is to look at the available
tools, see what they do well and gather together a solid list of
requirements (translation memory, good format support, proper plural
form support and a glossary might all fit in here) and desires
(KBabel-like panes and a lot of other interface considerations would go
here). This may be stating the obvious, but it's also important that we
determine what the most important features are and complete them first
and make sure they're working solidly before we go on to the desires.
Additionally, it's of the utmost importance that we design and settle on
an interface before we do much of anything else. If we need to make
changes later, we can, but we shouldn't be completely redesigning
constantly and we certainly don't want to end up with something unusable
and confusing. Last, we should look at what work has been done already
and how best we can save ourselves from having to reinvent the wheel.

    I've used up quite a few words here, but I think I've covered what I
wanted to say. I would really like to get some feedback on this. I think
we have enough people interested and with the skills to create something
quite good but we won't accomplish anything by writing twenty tools that
all do half of the same job. Organization will be the key to making
something good come of this.


Se�de B�