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 654883 - [L10N] Impossible to translate string concatenations for 'Export ...' + export method
[L10N] Impossible to translate string concatenations for 'Export ...' + expor...
Status: RESOLVED FIXED
Product: tomboy
Classification: Applications
Component: General
unspecified
Other All
: Normal normal
: ---
Assigned To: Tomboy Maintainers
Tomboy Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-07-19 05:34 UTC by Tommi Vainikainen
Modified: 2011-08-30 22:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Make strings l10n friendly (2.63 KB, patch)
2011-07-19 20:47 UTC, Tommi Vainikainen
accepted-commit_now Details | Review

Description Tommi Vainikainen 2011-07-19 05:34:45 UTC
Following strings are impossible to translate, because intltool/xgettext imports strings as containing only first part, and then beffore gettext call is made runtime, strings are concatenated with method of export e.g HTML.

#: ../Tomboy/ExportAllApplicationAddin.cs:53
msgid "Export All Notes to "

#: ../Tomboy/ExportAllApplicationAddin.cs:54
msgid "Start exporting notes to "

#: ../Tomboy/ExportAllApplicationAddin.cs:58
msgid "Export selected notebook to "

etc.
(there is more than those three in the same file.)

Simply said, one should not concatenate strings before or after gettext call if possible, but instead use strings such as

Catalog.GetString ("Export All Notes to {0}") and then call e.g. String.Format to fill {0} container.
Comment 1 Robert Nordan 2011-07-19 08:19:03 UTC
It seems translation is one thing I could have thought a bit harder about... 

Looks like the only place that really needs to be fixed is the Initialize() method, with user-facing strings. Bug 654865 and patch fixes the problem in ExportMultipleDialog. (I noticed there are a number of Logger.Error messages in other methods that are translated, if I've understood correctly they're not supposed to and so maybe we should remove those getStrings.)

Semirelated thought:
The pretty name (e.g. "HTML Files") is translated in the subclassing add-in and is fine for our HTML exporter, but unfortunately we cannot know what sort of pretty name will be given by any community add-ins that use the export all class. So for instance, "Export All Notes to Plain Text" becomes something like "Eksporter alle notater til Plain Text" in Norwegian even after we fix these l10n hiccups. Is that something that could be remedied after we set up a community repository?
Comment 2 Tommi Vainikainen 2011-07-19 20:47:48 UTC
Created attachment 192264 [details] [review]
Make strings l10n friendly

This patch makes all those strings localization friendly that I could find from the file Tomboy/ExportAllApplicationAddin.cs.
Comment 3 Robert Nordan 2011-07-19 20:53:56 UTC
Review of attachment 192264 [details] [review]:

Looks good to me. Note that this patch will also close Bug 654865 and render Aaron's patch there unnecessary.
Comment 4 Tommi Vainikainen 2011-07-19 21:03:09 UTC
Also patch from Bug 654865 should be committed in addition to my patch, because that string was not contained in my patch here.
Comment 5 Robert Nordan 2011-07-19 21:08:17 UTC
Sorry, I messed up (getting sleepy :P ). Quite right, disregard my previous comment. Both patches should be committed.
Comment 6 Tommi Vainikainen 2011-08-30 09:17:43 UTC
String freeze for GNOME 3.2 is coming in a week. Is it possible to commit this soon? I can commit too with maintainer approval as I've commit access as a translator.
Comment 7 Sandy Armstrong 2011-08-30 16:05:44 UTC
Feel free to commit Tommi, thanks!
Comment 8 Sandy Armstrong 2011-08-30 16:05:59 UTC
Review of attachment 192264 [details] [review]:

Great, thanks!
Comment 9 Tommi Vainikainen 2011-08-30 20:23:15 UTC
Now committed.
Comment 10 Sandy Armstrong 2011-08-30 22:25:30 UTC
Thanks!