GNOME Bugzilla – Bug 586063
Glade doesn't allow to set messagedialogs' text as translatable.
Last modified: 2009-06-24 08:33:39 UTC
Please describe the problem: messagedialogs have "text" properties which are arbitrary messages, and hence should be translatable. Instead, they're not. Steps to reproduce: 1. create a MessageDialo 2. set it text to any content 3. save 4. run xgettext on the produced file Actual results: The string is not catched by xgettext (since it has no "translatable" attribute in the .glade file) Expected results: To have a possibility, exactly with labels, to specify that string is translatable. Does this happen every time? yes Other information: xgettext works fine if a manually set "translatable"
Notice the bug applies for "text" field and also for "secondary text".
Fixed in master, thanks for reporting :)
Great, thanks. Possibly forgive my ignorance, but can't the fix be replicated on stock labels? I mean: the real fix for bug #126053 ("glade-3 incorrectly marks as translatable stock Gtk buttons") is probably to disable translation on stock items, but allowing one to enable/disable it via the interface would already be better than nothing.
stock ids are better represented in thier own property, in the case of GtkButton, it uses the label property, the label property is translatable. Yes, something could ultimately be done to special case the already specially cased gtk button but why ? just because it gives people a funny feeling in their stomach to see translatable="yes" on a stock id in the Glade file ? I still fail to see the negative side effects of this so called bug, as specially compared to the non-trivial work involved in "fixing" it.
Currently in the average programmer's workflow those stock labels go into .pot and then .po files. They're a problem for translators which don't know what they mean, and if they somehow translate them, they are an even bigger problem for users, since the "localized stock name" is unknown to gtk. So what are you saying? - That it's xgettext which should be fixed to not consider stock ids, even if they have "translatable = yes"? - That it's normal for a programmer, after he creates a Glade file, to manually open the xml and change each stock to translatable="no"? - That it's normal for a programmer, after he creates a .pot file, to manually open it and remove every stock label? - That it's normal for a translator - usually on a very translator-friendly system like Launchpad's Rosetta - to know about gtk internals and understand gtk-* is a stock label and shouldn't be translated?!
(In reply to comment #5) [...] > - That it's normal for a translator - usually on a very translator-friendly > system like Launchpad's Rosetta - to know about gtk internals and understand > gtk-* is a stock label and shouldn't be translated?! > Yes mister exclamation mark, this one would probably be best, to just ignore those. At this point, the only problem (with bug 352446 btw) is the distaste of seeing "gtk-ok" and such in po files. Its like bug 585430, wouldnt it be nice if Glade files would always serialize in exactly the same order ? I mean get serious. Want to hire someone to actually work on Glade ? Until then you have to understand I must keep my priorities straight, I wasted an afternoon the other day fixing bug 572756, I really could have spent that time fixing cross-project widget pasting that breaks with object references, or internalizing accel-groups so that menus and accelerators are actually usable.
I never said it wasnt a bug, I just said it wasnt important enough to deserve my attention. So in that spirit, I should at least say: See plugins/gtk+/glade-gtk.c:glade_gtk_button_write_widget(). If that doesnt exist it can be added via plugins/gtk+/gtk+.xml.in. From glade_gtk_button_write_widget() you should be able to dup the property and write it as non translatable, without interfering with the widget metadata and undo/redo. Have fun.
I obviously respect your priorities (not your opinion on the current workaround, since people knowing about gtk internals have better to do than to translate on Rosetta, but never mind), and didn't notice I was referring to a dup of something you already had commented, so sorry. I'll try to understand the hints you gave and write a patch; for the moment, I copy them to bug 352446 and stop commenting here.