GNOME Bugzilla – Bug 568442
Untranslatable strings
Last modified: 2018-07-01 09:04:52 UTC
There are many strings not marked for translation that should be, for example: "Files and folders" "What Do You Want to Synchronize?" "Drag and Drop a Data Provider on the Canvas" "Show me" and many, many others. Please, make them translatable. Thank you.
*** Bug 572825 has been marked as a duplicate of this bug. ***
note: The config rewrite introduces a shedload of new strings, must mark for translation. Patches welcome
Created attachment 129322 [details] [review] Make UI strings translatable Please find attached a patch which makes the most visible strings translatable. It is not exhaustive, since as I say I've focused on the most visible ones on the UI and left out some related to errors, for which I do not have more time today. In its current form the patch already provides an improvement in localisation, so if the review is positive, it could directly be committed. But even in case it is committed, please leave the report open, as I am intending to look for all non-translatable strings and mark them as translatable as soon as I have more time. A last question, though. Can/should the following strings be marked for translation? photouri = str(properties['Uri']) tags = str(properties['Tags']).split(',') [...] f.set_caption(str(properties['Description']))
(In reply to comment #3) > Created an attachment (id=129322) [edit] > Make UI strings translatable > > Please find attached a patch which makes the most visible strings translatable. Thanks, but this patch was obviously not tested - many of the files modified were missing gettext imports, so just caused Conduit to crash. Please add from gettext import gettext as _ To the start of files if you are going to be using translations from them, and they have not yet imported gettext > > It is not exhaustive, since as I say I've focused on the most visible ones on > the UI and left out some related to errors, for which I do not have more time > today. > > In its current form the patch already provides an improvement in localisation, > so if the review is positive, it could directly be committed. But even in case > it is committed, please leave the report open, as I am intending to look for > all non-translatable strings and mark them as translatable as soon as I have > more time. Cool. Please see my other comment for a quick review of the patch. Thanks for your work on this, it is much appreciated. > > A last question, though. Can/should the following strings be marked for > translation? > > photouri = str(properties['Uri']) > tags = str(properties['Tags']).split(',') > [...] > f.set_caption(str(properties['Description'])) > Im not sure where you are referring, but I think these are strings returned from FSpot.
Comment on attachment 129322 [details] [review] Make UI strings translatable > > if os.path.exists(autostartFile): >- log.info("Removing autostart desktop file") >+ log.info(_("Removing autostart desktop file")) Please do not translate log messages > if update and os.path.exists(desktopFile): >- log.info("Adding autostart desktop file") >+ log.info(_("Adding autostart desktop file")) Please do not translate log messages > #copy the original file to the new file, but > #add -i to the exec line (start iconified) > old = open(desktopFile, "r") >Index: conduit/modules/GoogleBookmarksModule.py >=================================================================== >--- conduit/modules/GoogleBookmarksModule.py (revision 1902) >+++ conduit/modules/GoogleBookmarksModule.py (working copy) >@@ -17,8 +17,8 @@ > > class GoogleBookmarksDataProviderSource( DataProvider.DataSource ): > >- _name_ = "Google Bookmarks" >- _description_ = "Sync your Google Bookmarks" >+ _name_ = _("Google Bookmarks") >+ _description_ = _("Sync your Google Bookmarks") > _category_ = conduit.dataproviders.CATEGORY_BOOKMARKS > _module_type_ = "source" > _out_type_ = "bookmark" >@@ -34,9 +34,9 @@ > def refresh( self ): > #self.Bookmarks = [] > auth_handler = urllib2.HTTPBasicAuthHandler() >- auth_handler.add_password( 'Google Search History', 'www.google.com', self.username, self.password ) >+ auth_handler.add_password( _('Google Search History'), _('www.google.com'), self.username, self.password ) This string is not shown in the UI, and also the GoogleModule has not yet been converted to the new config system, at which time .... > > items = [ > { The following will go away... >- "Name" : "Username", >+ "Name" : _("Username"), > "Kind" : "text", > "Callback" : self.set_username, > "InitialValue" : str( self.username ) > }, > { >- "Name" : "Password", >+ "Name" : _("Password"), > "Kind" : "password", > "Callback" : self.set_password, > "InitialValue" : str( self.password ) ... >- log.warn("Error parsing tomboy note modification time") >+ log.warn(_("Error parsing tomboy note modification time")) Please don't translate log messages >- log.info("Notes are equal") >+ log.info(_("Notes are equal")) Please don't translate log messages >- log.info("Updating note") >+ log.info(_("Updating note")) Please don't translate log messages >- log.info("Saving new Note") >+ log.info(_("Saving new Note")) Please don't translate log messages >Index: conduit/modules/NautilusBookmarksModule.py >=================================================================== >--- conduit/modules/NautilusBookmarksModule.py (revision 1902) >+++ conduit/modules/NautilusBookmarksModule.py (working copy) >@@ -15,8 +15,8 @@ > > >@@ -152,13 +152,13 @@ > import conduit.gtkui.SimpleConfigurator as SimpleConfigurator > items = [ > { >- "Name" : "Sync bookmarks to local places/files", >+ "Name" : _("Sync bookmarks to local places/files"), Will move to the new config system in the next week. >Index: conduit/modules/DesktopWallpaperModule.py >=================================================================== >--- conduit/modules/DesktopWallpaperModule.py (revision 1902) >+++ conduit/modules/DesktopWallpaperModule.py (working copy) >@@ -13,8 +13,8 @@ > > class DesktopWallpaperDataProvider(FileDataProvider.FolderTwoWay): > >- _name_ = "Desktop Wallpaper" >- _description_ = "Changes your Desktop Wallpaper" >+ _name_ = _("Desktop Wallpaper") >+ _description_ = _("Changes your Desktop Wallpaper") > _category_ = conduit.dataproviders.CATEGORY_MISC > _module_type_ = "sink" > _in_type_ = "file" >@@ -35,7 +35,7 @@ > FileDataProvider.FolderTwoWay.__init__( > self, > folder=folder, >- folderGroupName="Pictures", >+ folderGroupName=_("Pictures"), Do not translate this string. In general, so not translate strings if you are not sure that they will be seen in the UI > includeHidden=False, > compareIgnoreMtime=False, > followSymlinks=False >Index: conduit/modules/FlickrModule/FlickrModule.py >=================================================================== >--- conduit/modules/FlickrModule/FlickrModule.py (revision 1902) >+++ conduit/modules/FlickrModule/FlickrModule.py (working copy) >@@ -28,7 +28,7 @@ > flickrapi.set_log_level(logging.NOTSET) > else: > MODULES = {} >- log.info("Flickr support disabled") >+ log.info(_("Flickr support disabled")) Please don't translate log messages >Index: conduit/dataproviders/__init__.py >=================================================================== >--- conduit/dataproviders/__init__.py (revision 1902) >+++ conduit/dataproviders/__init__.py (working copy) gettext not imported, crashes >Index: conduit/Main.py >=================================================================== >--- conduit/Main.py (revision 1902) >+++ conduit/Main.py (working copy) >@@ -55,51 +55,51 @@ gettext not imported, crashes >- help="Generate no debugging information. [default: %default]") >+ help=_("Generate no debugging information. [default: %default]")) Should add note so that translators do not translate %default > options, args = parser.parse_args() > > whitelist = None >@@ -133,7 +133,7 @@ > #make the original process build or show the gui > sessionBus = dbus.SessionBus() > if Utils.dbus_service_available(APPLICATION_DBUS_IFACE, sessionBus): >- log.info("Conduit is already running") >+ log.info(_("Conduit is already running")) > obj = sessionBus.get_object(APPLICATION_DBUS_IFACE, "/activate") > conduitApp = dbus.Interface(obj, APPLICATION_DBUS_IFACE) > if options.build_gui: >@@ -270,7 +270,7 @@ > @dbus.service.method(APPLICATION_DBUS_IFACE, in_signature='', out_signature='') > def Quit(self): > #Hide the GUI first, so we feel responsive >- log.info("Closing application") >+ log.info(_("Closing application")) dont translate log messages
Created attachment 129380 [details] [review] Make UI strings translatable Please find attached a new version of the patch addressing the issues mentioned in the last two comments. >Thanks, but this patch was obviously not tested - many of the files modified >were missing gettext imports, so just caused Conduit to crash. Please add Yes, I apologise for that. It shows me again that there is no such thing as a trivial patch >>- help="Generate no debugging information. [default: %default]") >>+ help=_("Generate no debugging information. [default: %default]")) > >Should add note so that translators do not translate %default I still have not fixed this, since I have to find out how extracted comments from Python files can make it to the POT template. Does xgettext handle those? Thanks for the thorough review, please let me know if there is anything else left to correct.
Created attachment 129437 [details] [review] Make UI strings translatable Updated the patch against head. Not committed yet because I am still unsure what to do about _("<span foreground="red">Failed to connect.</span>") And I have not finished reviewing and testing it yet.
I havent tried the patch extensively, but I didnt had problems so far. Maybe we could use: '<span foreground="red">' + _('Failed to connect.') + '</span>' Or '<span foreground="red">%s</span>' % _('Failed to connect.') Or we could remove the red color entirely, I dont think it's HIG-compliant, and may even interfere with theme colors. And another thing, should this be translated? - raise Exceptions.SyncronizeError("Error creating contact") + raise Exceptions.SyncronizeError(_("Error creating contact")) Some other exceptions had this problem as well. I dont think filling the translation files with exception messages are useful. It would just make the translation more difficult.
Created attachment 132875 [details] [review] Make UI strings translatable Please find attached a new patch ported to git. Comments: * Regarding comments #5 and #6 (writing a comment so that translators do not translate %default): the string is already marked as 'python-format' in the POT file when extracted, in the same way as %s, %d variables are marked as 'c-format' in C. Translators usually know what that means. Furthermore, 'msgfmt -c' checks for those as well. In any case, if necessary, I can add the comments in a separate patch. * Regarding comment #7 (how to mark _("<span foreground="red">Failed to connect.</span>") for translation): I've used the first of Alexandre's suggestions in comment #8 * Regarding comment #8 (translation of exception messages): I believe they should be translated if they are presented to the user. In any case, I have not marked any for translation now. I'd like to hear what you think and I'd then send an additional patch taking care of the exception messages. * I still have not figured out how to: ** Properly mark the strings in the data providers pane for translation. They are extracted and appear in the POT file, but gettext does not show the translations at runtime. Reference [1] ** The data provider statuses' translations from DataProvider.py are also not shown at runtime. I think I could just simply enclose every instance of STATUS_* in _(), but I did not dare to do that, since I do not quite understand its effects (the strings there are not only used to be shown in the UI, but also in the program). [1] http://docs.python.org/library/gettext.html
Did anyone have a chance to look at the patch? Thanks.
Yeah, sorry I forgot to get back to you. I have applied it and pushed to http://github.com/nzjrs/conduit/tree/bug-568442 I am waiting for Alexandre to finish the config branch stuff, and then it can go into master. That way the translators can deal with all the new strings at once. John
Thanks a lot for commiting this, John. Please let me know when this is commited to the master branch, and then I'll try to deal with the pending issues I mentioned in comment #9.
(In reply to comment #12) > Thanks a lot for commiting this, John. > > Please let me know when this is commited to the master branch, and then I'll > try to deal with the pending issues I mentioned in comment #9. > Hi David, I commited the pending config changes, it probably conflicts with your patch. I made some changes on the translation strings as well, but I've not yet committed them, so I could wait for your answer. Could you update your patch with the latest code? Thanks
(In reply to comment #13) > (In reply to comment #12) > > Thanks a lot for commiting this, John. > > > > Please let me know when this is commited to the master branch, and then I'll > > try to deal with the pending issues I mentioned in comment #9. > > > > Hi David, I commited the pending config changes, it probably conflicts with > your patch. I made some changes on the translation strings as well, but I've > not yet committed them, so I could wait for your answer. > Could you update your patch with the latest code? > > Thanks > I applied your patch in my computer to the master branch, and it applies cleanly. It's probably missing the Google changes, but I already fixed that. Here are a few comments about the patch: * From comment #9, you said you did not put dataproviders status for translation, but for some reason they were marked for translation before, however you removed it and marked with N_, I didnt understand why. * You also marked other things as N_ in several other modules. Is there a reason? * You marked the TestModule for translation, however I do not think that is necessary. The test dataproviders only appears when running uninstalled and is only a developer feature. It will only distract translators from what is more important. That's my opinion anyway. * In line 294 of Module.py, you marked _(comment), shouldnt we mark strings in Knowledge.py instead? You did something similar on UI.py * On the Flickr dataprovider you marked "None", however that should not be translated, that value is used in the settings serialization. In the image dataprovider there is also a "None" string which should be translated for now, but that is a bug we should fix later. * Some of the changes in the patch are only about whitespaces, probably because of your editor or something. It makes it harder to evaluate your patch. That is my personal opinion tough. Thanks for your hard work, it looks great. Looking forward for commiting it.
Hi Alexandre, I will not have time until next week to address all the points you are mentioning, but I'll quickly comment on a couple of them: > * From comment #9, you said you did not put dataproviders status for > translation, but for some reason they were marked for translation before, > however you removed it and marked with N_, I didnt understand why. > * You also marked other things as N_ in several other modules. Is there a > reason? [...] > * In line 294 of Module.py, you marked _(comment), shouldnt we mark strings > in Knowledge.py instead? You did something similar on UI.py This is due to the way the variables are defined, which requires using deferred translations [1]. [1] http://docs.python.org/library/gettext.html#deferred-translations
Created attachment 137124 [details] [review] Make UI strings translatable Hi Alexandre, Please find a new patch against the current git HEAD addressing the issues pointed out on your last comment.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. Will push to master later today
Having a look at git.gnome.org, this still hasn't been committed. Could someone please commit it, as per the previous reviews and last comment? I would also like to ask you to leave the bug as opened. The two issues mentioned at the end of comment #9 are still not solved in the patch, but I'd like to have the patch committed as it is before I start looking into that. I'd prefer that the patch does not bigger and then concentrate on those separately.
(In reply to comment #18) > Having a look at git.gnome.org, this still hasn't been committed. Could someone > please commit it, as per the previous reviews and last comment? Yes, I am an idiot and forgot to push. Done now. > > I would also like to ask you to leave the bug as opened. The two issues > mentioned at the end of comment #9 are still not solved in the patch, but I'd > like to have the patch committed as it is before I start looking into that. I'd > prefer that the patch does not bigger and then concentrate on those separately. > Re-opened accordingly.
Conduit is not under active development anymore, has not seen code changes for eight years, and saw its last tarball release in 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/conduit/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.