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 _()).