Re: gtk+ based translation tool

[Gabor Kelemen <kelemeng gnome hu>]

Pedro de Medeiros írta:
> On 8/19/07, Gabor Kelemen <kelemeng gnome hu> wrote:
> > Pedro de Medeiros írta:
> > > I believe the glossary could be a list of words in English with
> > > maybe some explanation and suggested substitutes in the
> > > target language. They could be shared by all translation
> > > projects or they could be specific to each context (maybe
> > > categories could be used for that).
> > I think it can have more features, besides these.
> > For example, I use at work a proprietary tool, which has a really handy glossary-handling:
> > it lists the original strings in a pane, under them the known translations, which have each a letter assigned to them.
> > Then pressing ctrl+letter pastes the possible translation at the cursor position. Compared to simple text editors, this
> > feature alone boosts my productivity by a lot, and I think we need such a functionality. You can find a screenshot of
> > this tool here:
> >
> > http://www.vegadata.cz/images/TMpict.jpg
> >
> > > I think a treeview could do that. User defined categories
> > > could be implemented as different nodes in the same
> > > treeview. What do you think?
> > I think using treeview can waste a lot of screen real estate, and I'd prefer to see as much glossary matches as
> > possible.  Also, I can't imagine how user defined categories would help the workflow, could somebody enlighten this idea?
>
> Well, a treeview is actually a very generic widget that displays anything
> that implements a treemodel interface, including lists and trees. So, if
> a tree or a list isn't exactly what we want, maybe we can write a new
> treemodel-derived object that is?
>  
> But, by the looks of it, this TranslationManager application uses
> basically a tree with target words as nodes and source words as leafs.
> The difference is that it wraps vertically, allowing a variable number of
> columns in the same line.

Ok, then it should be a treeview, I'm rather a translator than a
programmer so I don1t know the possibilities of a gtktreeview :)

> The problem I see with the ctrl+letter accelerators is that they change
> for each translation unit, you can't memorize them

Should I? Really, in our proprietary glossary, we have almost 6000
original strings with 2-3 possible translation each :)

> and you will still be looking up for items in a table. 

Still a lot faster than typing, especially for short sentences, when
it's no need to scroll in the glossary widget. However, for longer
strings, it becomes slower and slower as the list grows. Also, sometimes
all the letters a-z and A-Z are over, it just diplays the
string-translation pairs, but there is no way to paste them quickly.
This is why I think type-ahead search is also a brilliant idea, so I'd
prefer to implement both.

Maybe we could use a look-ahead
> feature with a drop-down menu, like most IDE editors do. Or maybe
> both?

> > > > source, which are diffed against the to-be-translated string and colored based on the diff like in meld.
>
> I think the meld-like diff feature could be in a different window, like a
> "navigation mode", since it requires a lot of space.
No way. IMHO diff is a "must have" feature, not a "nice to have it". For
example, on the first mockup screenshot, there is a header editor, which
is nice to have, but not so critical to have it in the main window, so
Edit -> Header is a perfect place for it (just like in KBabel). Same
goes for the Must (not) translate tabs, they are not critical for the
workflow, so the should go to the menubar. The Status part of the right
bottom corner is a giant waste of space, this kind of information should
go to the statusbar. So basically, there is still a lot of space in the
window for the diff view :).
Another way to get more screen real estate is killing most of the
buttons and moving the necessary ones to toolbars. They are helpful
until you get familiar with the program, but once this is done, it's
better to turn off the toolbars and use only the keyboard and to see
more of the strings.

> > > I have to check poedit with more care, but how are TM data
> > > created exactly?
> > I don't know. Both KBabel and Poedit can read existing po files in their internal database, but I don't know how they
> > implement this. Probably this is not very important as long as it is fast :).
>
> Probably. Poedit scans for installed translations in /usr subdirectories
> to create its internal database, but it could be fed from somewhere
> else. For instance, there are, at least in Portuguese, a glossary that
> serves as guides for translations of free software. It should be useful to
> populate the application's glossary. How that TranslationManager you
> use gathers data for its glossary?
TranlationManager's glossary (or Dictionary on the screenshot) is
populated by hand. It's translation memory is populated automatically
with the translated strings, but it's also searchable and editable, but
no import from previous/other projects is possible, nor necessary.

For us, I'd prefer to populate the memory both automatically and from
files of a directory.

 >>> The "locations" string is the position in the source code
> > > where the string actually is, like the first line in:
> > I think this information is too precious, at least for me to hide behind a tab. Showing it in the same field as the
> > comment makes more sense, especially because in most of the cases, there is simply no translator comment at all.
>
> That's funny. I was thinking that most people don't use it, because
> it requires having source code around to be useful, which is not the
> case if you are not a tester. And I guess most translators aren't. :)
Oh, they contain a lot of information :)
For example, I can translate the same string differently if it's in a
.desktop file or in a .c file, or if strings are in adjacent lines of
code, meaning they are probably the from the same window - basically
most of the string's context can be guessed from the file names and line
numbers (with some experience :)).

> But then what about a configurable tab or side pane that displays
> different kinds of information from the comments, so you can
> choose what is important to you?
That would be fine.


Regards
Gabor Kelemen