GNOME Bugzilla – Bug 342042
plugins create menus items which are not translatable
Last modified: 2019-03-23 21:09:01 UTC
While looking on french translations for dapper I noticed that the Tools menu has some item that are apparently not translatable, strings like "Directory Listing". Are other distribution shipping with the plugins or is that something upstream doesn't recommend to do yet?
Well, sadly, tools labels are not translatable yet. Hopefully they will be for next release.
Just to clarify, note that those labels are the name of the tools which can be defined by the user, so the user is expected to type the name in his preferred language... The issue is that we ship some tools predefined as an example. The user is free to delete those tools if he doesn't need them or rename them to another name, including the translations. I am not sure that blindly translating them is a good idea either, suppose that the user adds a new tool and names it "Copy" or something like that, gedit should not use the translations of Edit->Copy...
I think we should add a way to translate names and descriptions of the sample tools we distribute. I think we can do it as we do with taglists files or as we do with .lang files in gtksourceview. While we are at it we should also review the tools and add only useful ones (note that ATM I don't know which are the default tools, so may be they are all perfect).
Well, default tools are quite crappy since they are basically tools I made as test cases. They may be useful though, but they're not the best ones we could ship. The translation case is handled just fine with the new tool storage backend I'm writing now (on a side note, it also allow to have system and private tools, as snippets do). I just need to take time to finish it, hopefully before 2.16.
nud, so can this be closed now?
Unfortunately it can't, the i18n part hasn't been implemented yet.
Created attachment 78926 [details] [review] patch 1 This doesn't work because of bug 389561.
Created attachment 78927 [details] [review] patch v2 This follow pbor's idea: tools are in fact splitted into a script file and a desktop file, that are merged at build time. The latter is translatable using intltool the usual way.
Ok, the patch seems pretty good to me. I am just pasting here the comments I made on irc. * it needs comments (one in Makefile.am and a longer explanation in the merge script itself, with references to this bug) * I am not thrilled by causing dupe tools, even if this affects only people testing the beta *and* installing from source. Nud said it should be possible to avoid that without much pain. * adding a build time script in python scares me a bit, but afterall this plugin is built only if python is detected so it's not that bad. On irc I raised the idea of doing the merge at run time instead of build time (that is, support both tools with metadata embedded in a comment and tool with metadata in an external file with the same name of the tool plus a '.tool-data' extension. However it's true that this would make things a bit more complicated and would also have the downside of not allowing to easily copy a shipped tool within and edit it with a text editor, which was one of the main reason for embedding the metadata. Paolo, what do you think? Either way we need to adress this before the string freeze
Created attachment 79001 [details] [review] patch v3 This one uses a perl script (intltool uses perl too) and remove the .tool suffix to generated files.
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.