After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 342042 - plugins create menus items which are not translatable
plugins create menus items which are not translatable
Status: RESOLVED FIXED
Product: gedit-plugins
Classification: Other
Component: General
2.14.x
Other Linux
: Normal major
: 2.18.0
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-16 22:00 UTC by Sebastien Bacher
Modified: 2019-03-23 21:09 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
patch 1 (19.69 KB, patch)
2006-12-26 21:34 UTC, Steve Frécinaux
needs-work Details | Review
patch v2 (17.35 KB, patch)
2006-12-26 22:37 UTC, Steve Frécinaux
none Details | Review
patch v3 (17.61 KB, patch)
2006-12-28 20:45 UTC, Steve Frécinaux
committed Details | Review

Description Sebastien Bacher 2006-05-16 22:00:33 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?
Comment 1 Steve Frécinaux 2006-05-16 22:59:51 UTC
Well, sadly, tools labels are not translatable yet. Hopefully they will be for next release.
Comment 2 Paolo Borelli 2006-05-17 07:19:33 UTC
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...
Comment 3 Paolo Maggi 2006-05-17 08:46:37 UTC
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).
Comment 4 Steve Frécinaux 2006-05-17 11:23:44 UTC
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.
Comment 5 Paolo Borelli 2006-12-24 10:59:25 UTC
nud, so can this be closed now?
Comment 6 Steve Frécinaux 2006-12-24 12:14:38 UTC
Unfortunately it can't, the i18n part hasn't been implemented yet.
Comment 7 Steve Frécinaux 2006-12-26 21:34:08 UTC
Created attachment 78926 [details] [review]
patch 1

This doesn't work because of bug 389561.
Comment 8 Steve Frécinaux 2006-12-26 22:37:19 UTC
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.
Comment 9 Paolo Borelli 2006-12-28 15:22:29 UTC
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
Comment 10 Steve Frécinaux 2006-12-28 20:45:18 UTC
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.
Comment 11 Steve Frécinaux 2006-12-28 21:04:53 UTC
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report.