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 _()).
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 :). 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. 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
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 :).
Regards, Enrico
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 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.
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 confess that I didn't think this could have been raised and let apart -- 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.
Hum, well, I read the thread, and it raises the same thinks that I thought about: 1. Is this important? 2. How to implement this? 3. What are the impacts?
To 1, you and I already answered our POV, and Nick seems to think it is -- as far as I can read in the thread.
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.
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. 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.
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.
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. The only objection I see is if somebody won't use main_locale_init() but some manual stuff; e.g. if the main_locale_init() defaults don't fit her needs, but I don't see why it would be so.
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 see this, and I must say that I don't see how this would be possible without re-setting plugin infos after setting up i18n. The only way I see for this to work would be that gettext takes care to bind the translation to the same pointer it would return if no catalogue is loaded. Hum, I don't think this is reasonably implementable or would be implemented by reasonable peoples :-' But of course I can be wrong, indeed if it actually happens (with some plugins?).
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.
Regards, Colomban
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
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
On Fri, 14 May 2010 18:17:36 +0200, Colomban wrote:
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 :)
Haha.
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.
I think that change this is now necessary is really reasonable. And nothing will break if they don't use it (for whatever reason).
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 :/
Because those plugins don't have a separate message catalogue but instead use the one from Geany, i.e. all strings within those plugins are already loaded once you start Geany.
Regards, Enrico
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 :/
Because those plugins don't have a separate message catalogue but instead use the one from Geany, i.e. all strings within those plugins are already loaded once you start Geany.
Yes, but then why would not they be translated /even before/ being loaded? I mean, at the time of the plugin's _set_info() call, the translation catalogue is already set up, and then calls to gettext should work properly -- and they do with the current version.
Regards, Colomban
On Fri, 14 May 2010 19:11:35 +0200, Colomban wrote:
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 :/
Because those plugins don't have a separate message catalogue but instead use the one from Geany, i.e. all strings within those plugins are already loaded once you start Geany.
Yes, but then why would not they be translated /even before/ being loaded? I mean, at the time of the plugin's _set_info() call, the translation catalogue is already set up, and then calls to gettext should work properly -- and they do with the current version.
Sorry, I think I was unclear. Those plugins shipped with Geany will show translated name and description in the plugin manager even before they are actually loaded. This is because, as said, they use Geany's gettext domain and its message catalogue. Loading or not those plugins doesn't matter, translation-wise.
For external plugins it's different. Those are first translated after they have been loaded, i.e. if you open the plugin manager dialog and haven't any external loaded, their name and descriptions are in English (C). If a plugin is loaded and you open the dialog again, the name and description of this plugin should be localised.
(As you know the above about external plugins is a bit different for the geany-plugins project as they all use the same gettext domain but I think you got the point anyways.)
Regards, Enrico
On Fri, 14 May 2010 18:03:13 +0200, Enrico wrote:
Hi,
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.
Committed now to SVN. Thanks a lot Colomban!
Regards, Enrico