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)?
Best regards, Colomban
PS: Ah, and on a similar topic, why does main_locale_init() call textdomain()? I think it is useless (and probably pointless) since it might be re-set to another value by another plugin, and anyway a plugin should probably only use dgettext() (or glib/gi18n-lib.h's _()).