multiple languages on the braille display

[nvaccessAuto]

Reported by fatma.mehanna on 2012-01-17 11:34 hi list, nvda doesn't allow multiple languages to be displayed on braille display.if i set my braille display table to arabic for example, and during reading an arabic text i found suddenly a hebrew word for example, nvda doesn't display it correctly.

if i set my braille table to arabic for example,

[nvaccessAuto]

Comment 1 by jteh on 2012-01-17 20:59 It's worth noting that this would only be able to work if the document indicates the language of each piece of text, just like NVDA's auto language switching for speech.

[nvaccessAuto]

Comment 2 by geoff on 2012-01-18 17:05 Actually, the right way to do this in my limited experience is to have a unicode Braille table. As far as I know, this would require no native language support in NVDA whatsoever. As long as it passes unicode through to the Braille engine unmodified, you should be able to read it just fine. My wife uses a unicode table with VoiceOver (this is not shipped with it), and is able to read Hebrew quite happily despite VoiceOver having no Hebrew support.

I don't know if LibLouis has a unicode table, but maybe it's worth trying it if it does.

[nvaccessAuto]

Comment 3 by jteh on 2012-01-18 22:52 I don't follow how that would work. Every language has its own braille code and there is obviously going to be duplication of dot patterns. Some braille codes will use different dot patterns for the same symbols; e.g. punctuation. Finally, I imagine this would only work for computer braille and doesn't handle grade 1/grade 2 at all.

[nvaccessAuto]

Comment 4 by geoff (in reply to comment 3) on 2012-04-13 20:51 Replying to jteh:

I don't follow how that would work. Every language has its own braille

code and there is obviously going to be duplication of dot patterns.

Naturally. But at least you would see something instead of, presumably, nothing. I'm not aware of any way of indicating a language change in Braille. Certainly this is the kind of case where Unicode works well.
If the reader knows both languages, they may be able to figure out the word in the second language when they see it doesn't make sense in the first. If they don't, well they're no worse off than they are now.

Some braille codes will use different dot patterns for the same

symbols; e.g. punctuation.

True. This would be harder to deal with.

Finally, I imagine this would only work for

computer braille and doesn't handle grade 1/grade 2 at all.

I'm not sure how many languages other than English have a "Grade 2".

All of the above is really only relevant to languages which have their own characters, as per the original description. Switching between two latin-based languages properly would require knowing the actual languages, however I dare say that a latin-based language written in the wrong Braille code would presumably still make some kind of sense at least, instead of producing nothing.

[dkager]

I would say this needs to be addressed in liblouis. Switching braille tables isn't a good idea because it assumes that people learn to read a language's native braille code. I don't think this is true for most people. For example, I don't read UEB but definitely want to read English texts. Even if you want to read a language's alphanumeric characters in the native braille code, such as the ä and ö in Finnish, you probably don't know all the punctuation signs of that code.

So in short, I think the braille table should provide the dot patterns for these characters. For example, JAWS has dot patterns for Greek and many other Unicode ranges in its computer braille table.

[jcsteh]

I think there's some merit in supporting this but making it configurable. There's an analogy in speech: some people might choose to read English with a synthesiser that primarily speaks another language because the accent might be more understandable to them (assuming the synth handles this well enough). So, I don't think this should be a won't fix, but it's definitely a low priority feature.

[dkager]

One more thing to keep in mind is that a word in another language that occurs in the middle of a sentence will probably break capital sign rules from the braille table. Liblouis has to switch to a different table, which results in a different set of capital sign rules. So this idea is most interesting for people who are proficient in two or more codes.

[PratikP1]

One significant reason to add this type of functionality is for people needing to access textbooks when learning languages. These often commingl two languages. It requires that the book is properly marked up. I'll ask someone at the DAISY Consortium or Epub forum to get a sample document for a test case.

[Adriani90]

@andre9642 has written code for this. In my view, people who read multilingual texts know already the native braille of the languages they want to read in. So it should be an optional setting. I also have creadet an idea on Liblouis project for an universal 8 dot computer braille for every language which would require users to learn reading like that. But I think Andre's solution is also very good.

@andre9642 do you plan to raise a pull request for NVDA?

@leonardder your thoughts are appreciated here.

[aaclause]

Hi @Adriani90, My code for this is very basic. I have another code (currently not included in my add-on) which allows multiple outputs braille through auto-detection of the language (provided that the document is well tagged) but this code is horrible and not optimized... In short, if it's for an integration in NVDA Core, I prefer to let other people more competent to do it. Honestly, I still have a lot of work to make good code for something serious.

Regarding an universal 8 dot computer braille, I think that will be great but... a bit utopian. With 256 combinations, whether on one, two or three cells, we can never represent all signs...

[zstanecic]

Regarding an universal 8 dot computer braille, I think that will be great but... a bit utopian. With 256 combinations, whether on one, two or three cells, we can never represent all signs... i agree with the above sentence from andre, as liblouis has only basic imput/output mapping

[Adriani90]

cc: @dineshkaushal

[yeatersink]

@LeonarddeR is there anyway that we can work on trying to enable various Braille tables or multiple rail tables in NVDA at the same time so that we can get multiple language support in the same document?

[LeonarddeR]

In my opinion, a user experience like this would be changing the list of braille tables into a checkable list. That allows you to enable/disable tables, but it will also require the ability to move tables up and down, because ordering of the tables matters. This is also why I believe with @dkager that the primary responsibility for such functionality should be on liblouis' side.

One major problem with how many tables are currently designed, is that they usually include characters that are strictly spoken unrelated to the main language of the table. For example, speaking about your (@yeatersink) hebrew table, that also includes the latin alphabet and some punctuation. Imagine what would happen if one enables both Hebrew and UEB. The order of these tables will matter, I assume the first table should be UEB. But it is hard to say what some of the more complex UEB rules will do with the output of Hebrew. So long story short, liblouis is currently not accustomed for this.