GNOME Bugzilla – Bug 387579
PluginInfoAttribute is not easily localizable
Last modified: 2008-02-27 01:30:40 UTC
The attributes of a plugin (which are shown in the preferences UI) are not translatable (i.e., cannot use Catalog.GetString () to provide a localizable description of the plugin).
Well, Catalog.GetString could be used within the getter/setter methods of localizable properties (Name, Description), or we just use Catalog.GetString when accessing those properties. Problem: How let xgettext recognize those localizable strings. As xgettext supports custom keywords via the -k switch, PluginInfoAttribute could get a new contructor taking name and description as argument. "-k PluginInfo:1 -k PluginInfo:2" would have to be passed to xgettext.
Mathias, Have you had a chance to tinker around with this idea (comment #1)?
By reading intltool-update I've learned, that you can have a variable called XGETTEXT_KEYWORDS in po/Makevars or po/Makefile.in.in. Well, but have to try this out, as the level of obfuscation Perl allows makes me wonder, if OpenSource licenses really are applyable to Perl programs...
Grr: xgettext considers only the first keyword spec if there are several keyword specs for the same function.
Created attachment 81727 [details] [review] A solution for the problem This patch addresses the problem by placing a Makevars file in po tagging PluginInfo as localizable. As position of the localizable strings has to be fixed I added some constructor to PluginInfoAttribute. Unfortunatly xgettext doesn't expect two arguments of a function to be indepentently localizable. As we need just two arguments (Name and Description) I've used the plural feature of gettext to get both strings into the pot file. To get things right this pot file has to be post-processes by my quickly hacked adjust-plugin-info script. As Makefile.in.in is pulled by gnome-autogen from some fixed location, I have no idea yet how to integrate this script into the build system.
Created attachment 81742 [details] [review] A clean solution for the problem. No I've got a clean solution for the problem: Replaced "adjust-plugin-info" by a trivial shell script called "pot-update" and tell intltool-update to use this script instead of xgettext. Inside this script xgettext is called twice with all the parameters intltool-update passes. First time switches are injected to extract plugin names. Second time switches are injected to extract plugin descriptions and to merge the results of this run with the results of the first run. BTW: The patch also contains some information about updates to the svn:ignore property. Would be nice if you also would apply them. Guess you have to do it manually - unfortunatly.
Well, and pot-update.in doesn't have to be executable. Appears that svk (unlike svn) doesn't track the svn:executable property automatically.
Created attachment 81799 [details] [review] Patch that accounts for older versions of xgettext Way to go Mathias figuring this out. This patch includes your latest fixes to account for older xgettext versions. It also adds the plugin info attribute to the remaining plugins.
Committed to SVN.
This is fixed in 0.5.6.
Modifying default assignee and qa contact to be tomboy-maint@gnome.bugs.