GNOME Bugzilla – Bug 419742
Add the ability to switch languages
Last modified: 2013-03-05 05:42:05 UTC
From the Orca mailing list: From Jan: I would like ask if developers of orca plan add to orca automatic languages switching. It will be very useful for reading multi-lingua texts etc... From Hermann and Luke: What the Orca developers should think about is to implement a switching hotkey.
(In reply to comment #0) > From the Orca mailing list: > > From Jan: > I would like ask if developers of orca plan add to orca automatic > languages switching. It will be very useful for reading multi-lingua > texts etc... > > From Hermann and Luke: > What the Orca developers should think about is to implement a switching > hotkey. I would like to suggest a hotkey that cycled through languages rather like in Supernova and other Dolphin products for Windows, one option would be ctrl+. to cycle forward and ctrl+, to cycle backward or something similar. /Krister
I mean really automatic switching languages from multilingual texts. If user will read line, paragraph or all document, then orca will automatically as for language which is in source of text as an its attribute.
Jan, that's another important feature. It's logged as bug #400717 – Orca should support multi-lingual text.
In terms of language switching via hotkey: I see value in Krister's suggestion of being able to cycle through all languages. But if you are using eSpeak you potentially will have a lot of cycling to do to get to the one you want. Also what if you are using different synthesizers, such as DECTalk for English and Cepstral for German? Perhaps we could add a way for the user to specify their three favorite voices and parameters and the hotkey cycles through those?
Those parameters *have* to be configurable so that you can change secondary and third language or such pretty easily. In Hal which i use often in Windows, there are many languages so there are many steps in the cycle, but i can see value in your point Joanie. Or maybe Orca could have some sort of logic to put the most frequently used languages first in the cycle, but i don't know if that's even possible. There should also be a "change synthesizer" dialog that you could reach via a keyboard command. (Is there room for that?) /Krister
As part of this, Orca's internals may also need some work. The problem is that any text that is generated from Orca ends up coming from the locale in which Orca was started. For example, all role names, character names, speech messages, etc., will use the default locale of the system. The problem with this is that speech can become a mixed jumble of languages. For example, assume the user started Orca in English, but then switched to a German voice. When speaking German text, Orca would speak the text in German using the German voice, but any other text coming from Orca, such as role names or character namesd, would be English words be spoken by the German voice. The desired user behavior would be to have everything spoken in German. The gettext stuff does support switching languages on the fly: http://docs.python.org/lib/node741.html. In order to better support this, however, the use of gettext in Orca has to be more dynamic. Right now, much of the acquiring of translated text happens at module initialization time. For example chnames.py and rolenames.py obtain translated text when they are imported. This would probably need to be changed so that the translated text is obtained on a per use basis, and it should depend upon the locale of the speech synthesis engine being used.
OK, so....here's a hack to change at least the chnames dictionary on the fly (the hack comprises the 4 lines beginning with "lang ="): import gettext import orca.orca_i18n import orca.chnames print orca.chnames.getCharacterName(",") lang = gettext.translation('orca', languages=['fr']) orca.orca_i18n._ = lang.gettext reload(orca.chnames) orca.orca_i18n._ = gettext.gettext print orca.chnames.getCharacterName(",")
And another hack. The main idea is to change orca.orca_i18n._ to be the gettext method of a new translation and then force a reload of the module that contains strings we want to use. import gettext import orca.orca_i18n import orca.chnames import orca.rolenames print orca.chnames.getCharacterName(",") print orca.rolenames.rolenames[orca.rolenames.ROLE_MENU_BAR].speech lang = gettext.translation('orca', languages=['fr']) orca.orca_i18n._ = lang.gettext reload(orca.chnames) reload(orca.rolenames) print orca.chnames.getCharacterName(",") print orca.rolenames.rolenames[orca.rolenames.ROLE_MENU_BAR].speech orca.orca_i18n._ = gettext.gettext reload(orca.chnames) reload(orca.rolenames) print orca.chnames.getCharacterName(",") print orca.rolenames.rolenames[orca.rolenames.ROLE_MENU_BAR].speech
Assigning to Eitan as part of the speech/braille refactor.
*** Bug 568727 has been marked as a duplicate of this bug. ***
Comment from Jacob Schmude on the Orca list: --------------- The talk about the say all voice got me thinking of another feature I would really like to see: voice profiles like in jaws 10 and later. This would be nice for reading content in other languages, you could assign a hotkey to switch profiles and could have your parameter set up for each language you use. It wouldn't just store the tts engine and voice, but the rate, pitch, and volume associated with it and probably for all three (maybe four if the say all voice is implemented) voice types if their parameters are different from the default voice. This really would make it easier to deal with reading multiple languages. --------------- Comment from Peter Korn on the Orca list: --------------- Regarding language switching, OpenOffice.org Writer has the ability to encode text in different languages. We use this in the odt2daisy plugin to create DAISY books that use the appropriate TTS engine for the different passages. I don't know whether the language information is exposed via AT-SPI yet. But this would be a nice way to have language switching automatically done for users who have to work with documents in multiple languages. HTML / Firefox should likewise support this (which is to say, you can encode it in HTML but I don't know if Firefox exposes it in any way). ---------------
Comment from Nolan Darilek on the Orca list: --------------- I'd really like a feature like this, but I might take it a step further. I notice that different speech synthesizers have their own pronunciation quirks. Sometimes, if I make a tweak in one, it introduces incompatibilities in other synths. As such, I might suggest having a global pronunciation dictionary of some sort, then one for each voice profile. This would also be compatible with the idea of using voice profiles for different languages, as phoenetics are quite language-specific. Also, I guess I'm one of those strange people who likes reading ebooks more slowly using natural-sounding voices. I find that it helps me to recall complex plot details better if I'm not reading at 400 WPM, and while I can slow Espeak or another artificial voice down substantially, I find listening to more synthetic speech at a slower rate quite grating. Also, at high speeds I can digest huge, Robert Jordan-esque novels in a bit over a day of constant reading, but I'd really rather draw things out and enjoy the experience (which I can't really say I do of RJ novels anymore, but that's neither here nor there. :) Instead of having a voice specifically for "read all," though, I'd rather just define an English voice profile with a more natural-sounding voice at a slower rate, then manually switch to that when reading books. I'd still prefer to read blogs and articles quickly, and would rather explicitly swap profiles rather than having it automatically done for me when I use read-all. ---------------
Planning spam. Sorry!
Ale, this one is something we should be able do easily as part of the saved settings work (and something I really, really would like to see done this cycle). So I'm 3.0!ing it.
(In reply to comment #14) > Ale, this one is something we should be able do easily as part of the saved > settings work (and something I really, really would like to see done this > cycle). So I'm 3.0!ing it. is this related to bug #400717 ?
(In reply to comment #15) > (In reply to comment #14) > > Ale, this one is something we should be able do easily as part of the saved > > settings work (and something I really, really would like to see done this > > cycle). So I'm 3.0!ing it. > > is this related to bug #400717 ? Conceptually, yes. Functionally, I think it's more related to the settings and profiles work because the solution for this bug will be the implementation of a profile which the user creates for a desired language. For instance, my default could be: * English (synth and locale) * Contracted/Grade 2 English (US) braille * Fast speech * Most punctuation * Etc. But I now come across an awful lot of Spanish text these days. ;-) Therefore I could create a second, 'Spanish' profile which might look something like: * Spanish (synth and locale) * Uncontracted Spanish braille * Slow speech * No punctuation * Etc. The idea on this bug being that *when I, the user, have detected a change in language* I need a way to easily to change to the settings which will best enable me to access that new language. Bug 400717, on the other hand is about handling a situation like: "Ale pointed out an article that is worth reading, 'UE: Guía práctica sobre el uso del Software Libre en el Sector Público'. The Guide is also available in English ('A Practical Guide to Using Free Software in the Public Sector') and in French ('Guide pratique d'usage des logiciels libres dans les administrations')." In other words, ideally, I should hear the English in English, the Spanish in Spanish, and the French in French. It's not worth taking the time to switch to an entirely different profile for a handful of words, however. So bug 400717 is really an entirely different beast from this bug: One that will requires .... something .... to be able to detect the language automatically and then .... something else .... to make the appropriate switches on behalf of the user. Assuming the user has enabled that option in the first place and has the appropriate synthesisers. (Make sense??)
At long (long, long, long) last: This RFE is pretty much done. Yay! The implementation is profile-based. Thus: 1. Set up a profile for each language, assigning the appropriate synthesizer along with anything else you deem relevant. 2. Bind the command to cycle amongst profiles. 3. Cycle amongst your profiles. 4. Be amazed. The last item is, of course, a joke. But this wound up being far bigger/more comprehensive than anyone (including myself) anticipated. With one keystroke, more or less all things Orca switch: * Speech language * Punctuation, key names, char names, text attribute names * Spoken messages for feedback on pretty much everything * All GUIs (Prefs, Find dialog, the new links/headings/etc dialogs, etc.) * Object states and other properties (nesting levels, for instance) The two glaring to-do items are GtkStockItem instances and accessible role names. And there are undoubtedly other little bugs here and there. But I'm declaring this RFE fixed. We can open new bugs as need be for the stuff we discover isn't quite right.