Internationalizing Screen readers.

[Devin Prater]

Emacspeak controls the synth a lot more aggressively, which in this case 
is a very good thing. There was some talk a while back about having 
speech dispatcher handle unicode stuff, but so far only Emacspeak has 
pushed ahead in this regard, tapping into Emac's list of Unicode 
characters and their meaning. Since that's open source, I see no reason 
why all that info couldn't be pulled from Emacs and put into eSpeak or 
Speech Dispatcher, depending on if people think the synth should do all 
the work, leaving out all others in the process, or if the speech server 
should do the work, which would include all synths it supports and would 
reduce the work load to one system, instead of lots of smaller ones. 
That's just my idea though. I support all operating systems, and the 
people that make them better for all people.


On 11/3/2016 10:49 PM, Jackie McBride wrote:
> Jeffery, you don't tell us what synthesizer you're using w/Orca, but
> the truth is it's the tts engine that really handles the language
> aspects, as opposed to the screenreader itself. ESpeak, Flite, etc,
> all have I18N capabilities, I believe, & these are all being used
> w/Orca. I'm not familiar w/sbl, but here again, if it will work w/a
> different synthesizer than what you're currently using, give that a
> try & see if things are better.
>
> On 11/3/16, Devin Prater <r.d.t.prater at gmail.com> wrote:
>> Emacs, with Emacspeak, can handle most, if not all, Unicode characters,
>> even emoji!
>>
>>
>> On 11/3/2016 9:24 PM, Jeffery Mewtamer wrote:
>>> English is the only language I'm fluent in, and among the languages I
>>> know more than a few words of, many of those words have been imported
>>> into English anyways, but I still come across enough non-Latin text
>>> for short comings in internationalization to be annoying.
>>>
>>> In graphical mode on my desktop, I use Orca(do there even exist
>>> graphical screen readers for Linux other than Orca), and it handles
>>> non-English Latin text well enough, but for some non-Latin character
>>> sets(such as Greek, Hebrew, and Arabic), it can only read
>>> character-by-character instead of string characters into words, and
>>> for others(such as Chinese and Japanese), it can only identify the
>>> character set and then repeat the word "letter" for each character in
>>> the string, and then there are some characters Orca can't identify at
>>> all and just reads the Unicode code point in Hexadecimal.
>>>
>>> This can be particularly annoying when reading wiki pages that are
>>> heavy on foreign terms that are displayed both in their source
>>> language and Romanized.
>>>
>>> My text-mode screen reader, SBL, has even bigger issues, reading
>>> pretty much all non-ASCII characters as "thorn", and can't even handle
>>> things such as accented Latin characters or the curly versions of the
>>> single and double quotes.
>>>
>>> If anyone knows anything I could try to improve these, it would be
>>> greatly appreciated.
>>>
>>> If it matters, I'm running a system customized from Knoppix 7.7.1,
>>> which is based on Debian.
>>>
>>> _______________________________________________
>>> Blinux-list mailing list
>>> Blinux-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/blinux-list
>> _______________________________________________
>> Blinux-list mailing list
>> Blinux-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/blinux-list
>>
>