GNOME Bugzilla – Bug 122549
stock icons have no accessible-name
Last modified: 2004-12-22 21:47:04 UTC
It seems that stock gtk+ (or, at least, gnome) icons don't have accessible-names. The plan as I recall it was for stock icons to take their names from the icon-name as used internally by gtk+, since those names are pretty descriptive and better than 'no name' in any case. Example: run GOK without StickyKeys enabled; GOK will post the 'Sticky Keys has been enabled' dialog. at-poke shows that the stock icon inside the dialog has no name, whereas it should have name "dialog-info" (i.e. the gtk name with the 'gtk+' prefix removed), or perhaps the name should be the full string 'gtk-dialog-info'.
Created attachment 20208 [details] [review] Proposed patch
The proposed patch returns the name as "gtk-dialog-info" for the test case given.
Created attachment 20233 [details] [review] Updated bpatch
The updated patch strips "gtk-" from the name of GTK stock icons and "gnome-stock-" from the name of GNOME stock icons.
Padraig: can we return gettext_noop (string); (if NLS is #defined) instead of just string, in your patch? We can then create a list of known gtk+/gnome stock icon names for localization (I am still thinking about how best to do the latter). It may be that we can get the stock-icon-names from gtk+ at build-time and have them extracted by 'make' so that they are marked appropriately for translation (this would keep gail in-sync with the gtk+ version it's built with, translation-wise). I do think we need to at least make a first cut at returning localized names for the stock icons, since atk_object_get_name() is defined to return a localized value and we don't want to tempt ATs into re-localizing these names by some brute-force method.
padraig: I meant 'gettext(string)' and not gettext_noop, in my example above. Sorry!
If we did the following: foreach (stockicon-name) N_(name) then we could return _(icon-name) where stockicon-name is the set of (unlocalized) stock-icon-names, 'name' is one of those names, and icon-name is the return value from gail_stock_icon_get_name().
I do not think that we can return localized names in 2.4.x as it would be a new feature. The GTK stock ids are listed in gtk+/gtk/stock.h. The GNOME stock ids are listed in libgnomeui/libgnomeui/gnome-stock-icon.h. We could manually add the names to gail rather than trying to generate them automatically. I would not expect much change in the names.
I don't see why returning localized names would be a new feature, since the result of atk_object_get_name () is supposed to be localized (according to the docs), i.e. a developer is supposed to call atk_object_set_name (atko, _("foo")); when using this API in applications.
Created attachment 20285 [details] [review] i18n patch for gailimage.c
Bill, The i18n patch for gailimage.c provides for retruning localized names for GTK and GNOME stock icons. Is this what you have in mind?
Hi Padraig: This does the right thing I think, regarding functionality. However it's a shame it has so many duplicate string literals... Could we try something that has a static array of literal names instead, using the N_() macro? So instead of all those nested ifs, we could for (i=0; icon_names[i]; ++i) { if (icon_names[i].quark == this_icons_quark) return gettext (icon_names[i].string); } or something like that? I think the N_() macro is used in places where you want intltool-extract to find and extract the string, but you don't actually want to use the localized value in the code at the location where the macro occurs. I could be wrong as I have limited experience with N_() to date.
Created attachment 20312 [details] [review] Updated i18n patch
I have reworked the patch to use an array for the strings. My understanding of the N_ macro is that is does nothing but is used by gettext tools which scans the code for translatable strings.
Patch looks good. My understanding of N_() is the same, that it causes the strings to be extracted by intltool-extract, but doesn't expand to a dgettext() call inline.
Padraig asked me to comment on the 'usability' of the labels... well, aural comprehensibility in this case :) Just had a couple of thoughts: + { 0, N_("dnd"), "gtk-dnd"}, + { 0, N_("dnd-multiple"), "gtk-dnd-multiple"}, Might want to make these more explicit, i.e. "drag-and-drop" and "drag-and-drop-multiple". Do we really need the hyphens in the read-aloud names? Might they adversely affect the way the text is read out? + { 0, N_("goto-bottom"), "gtk-goto-bottom"}, + { 0, N_("goto-first"), "gtk-goto-first"}, + { 0, N_("goto-last"), "gtk-goto-last"}, + { 0, N_("goto-top"), "gtk-goto-top"}, I assume any reasonable speech engine would know to pronounce "goto" as "go to" rather than "gawtoe" or anything equally silly, but you might want to call these "go-to-<whatever>" just to make sure. + { 0, N_("justify-center"), "gtk-justify-center"}, + { 0, N_("justify-fill"), "gtk-justify-fill"}, + { 0, N_("justify-left"), "gtk-lustify-left"}, + { 0, N_("justify-right"), "gtk_justify-right"}, Strictly speaking (in the typographical sense), "justify" always means "justify-fill", and the others are really "flushes" or "alignments". So if we're being pedantic, we might want to call these "justify", "align-center", "align-left" and "align-right". I guess the sloppier^H^H^Hcommon usage might have to prevail here though :) + { 0, N_("zoom-100"), "gtk-zoom-100"}, Maybe "zoom-100%", "100" on its own might be a little ambiguous (could mean either "100%" or "100x"...) + { 0, N_("mic"), "gnome-stock-mic"}, Can we be sure the speech engine would read this as "mike" rather than "mick"? Might want to call it "mike" or "microphone" to make sure.
Can we apply a (reworked) version of this patch to HEAD? Perhaps removing the hyphens from the translated strings would be a good idea. It's tough for translators to translate text that isn't proper English anyway.
have comitted a reworked patch to CVS HEAD and branching.