hi Sébastien; On 17 February 2014 18:49, Sébastien Wilmet <[email protected]> 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/ _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
