On 8/19/07, Gabor Kelemen <[EMAIL PROTECTED]> 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. _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
