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 352446 - Translated stock ids
Translated stock ids
Status: RESOLVED FIXED
Product: glade
Classification: Applications
Component: general
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
: 412657 430450 522544 575382 (view as bug list)
Depends on:
Blocks: 412657 414576
 
 
Reported: 2006-08-22 19:34 UTC by Tristan Van Berkom
Modified: 2009-06-25 17:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tristan Van Berkom 2006-08-22 19:34:07 UTC
Some properties are used as stock ids in some cases but not in all
cases, for example the label text on a GtkButton or a GtkMenuItem,
combined with "use-stock" property - will be used as the stock id itself.

Glade should ensure that these properties are not marked for translation
when the button/menu item is being configured for a "stock" setup.
Comment 1 Steve Frécinaux 2007-03-15 20:17:34 UTC
An alternative would be to (at least) allow one to mark a label as not translatable, in order not to have that much junk in the po files. Currently the only way is to edit the .glade file in a text editor.
Comment 2 Tristan Van Berkom 2007-03-20 17:52:25 UTC
All translatable strings come with a "..." button for the i18n dialog.

You can set it manually there - the problem is that a buttons label
by default is translatable, when that property is used to depict a
stock id, then it shouldnt be translatable - and the user shouldnt 
have to set it manually.
Comment 3 Steve Frécinaux 2007-03-20 18:31:49 UTC
This "..." button is not sensitive when STOCK is chosen as the button type.
Comment 4 Tristan Van Berkom 2007-04-17 14:03:27 UTC
*** Bug 430450 has been marked as a duplicate of this bug. ***
Comment 5 Claudio Saavedra 2007-04-17 14:27:50 UTC
A solution could be to set the "translatable" property to FALSE when the button type is set to "Stock" -- my blind guess is that there is a callback for that (where the "label" entry and label are set insensitive).
Comment 6 Tristan Van Berkom 2007-04-17 14:51:50 UTC
Unfortunately its not that simple, when a property changes we
cant just go and blindly change another property - this introduces
inconsistencies with the use of Undo/Redo.

The planned architectural solution for this is to add a widget-class
level plugin delagate method that would allow the gtk+ plugin for
instance to issue the commands in the place of the core, it would
look something like in pseudo code:

glade_gtk_button_issue_command (...) 
{
   if (command_type == SET_PROPERTY &&
       property_to_set == STOCK)
   {
      glade_command_push_group ();

      /* Do 2 separate actions grouped as one */
      glade_command_set_property ( the stock property to set );
      glade_command_set_translatable ( the stock property to set, FALSE );

      glade_command_pop_group ();
   }
}

For the same reasons, we dont allow the user to delete notebook
pages that contain project widgets (thus orphaning the widgets),
but we can remedy this with the afore mentioned solution... just
takes a little bit of serious work :)
Comment 7 Leonardo Ferreira Fontenelle 2007-05-07 05:06:36 UTC
*** Bug 412657 has been marked as a duplicate of this bug. ***
Comment 8 Gabor Kelemen 2009-04-30 10:06:53 UTC
*** Bug 575382 has been marked as a duplicate of this bug. ***
Comment 9 Pietro Battiston 2009-06-24 08:34:56 UTC
I copypaste from bug 586063:

"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.
"
Comment 10 Akhil Laddha 2009-06-24 08:38:55 UTC
*** Bug 522544 has been marked as a duplicate of this bug. ***
Comment 11 Tristan Van Berkom 2009-06-25 17:44:38 UTC
Turns out this was a one line fix, pushed in master,
closing this one finally.