Re: complain!
2008/2/8 Andre Klapper [EMAIL PROTECTED]: Am Freitag, den 08.02.2008, 15:22 +0100 schrieb Robert-André Mauchin: Le vendredi 08 février 2008 à 03:11 +0100, Andre Klapper a écrit : only one example: do you really want to tell me that translating sentences like An application wants access to the %s '%s', but it is locked was no problem for you, because in your language %s is also always(TM) neutrum? Sh*t, I've just found this string, have you file a bug report about that ? yes, i just didn't want to blame any specific modules, as i wrote already. in general, just take a look at the bug list of the affected module or search for the L10N keyword. if everybody bug reporter would add the L10N keyword to bug reports like these ones, it would be even easier to find them and to avoid filing duplicates. that's why i ask all translators to please report bugs *and* add the keyword L10N to them. I was doing it already, but adding the I18N keyword to them. According to http://bugzilla.gnome.org/describekeywords.cgi it makes more sense. Since you want the programmers to fix the infrastructure for translators. Pedro ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Need input from the translators for anjuta
On Jan 7, 2008 4:47 PM, Johannes Schmid [EMAIL PROTECTED] wrote: Hi all! Just to note: a) There is a bug about wrong translation: http://bugzilla.gnome.org/show_bug.cgi?id=496833 We tried to resolve issues that are brought up here! I don't like the idea of packing lots of new bugs in the comments. It was too big and some comments were answered while others were not. So I created a new one here too: http://bugzilla.gnome.org/show_bug.cgi?id=507921 There's a link to it in bug #496833 too. Pedro ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gtk+ based translation tool
Here, made another one: http://flickr.com/photos/[EMAIL PROTECTED]/1190237995/ A mock-up of the database preferences tab. Cheers, Pedro. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gtk+ based translation tool
On 8/20/07, Raphael Higino [EMAIL PROTECTED] wrote: On 8/19/07, Pedro de Medeiros [EMAIL PROTECTED] wrote: 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? I don't know how it works on Linux, but on Windows I have to point a directory where poEdit will find po files to make its TM database from. But getting translations from mo files seems to me something really clever. I'd just suggest that the TM database be stored in plain text files, so they can be more easily edited, if needed. Raphael, TM databases in plain text are slow. That's why poedit converts them to Berkeley DB. Besides, editing the TM database is one of the things that the translation tool should do anyway. Gzip plain text TM could be shared between translators, though. But an export feature should suffice. Cheers, Pedro. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gtk+ based translation tool
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
gtk+ based translation tool
On 8/17/07, Gabor Kelemen [EMAIL PROTECTED] wrote: Hi This is a nice start, but lacks the two most important features a new Gnome translation tool should have: glossary pane (no, a notebook tab is not sufficient) and translation memory pane, which shows the good results from TM and their 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 a treeview could do that. User defined categories could be implemented as different nodes in the same treeview. What do you think? source, which are diffed against the to-be-translated string and colored based on the diff like in meld. I have to check poedit with more care, but how are TM data created exactly? 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. The locations string is the position in the source code where the string actually is, like the first line in: #: accels.c:123 msgid C_urrent Profile... msgstr Perfil _Atual... The locations tab gathers these comment (because they can happen several times). The actions tab is just an idea. Maybe some kind of a plugin structure that could be turned on/off by special comments for each translation unit, or even for the whole file. Cheers, Pedro. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: gtk+ based translation tool
On 8/17/07, Gabor Kelemen [EMAIL PROTECTED] wrote: Hi This is a nice start, but lacks the two most important features a new Gnome translation tool should have: glossary pane (no, a notebook tab is not sufficient) and translation memory pane, which shows the good results from TM and their 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 a treeview could do that. User defined categories could be implemented as different nodes in the same treeview. What do you think? source, which are diffed against the to-be-translated string and colored based on the diff like in meld. I have to check poedit with more care, but how are TM data created exactly? 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. The locations string is the position in the source code where the string actually is, like the first line in: #: accels.c:123 msgid C_urrent Profile... msgstr Perfil _Atual... The locations tab gathers these comment (because they can happen several times). The actions tab is just an idea. Maybe some kind of a plugin structure that could be turned on/off by special comments for each translation unit, or even for the whole file. Cheers, Pedro. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Invariant sections? GFPL
2005/9/5, Danilo Šegan [EMAIL PROTECTED]: Today at 13:58, Clytie Siddall wrote: GFDL (and any other GNU licenses) itself is valid only in original English language[1]. Translated versions are there only for convenience, so just do not worry about it. Good to know that. Is there a default disclamer notice for that kind of thing? So we don't have to come up with a new way of saying that on each language GNOME is translated for. Sorry if it is a stupid question. :) Cheers -- Pedro de Medeiros - Ciência da Computação - Universidade de Brasília Email: [EMAIL PROTECTED] - Home Page: http://www.nonseq.net Linux User No.: 234250 - ICQ: 2878740 - Jabber: [EMAIL PROTECTED] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: 2.12 Press Release ready for translation
2005/9/2, Murray Cumming [EMAIL PROTECTED]: How about the location at the begining of the text. Are translators allowed to change BOSTON, Mass with their city/country name? Yes, I guess that is OK. Do it if it seems to make sense for you, though it might be strange if everyone does it. Maybe you would want to rephrase the sentence somehow though. I changed Boston, Mass to Boston, Massachusetts since Mass makes very little sense to anyone not familiar with the abbreviation. Cheers. -- Pedro de Medeiros - Ciência da Computação - Universidade de Brasília Email: [EMAIL PROTECTED] - Home Page: http://www.nonseq.net Linux User No.: 234250 - ICQ: 2878740 - Jabber: [EMAIL PROTECTED] ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
