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.
Me neither. Before actually looking at this I guessed it to be a quite hard piece; but I will not complain that it wasn't true :)
-- 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.
Thank you, and it should be. But as you might see, I now have found a temporary solution that works pretty well :)
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.
Same for me, but it needs a little (well, really small) work from plugin authors. But it is probably small enough not to be a problem.
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.
Well… for them, why wouldn't they be translated even before being loaded then? Still strange to me :/
Regards, Colomban