[Geany-devel] About translation of plugin name and description

Fri May 14 16:03:13 UTC 2010

On Tue, 11 May 2010 00:54:36 +0200 (CEST), Colomban wrote:

> > On Mon, 10 May 2010 00:12:47 +0200 (CEST), Colomban wrote:
> >
> >> Hi,
> >>
> >> I just wondered why my plugin's name and description wasn't
> >> translated since every other part of my plugin was. But a little
> >> thinking made me realize it's completely "normal": of course
> >> bindtextdomain() wasn't already called for my plugin when
> >> plugin_set_info() is called, which explains it all.
> >>
> >> And then, how to solve this? The easy and naive solution would be
> >> to call main_locale_init() in the top of plugin_set_info(), but it
> >> doesn't work since geany_functions isn't set at this time. A manual
> >> call to bindtextdomain() and friends of course solves the problem,
> >> but we lose the cool things that both main_locale_init()
> >> (simplicity, consistent Windows support, etc.) and
> >> PLUGIN_SET_INFO() brings.
> >>
> >> I think something like PLUGIN_SET_TRANSLATABLE_INFO(localedir,
> >> package, name, description, version, author) (or any other better
> >> name) would be a solution: it would call main_locale_init() (or
> >> manually do the stuff main_locale_init() does) and then set the
> >> plugin infos. In facts, it would only need to set geany_functions &
> >> friends /before any/ plugin function call -- even
> >> plugin_set_info(). OTHO, it pollutes a bit gettext's "database" by
> >> binding (and perhaps loading?) almost useless translation domains
> >> -- since the plugin might not be loaded -- but it probably can't
> >> be avoided if we want translations at this point.
> >>
> >> What do you think? Do you see (an)other solution(s) to fix this? Do
> >> you think it worth it (I definitely think so but still)?
> >
> > I personally don't think it's strictly necessary, though of course
> > it would be nice. But then, I personally also use en_GB as locale
> > so I almost always get the correct string :).
> The reason why I personally think it is important is both for
> consistency (all Geany is -- or may be -- translated), and usability:
> even though I think that most Geany users understands at least a bit
> of English, I don't think it should be a necessity. Then, proper
> translation of plugin description (name is less useful since it can
> be an arbitrary name that shouldn't be translated at all) seems
> somewhat "needed" to me (take it relative though).
> But I can easily understand that you don't think it is that
> important, and it is probably true that it is more an improvement
> than a need.
> 
> > PLUGIN_SET_TRANSLATABLE_INFO is an interesting idea, are you sure
> > that would work? I didn't test it at all, so I'm just curious. I
> > guess the former question will make you testing it and once you had
> > enough code to test it, you probably also will send a patch, I
> > guess :). If so, cool. If not, also cool.
> Haha, trying to delegate the work to the one that asks is always the
> way to go, I must admit! :D

I didn't try to delegate it to you, honestly. I just guessed you will
try it anyway and I was right :). I didn't mean to ask you to do :).

> Hum, more seriously: I already tried (by using direct gettext calls)
> and yes -- I would say of course -- it works fine. Even better, you
> succeeded to make me hack Geany in order to implement it directly
> (see attached patch) and yes again, it works well (and don't need so
> much code change finally).
> In practice, I moved geany_functions and geany_data assignation from
> plugin_init() to plugin_new() for them to be set before the call to
> plugin_set_info(); and added the PLUGIN_SET_TRANSLATABLE_INFO() macro
> that calls main_locale_init() before setting the info fileds.

Awesome.
That looks fine to me and it works well.
I didn't expect it to be that easy.

If Nick nor anyone else see any problems with this, I'd like to commit
it.

> > At least this topic raised a few times (I think to remember at least
> > two times).
> > Ah, just found the last discussion:
> > http://lists.uvena.de/pipermail/geany-devel/2009-September/001281.html
> Oops, I didn't even think to search the archive about this. I must

No problem.

> -- and haha, I'll use the excuse that I'm not using my regular
> computer since it is broken for now. Yes I know, it isn't a so good
> excuse, but who cares? Sorry, back to pointful things.

Hope things will get back to normal soon for you.

> To 2, I think we would all agree that simply calling
> main_locale_init() in plugin_set_info() is probably the best solution.
> I think the idea of Eugene to add a plugin_loaded() plugin function is
> quite elegant, but I also think it is completely overkill for this --
> and I don't see why a plugin would use it apart i18n initialization.

Agreed.

> 3 is the more complicated and probably controversial point:
> 
> As raised in the mentioned thread, the biggest point is that it would
> load the entire translation catalogue for each plugin, even if only
> the the name and descriptions have to be translated when the plugin
> isn't loaded. I see no obvious way to address this. The only way I
> see would be to have a separate catalogue for this, but I don't think
> it is a good idea: it would be harder to set up (two catalogues need
> manual calls to dgettext() and fine build system tweaking) and it may
> even be a worst solution if the plugin gets loaded finally.

Yeah, a separate message catalogue is not an option.

> I personally think that the catalogues are probably not that big.
> Geany's French translation file is about 100kb, and my plugins'
> French translation file is about 7kb. Even without benchmarking
> actual memory usage, I think we can safely say that 100 (!) plugins
> would probably not use 1mo for translations. I might then say that
> it's probably acceptable. Moreover, with geany-plugins plugins it is
> even less a problem since they share their catalogue, which means
> that it is loaded anyway if one of the plugin is loaded.

And as a side effect, only one of the geany-plugins plugins need to
call PLUGIN_SET_TRANSLATABLE_INFO() and all others benefit from it even
when "only" using PLUGIN_SET_INFO().

> The other thing is allowing plugin_set_info() to call Geany
> functions, and then have both geany_function and geany_data set. I'm
> pretty sure this doesn't change anything for memory usage (only 2
> pointers are set in order to point to Geany's internal data), and I
> think that the computing overhead (two module lookups, tests and
> pointer affectations) is more than reasonable.

Probably.

> Eugene also suggested a way -- he qualified ugly -- to integrate this
> to the current API, based on checking if LOCALEDIR and
> GETTEXT_PACKAGE are set. I don't think this is that ugly:
> * Most plugins with translations probably already use these constants
> names since they are quite conventional;
> * If these constants are defined, it is very unlikely the plugin won't
> setup i18n.

Your solution seems cleaner to me.

> And finally, on the thread I see that you (global) say that when the
> plugin gets loaded, the name and description are translated? I don't

I think this is true only for plugins shipped with Geany itself as
those use Geany's gettext domain.

> >> PS: Ah, and on a similar topic, why does main_locale_init() call
> >> textdomain()? I think it is useless (and probably pointless) since
> >> it
> >
> > To be honest: because I found it somewhere else and used it as well.
> > This happened as one of the first steps of Geany's lifetime long
> > time ago when I had a lot less experience. And since then, I just
> > didn't touch the code anymore since it worked :).
> Oh, ok, fine then. But it can probably be removed the next time you
> touch the function -- even though it is harmless.

Now removed in SVN.

Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20100514/75b12091/attachment.pgp>