Finding context for strings (was Re: gnome-doc-utils strings)

[danilo gnome org (Danilo Åegan)]

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