gtk+ based translation tool

["Pedro de Medeiros" <pedrovmm+gnome-i18n gmail com>]

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.

The problem I see with the ctrl+letter accelerators is that they change
for each translation unit, you can't memorize them and you will still be
looking up for items in a table. 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.

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

> >> Also I'd like to see some more screenshots about the "Must (not) translate" and the Locations and Actions tabs: what do
> >> these do?
> >
> > These are translate-toolkit features. If the same word is
> > used in both source and target messages and if it is also
> > in the "Must translate" list, the filter issues a warning.
> >
> > The same thing happens if the word is in the "Must not
> > translate list" and the word is not found in the target
> > string.
> >
> Ok, I see, but on these tabs, what can we do? Edit the lists or see the warnings or something else?

We can edit those lists and if we double-click the warning message
we get after editing, the specific item in the list is displayed.

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

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?

And, about the translator comments not being used, I was hoping
we could start using it more, if they were easier to edit and made
more visible. I believe it's not uncommon for translation teams to
constantly change or reassign translators for different modules
and, every time this happens, a lot of that knowledge gathered by
experienced translators is lost. This can be a source of regressions
and translation bugs that translator notes could help avoid, that is,
if we can encourage its use.

I will try to come up with more mock-ups based on those ideas
during the following week.


Cheers,
Pedro.