GNOME Bugzilla – Bug 152742
menu not translateable
Last modified: 2004-12-22 21:47:04 UTC
The menu system of the 4.4 series of gcalctool cannot be translated. Tested with 4.4.8, 4.4.14 and 4.4.18 (the current one of the 4.4 ones). There are two problems. One is that the four always visible elements of the main menu are not even marked to be gettextized, hence they're even missing from the .pot and .po files. The other is that the whole menu system is built up with N_("...") stuff which should be explicitely translated at run-time but they aren't. Patch is attached. Maybe not the cleanest one, but works for me.
Created attachment 31587 [details] [review] worksforme fix
Hi Egmont. Thanks for this. What I'm confused about is why this wasn't reported by one of the other translators. We are too late for GNOME 2.8, but can this now be changes for 2.8.1.? Adding Christian to the cc: for his thoughts on this.
One could just aswell argue that developers should have caught this, using roughly the same reasoning. Translators don't always test everything, because then there would be no time left for actual translation. The translation burden has increased dramatically with the GNOME 2.8 release, because of the inclusion of Evolution and other pieces of software. It should be no surprise that translators often rely on testing being done by others. Regarding the patch: Egmont, please don't touch the hu.po file, unless you have approval from the responsible Hungarian translator or the Hungarian translation team coordinator. Regarding string freeze: This patch breaks string freeze. Please follow the steps on http://developer.gnome.org/dotplan/tasks.html#ApprovingFreezeBreaks for requesting approval to break it. I'm positive that this will in the end be approved, but please request formally anyway, so that all interested parties are properly notified about this problem.
About touching hu.po: I just brought back the translations that were present in gcalctool 4.3.x, and was still present, though commented out, in 4.4.8. Anyway I told it's just a reference worksforme patch, which may differ from what you'd prefer to apply. It was yesterday I learnt what N_() means :-)) Actually I noticed there's a variable declaration in the middle of the code which is only supported by newer compilers, so you might not like that one either. About the string freeze: I don't exactly know the details of this string freeze stuff but please note that my patch doesn't bring new words to the user interface, only gives a chance to translators to translate the text that currently appears in English. I guess this should be allowed every time, though I fully agree that bringing new words to the UI shouldn't be allowed at certain development phases, but this is not that case. Anyway, Gnome 2.8.0 is already released, so we're talking about 2.8.1, aren't we? Is there a complete string freeze through the whole 2.8 series???
This patch is not the right way to do it. I'll attach another variant which might be better. String freeze *is* in effect through entire Gnome 2.8 series. Though, this sounds like something we might want to have fixed, so you'd need to follow through standard string-freeze break approval procedure: http://developer.gnome.org/dotplan/tasks.html#ApprovingFreezeBreaks (On translators not noticing this: it's not that simple, I've tested entire Gnome 2.7 at one point [a couple of months back], but I didn't have complete Serbian translations at that time, so I considered anything that's in English due to that; I lack the time to regularly test all the applications, and I believe it's no better with other translators.)
Created attachment 31605 [details] [review] Call gtk_action_group_set_translation_domain() instead. This patch is tested and works well. I don't mark any new strings since that would break string freeze. 2004-09-16 Danilo Šegan <dsegan@gmx.net> * gcalctool/gtk.c (create_kframe): call g_a_g_set_translation_domain().
A note: I've committed a sr.po and sr@Latn.po translation to gnome-2-8 branch which contain even these unmarked entries translated ("_Calculator", "_Edit", "_View" and "_Help"): you can test with "LANGUAGE=sr gcalctool" to see all the menus translated.
Yes, this patch definitely looks better than my one :-)) I still do not understand, though, why it's so problematic to apply a patch which does not cause any new strings to appear for the user. I guess the goal of the string freeze is that the translators can do a 100% job, once they're ready the desktop is 100% non-English and this is a way to protect against new English string appearing. Current situation is not this. Applying the patch will not cause the desktop in any language to become any worse or more English or less non-English. Does not cause any harm at all. Only gives a chance to become better. Anyway, I reported the bug and fixed it for myself, the rest is not my business.
Egmont, it's not that simple. It's very important that translators can rely on no new strings appearing for translation, and that they're notified about any such (odd) instances. "No new strings" means that they can now concentrate on other stuff, such as HEAD branches etc. Merging translations (actually, PO files) between revisions is much harder than source code, since they're partly automatically generated. "Notifications of new strings" means that they get notified that they need to update some translations, even though they thought about it being finished. If they don't know about it, they might miss it (because they have other things to do). So, the purpose of freeze-approval procedure is not to make it impossible for new strings to be added, it's to make it work better for everyone involved. As I said, I'm of opinion that this breakage is needed because it's fairly exposed (even with my patch, 4 top-level menu entries will be untranslated unless translators added them by hand), but the procedure is there for a reason.
Okay, thanks for clarifying this for me :-)
Email was sent to i18n-list at gnome dot org, gnome-i18n at gnome dot org with a cc: to release-team at gnome orgorg (although I got a bounce from the first alias). If/when I get a reply, I'll adjust the bug accordingly. Thanks everybody.
Created attachment 31641 [details] [review] Mark missing strings for translation As requested by Christian Rose on gnome-i18n list (to be discussed for approval): 2004-09-17 Danilo Šegan <dsegan@gmx.net> * gcalctool/gtk.c (entries): Mark top-level menu entries for translation (fixes #152742).
Rich, Christian approved the string-freeze break (http://lists.gnome.org/archives/gnome-i18n/2004-September/msg00297.html) Ok to commit (both patches, to both HEAD and gnome-2-8)?
Uhm, make that http://lists.gnome.org/archives/gnome-i18n/2004-September/msg00298.html instead ;-)
Danilo, yes please do. I'm guessing you have CVS gcalctool checkouts of gcalctool just ready to do a commit on, so you are more prepared at this point then me. Free free to just check the changes in. Thanks!
Uhm, I've committed these to gnome-2-8 branch, but HEAD seems to already have them, as a result of this change 3 months (!) ago: 2004-06-18 Christian Neumair <chris@gnome-de.org> * gcalctool/functions.c, gcalctool/graphics.c: s/precedencer/precedence/ * gcalctool/gtk.c: Mark missing GtkActionEntry entries in menu entry array for translation. * (create_kframe): Call gtk_action_group_set_translation_domain to enable menu i18n. Marking as RESOLVED/FIXED as well, and notifying gnome-i18n.