Re: Translating GObject properties names and descriptions

[Emmanuele Bassi <ebassi gmail com>]

hi Sébastien;

On 17 February 2014 18:49, Sébastien Wilmet <swilmet gnome org> wrote:
> Hi again,
>
> GObject properties names and descriptions are usually translatable (and
> translated) for tools like gtk parasite or glade. It seems that it has
> always been like that. But is there a really good reason?

this blog from Stack Overflow about the introduction of their
localised version in Portuguese gives a nice introduction to the
issue, and some very interesting discussion points:

http://blog.stackoverflow.com/2014/02/cant-we-all-be-reasonable-and-speak-english/

in short: increasing the localization of documentation for non-English
speaking developers increases the visibility of those developers to
the overall community, and that is a good thing.

> GObject properties are targetted to the developers. All our APIs are
> written in English, so why do we make an exception for properties?
> Developers generally work in English. The translations are more
> targetted to the users, not the developers.

it's important to note that what is being translated is not API: it's
the "nick" and "blurb" fields of GParamSpec, which are a user readable
name and description of the property. the property name, i.e. what you
would use use with g_object_set(), g_object_get(), or any other
function using the property name string, is left untranslated. if it
*is* translated, then it's a bug, as it would modify the API depending
on the locale.

in reality, though, there's a bit of an issue at play; in general, the
"nick" is used as a replacement of the property name inside a GUI,
like you correctly said. the blurb is used to generate documentation,
except that every self-respecting maintainer of a library will likely
use a gtk-doc annotation to describe the property, as the
documentation can be arbitrarily long, include examples, and
annotations — whereas the "blurb" field really shouldn't. some tools I
think use the blurb for tooltips, but that's fighting against the API
reference; I'd rather have Glade allow clicking on a property, and
directing me to the corresponding field in DevHelp.

so, we have two different fields being used for two different results,
but conflated in the same API.

> Moreover, those strings can be hard to translate without the context.

this is very true.

> So, it is a lot of work for translators without much gain.

you *can* just ignore the properties translation; sure, it's a problem
if you're trying to reach 100% coverage, but realistically we could
simply teach damned-lies to ignore some module.

> Do you think it is a good idea to remove the _() around the strings?

from a library maintainer perspective, I'd probably remove the
localization around the "blurb" field — or even set it to NULL, given
that it's pretty much pointless. I'd still keep the localization of
the nick: a GUI half in english and half in the user's language would
look pretty poor to me.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/