GNOME Bugzilla – Bug 575614
Please add speakable characters: → and ←
Last modified: 2009-11-09 21:35:25 UTC
Orca currently does not speak the u+2192 and u+2190 characters in the subject, however it is used several places in gnome translations, with the most appearances in gimp-tips[1]. Also, several times translators use* these either instead of -> and <- or just because it's more convenient this way to express things like menu hierarchy relations[2] or source->target relations[3]. The left pointing arrow is used too at some places, and also RTL languages could use it. *: I'd like to use these extensively, because -> is ugly and can break in two at linebreaks, which is even more uglier. But, I have a blind user at hand, who is ready to throw rotten things at me if I break something from a11y POV :) [1]: http://l10n.gnome.org/POT/gimp.gimp-2-6/gimp-tips.gimp-2-6.pot [2]: from gnome-games.HEAD.bg.po: msgid "--> Room" msgstr "→ Стая" gnome-bg/development/ekiga.HEAD.bg.po: msgid "No video will be displayed during this call->" msgstr "По време на този разговор няма да се показва видео→" [3]: from gnome-games.HEAD.hu.po: msgid "Black pawn moves from %(start)s to %(end)s" msgstr "Sötét gyalog lép: %(start)s → %(end)s"
Do you have a recommended English translation for these characters? The issue I'm wrestling with is what to do in speech. The GUI developer obviously put these characters in the UI for brevity, and we'd like to keep similar brevity in speech, yet make sure the purpose of the character is clear. The problem I'm wrestling with is that → and ← are used in many ambiguous ways. So, the best we might be able to do is say "right arrow" and "left arrow" in speech. For the gnome-games case, however, speech would end up saying the equivalent of "Black pawn moves from %(start)s right arrow %(end)s" in Hungarian because the translation chose to use "→" as the translation for "to".
Will, sorry my long answer. Left arrow and right arrow usual I think is good. But I have a question: When I make translation with gnome accessibility guide, the menues markup sintax is following for example: msgid "To setting up this function, choose <menuchoice><guimenuitem>System</guimenuitem><guimenuitem>Settings</guimenuitem><guimenuitem>Accessibility Technology</guimenuitem></menuchoice> menu item." What character was displaying yelp when displaying this text? This is equals the Gabor requested character? If yes, the resulted text is following spokening Orca: To setting up this function, choose System right arrow Settings right arrow Accessibility technology menu item. This situation left arrow and right arrow translation is not right, because this is a menu text. If this character is different with requested character, important put this character with src/orca/chnames.py file. If this question is clear, I would like doing this patch. Gabor, have another important visual character with important spokening? Attila
(In reply to comment #2) > Will, sorry my long answer. Left arrow and right arrow usual I think is good. OK. We'll go with that. > But I have a question: > When I make translation with gnome accessibility guide, the menues markup > sintax is following for example: > msgid "To setting up this function, choose > <menuchoice><guimenuitem>System</guimenuitem><guimenuitem>Settings</guimenuitem><guimenuitem>Accessibility > Technology</guimenuitem></menuchoice> menu item." > What character was displaying yelp when displaying this text? The character is the '▸' character, which is a whole different character. I believe it is U+25B8, which is the "BLACK RIGHT-POINTING SMALL TRIANGLE" > This situation left arrow and right arrow translation is not right, because > this is a menu text. This is the point I make in comment #1. The character used is the character used. I'm not sure we want to make Orca be responsible for getting into the mind of the person who chose to use that character. For example, I don't think we can reliably make the decision that a person used '→' to mean "moves to" versus something else. Or that '▸' means "go to submenu" versus "play". I believe the most reliable thing we can do is provide some semblance of the string the Unicode designers chose for the character. So: ▸ 25B8 BLACK RIGHT-POINTING SMALL TRIANGLE → 2192 RIGHTWARDS ARROW ← 2190 LEFTWARDS ARROW Keep in mind there are many many many (did I say many?) unicode characters. We're not going to cover them all. Bug #431531 has been opened to handle the characters we don't cover.
Created attachment 134341 [details] [review] Patch to add pronunciations This patch adds the pronunciations in question. While testing it, I noticed some issues with how character pronunciations were not being used when navigating by line. Those have been opened as bug #582028.
I think left/right arrow is a good choice, at least usually it will be close to the intended meanings. But, for "black right pointing small triangle": Choose the System "black right pointing small triangle" Settings "black right pointing small triangle" anything menu item. Is this not too lenghty? I understand that it should mostly resemble to the original description, but one can forget what was the beginning of the sentence after hearing this 5 word description twice :). Would "right pointing triangle" too terse? How many similar triangles are there in Unicode?
Yes, black right pointing small triangle is too lenghty my openion. My ydea: Choose the System "menu" Settings "menu" anything menu item. Because no difference the main "system" menu markup and "settings" submenu markup character, I use the menu simbol with english translation. The perfect description is following, but impossible doing if I known right: Choose the System "menu" Settings "submenu" anything menu item.
(In reply to comment #5) > Would "right pointing triangle" too terse? How many similar triangles are there > in Unicode? There seem to be quite a few: http://www.alanwood.net/unicode/geometric_shapes.html There's white ones, black ones, big ones, small ones, etc. I don't think Orca should be the judge of what should or should not be spoken. Small vs. regular amd white vs. black might make a tangible difference in meaning on some pages, for example.
(In reply to comment #6) > Yes, black right pointing small triangle is too lenghty my openion. > My ydea: > Choose the System "menu" Settings "menu" anything menu item. > Because no difference the main "system" menu markup and "settings" submenu > markup character, I use the menu simbol with english translation. > The perfect description is following, but impossible doing if I known right: > Choose the System "menu" Settings "submenu" anything menu item. I agree it is verbose. HOWEVER, Orca does not know that the meaning of the triangle in this context is "menu" by looking at the text. All it knows is that there is a character there and the character is a small black right pointing triangle. Having said that, the HTML markup ends up looking like this, where the whole thing is surrounded by <span class="menuchoice">......</span>: To enable GNOME accessibility features from a GUI, run the <span class="menuchoice"> <span class="guimenuitem">System</span> ▸ <span class="guimenuitem">Preferences</span> ▸ <span class="guimenuitem">Assistive Technology</span> </span> Potentially, one could attempt to create a custom script that attempts to interpret the CSS to guess what word(s) should be used to speak a given symbol, assuming "menuchoice" is a well known tag. I believe what they will quickly find is that this information is not exposed to Orca via the AT-SPI (I could not find it anyway). As such, we're back to Orca just knowing that a small black right pointing triangle is present. So, providing the semantic interpretation of symbols based upon their context is something that is outside the scope of this bug, and is also something where I don't believe Orca is given enough information to make a decision. So, to bring us back to this bug: this bug is about providing spoken text for the left and right arrow characters. The patch provides that and also adds text for the small right pointing black triangle. In the spirit of trying to keep bugs to a specific thing, I can happily strip out the black triangle text and we can open a separate, likely-never-to-be-addressed, enhancement request that Orca provides a semantic interpreter for characters based upon the perceived context.
Well, then the easiest way to go is to ask gnome-doc-utils developers to ditch this annoying triangle in favor of the right arrow :).
Bug #582098 filed.
(In reply to comment #10) > Bug #582098 filed. Ha! :-)
Created attachment 134472 [details] [review] This is the second revision. Modifyed first patch. Only change the U+25B8 character description and add the requested characters with src/orca/punctuation_settings.py file. I tested this patch when readed gnome-access-guide with Yelp, U+25B8 character perfect spokened and not disturb the whole sentence understand. If not big problem my patch, possible commit with master age?
(In reply to comment #12) > Created an attachment (id=134472) [edit] > This is the second revision. > > Modifyed first patch. Only change the U+25B8 character description and add the > requested characters with src/orca/punctuation_settings.py file. > I tested this patch when readed gnome-access-guide with Yelp, U+25B8 character > perfect spokened and not disturb the whole sentence understand. > If not big problem my patch, possible commit with master age? Having the text insertion happen via punctuation_settings.py is a good idea. Thanks! We can go with that. I cannot accept the 'menu' change, however, due to what I've said in comment #8. :-( For example: ▸ It might be used as a bullet. We don't want this spoken as "menu It might be used as a bullet" It might be used as an indication to play something: Press ▸ to play. We don't want this spoken as "Press menu to play." It might be used as an indication to nudge something: Press ▸ to nudge this to the right. We don't want this spoken as "Press menu to nudge this to the right." It might be used to show relations between things: claw▸cat▸mammal▸animal. We don't want this spoken as "claw menu cat menu mammal menu animal". It might be used to to indicate a tree node: ▸ some tree node item ▾ an open node ▸ a sub node ▸ another sub node ▸ another tree node Speaking these as "menu" also does not apply.
Orca punctuation possible to replace this context with Yelp application setting? Now the punctuation is not do replace more words. Attila
(In reply to comment #14) > Orca punctuation possible to replace this context with Yelp application > setting? > Now the punctuation is not do replace more words. Hi Attila - can you please open a new bug for this? By introducing separate problems in the same bug report, you risk the chance that the original problem never gets addressed until all the other separate problems are addressed. This bug is about adding spoken words for the left and right arrow keys. You're introducing a new bug/rfe, which seems to be that the chnames and pronunciation dictionaries should be customizable per script. Thanks!
Ok, sorry agree your comment. I do a final patch with contains only the left arrow and right arrow character. I try put the U+208 character with application settings dictionary. If this is wor, not need open another bugreport with this topic. Attila
Created attachment 134545 [details] [review] Final patch. This is the final revision. Contains the U+2190 and U+2192 character and add this characters with src/orca/punctuation_settings.py file. Attila
Thanks Attila! I committed a slightly modified version of the patch since some of the work had already been committed and I also wanted to better follow the coding style that existed in the source files. Please give the master branch a check to see if it works for you.
I think this bug was fixed, thanks Will.