Call for translations & QA for bzr-explorer 0.4

[Stephen J. Turnbull]

Philippe Lhoste writes:

 > One think that annoy me in this Gettext idea, it the lack of information 
 > on the strings: are they for a button, a tooltip, a field label, a 
 > dialog title, etc.? Depending on placement, capitalization, among other 
 > things, is different.

Can't you get (stylistic) capitalization information from the English
version?  (I know that German *conventions* for capitalization differ
from English, for example, but I don't think it's context dependent.)
Note: I'm not criticizing, I'm curious.

Also, one of the points of the gettext implementation is that the same
string may appear in multiple places (eg, it might be that the
"update" command appears as *all* of a button label, a value for
plugging in to a "variable" tooltip, a field label -- suppose you have
multiple backends available such as bzr-git and bzr-svn, then the
field might specify the backend and subcommand used for update -- and
the dialog title!)  If (as would be the case for many languages, for
example in Japanese it is almost always possible to make a word choice
such that the noun is ACTION and the verb is equivalent to "do ACTION")
the translation would be the same, why translate it multiple times?

Note that the old X style of internationalization using resources
provides exactly the information you request (ie, the exact widget
which will display the string), and translators hated it.  I'm not
denying the importance of the information you request, simply
cautioning "be careful what you wish for, you might get it" :-).
Designing an interface to provide what you request is likely to be
quite difficult, based on past experience.

There is an existing compromise: for programmers, gettext interacts
well with the tags facility (etags/ctags).  If you use Emacs, in
po-mode, M-. will jump to the source of the string.  I suppose vim has
a similar facility, and I would assume Eclipse and other IDEs have
ctags support.

 > Likewise, some strings can be translated differently depending on 
 > context. For example Update.
 > As a dialog title, it is a noun, I will translate it as Mise à jour.
 > As a menu item, it is a verb, translated to Mettre à jour.

This is a known problem.  I thought gettext had a way to deal with
this (ie, a way to give the same string multiple translations
depending on context), but I can't find it.  I guess you are stuck
with deciding which is less ugly: treating verb context as a noun, or
a noun context as a verb.

You could also report a bug against the dialog title or menu item, and
suggest an alternative wording that would disambiguate.