Re: Translating GObject properties names and descriptions

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:

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]