Hi Yavor, Today at 9:12, Yavor Doganov wrote:
> On Thu, 14 Jul 2005 14:04:07 +0930, Clytie Siddall wrote: > >> It is essential to know the purpose of the string. Background like: >> _______________ >> Type: menu item >> Function: brings up a dialogue which allows the user to modify >> currently-highlighted text >> Original: Edit >> _______________ >> is much better than just "Edit" on its own. The less information in >> the string, the more explanation we need. > > This would be a substantial burden to the developers. Actually, we should try to explore how to make that not be a burden to developers yet get that information. I already have some ideas for that, but I'm not spending too much time actively hacking on it. For example, many applications use Glade files. With them, we can do many interesting things. For instance, I was planning on doing the following: — load Glade file in, separate segments into "visible at any one time" — load a translation and check for conflicting accelerators — suggest any of the strategies for resolving conflicting accelerators Another use would be to extract such "context" information as Clytie suggested. These are all interesting (and not too hard) projects for anyone having some spare time (I'd be willing to give a lot of help and pointers if needed). Anyone can start by subscribing to gnome-i18n-tools[1] list (didn't have any traffic so far, so I want to activate it), and lets discuss such tool development there. [1] http://mail.gnome.org/mailman/listinfo/gnome-i18n-tools We should not just say that something is hard and give up, we should instead try to look for solutions for problems we have. Even if it means it will work only for a subset of all translatable programs (i.e. those using Glade), it's still a big win, IMHO. > Absolutely off-topic, for which I apologise: I've noticed that you're > quite actively translating GNOME and debconf templates. How can you > possibly do this effectively if you are not running a GNU system? Apple > Mail, AFAIK, runs only on the proprietary system MacOS X. We had one > translator in the past who was blindly translating on Windows and the > result was pretty painful -- all translations were a mess. That usually > happens when there is no possibility to test the translation. I mostly agree with you, but it's actually possible to run GNU software on MacOS/X (I've ran across numerous mentions of some repository named "fink", etc.). Also, it's up to end users of a translation to deduce how good is it, so lets leave complaining to native vi users and other vi translators. > Most of the code is very well commented, so if you doubt for a particular > string you can always checkout from CVS and open the relevant file in > another buffer of Emacs ;-) Or you can always check how other people have > translated it (f.i. our team is "using" the experience of the Russian, > Serbian and Macedonian teams). These are actually only work-arounds. We want to lower barriers to translation, and while these are all same things that I use, I don't want to make every translator use them: it wastes their time, just like it wastes yours and mine (if you had most entries marked with "button" or "menu item", I guess you'd need to look elsewhere at least a bit less often, and we can get that, as I described). > There are some strings which are ambigous, but you can always test your > translation and make the right decision. Asking the developers to comment > every string in detail sounds crazy (at least to me). Indeed: the goal is to help translators waste less time, but not at the cost of extensively increasing workload of developers. We should meet somewhere in the middle, and that's what we're doing now (we're asking developers to comment on any ambigous messages). Recommended practice is still the following: 1. translate 2. check translation extensively by running translated program, watching for inappropriate translations (out of context), conflicting accellerators Currently, 2nd step is still very hard, so lets try to make it much simpler. Maybe I'm wrong and it's no improvement at all, but why not try it first? Cheers, Danilo _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
