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 419742 - Add the ability to switch languages
Add the ability to switch languages
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
2.18.x
Other All
: High enhancement
: ---
Assigned To: Joanmarie Diggs (IRC: joanie)
Orca Maintainers
: 568727 (view as bug list)
Depends on: 626072
Blocks: Andalucia
 
 
Reported: 2007-03-18 15:15 UTC by Rich Burridge
Modified: 2013-03-05 05:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Rich Burridge 2007-03-18 15:15:03 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.
Comment 1 krister 2007-03-18 15:31:14 UTC
(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
Comment 2 Jan Buchal 2007-03-18 16:47:33 UTC
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.
Comment 3 Joanmarie Diggs (IRC: joanie) 2007-03-18 19:07:39 UTC
Jan, that's another important feature.  It's logged as bug #400717 – Orca should support multi-lingual text.
Comment 4 Joanmarie Diggs (IRC: joanie) 2007-03-18 19:16:10 UTC
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?
Comment 5 krister 2007-03-18 22:00:17 UTC
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
Comment 6 Willie Walker 2007-05-17 13:37:01 UTC
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.
Comment 7 Willie Walker 2007-05-17 21:28:56 UTC
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(",")
Comment 8 Willie Walker 2007-05-17 21:33:23 UTC
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
Comment 9 Willie Walker 2007-09-04 15:13:54 UTC
Assigning to Eitan as part of the speech/braille refactor.
Comment 10 Willie Walker 2009-02-08 16:14:22 UTC
*** Bug 568727 has been marked as a duplicate of this bug. ***
Comment 11 Joanmarie Diggs (IRC: joanie) 2010-04-30 19:21:25 UTC
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 12 Joanmarie Diggs (IRC: joanie) 2010-04-30 22:43:28 UTC
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.
---------------
Comment 13 Joanmarie Diggs (IRC: joanie) 2010-07-05 01:57:59 UTC
Planning spam. Sorry!
Comment 14 Joanmarie Diggs (IRC: joanie) 2010-07-05 21:02:42 UTC
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.
Comment 15 Alejandro Leiva 2010-08-04 09:26:58 UTC
(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 ?
Comment 16 Joanmarie Diggs (IRC: joanie) 2010-08-04 12:48:16 UTC
(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??)
Comment 17 Joanmarie Diggs (IRC: joanie) 2013-03-05 05:42:05 UTC
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.