Comment 1 by MHameed on 2012-10-21 14:34
Changes:
Milestone changed from 2012.3 to 2013.1

Comment 2 by jteh on 2012-10-21 21:41
Marking as needsExternalFix, since most of the work is in liblouis.

Comment 3 by mdcurran on 2013-01-30 04:10
Moving out of 2013.1 as I'm assuming no progress on this yet, and we are getting ready for a beta.
Changes:
Milestone changed from 2013.1 to 2013.2

Comment 4 by nishimotz on 2013-02-01 07:07
I agree with this decision.

NVDA Japanese Team is developing a forked version called NVDAJP, which contains experimental Japanese braille support.
We are intensively working to improve the quality of Japanese braille translation toward the 2013.1jp, which is the Japanese version of 2013.1.

This work includes the development of test harness of Japanese braille, which is publicly hosted at launchpad repository, based on the rules made by the Braille Authority of Japan (BAJ).
BAJ rules consist of the rule for braille translation for books of general interests, and the rule for books for information processing.
Neither NABCC nor UEB is accepted by Japanese braille users at all.
The BAJ rule for information processing books is so outdated that it does not cover Japanese full-shape characters.
Because of the incompleteness and the complexity of BAJ rules as the screen reading application, commercial screen readers in Japan are making their translation rules, which are useful but not fully compliant with BAJ.
We must make many decisions regarding punctuations, half-shape and full-shape symbols.

In parallel, prototype version of translator, written in Python, is under development.
It uses Japanese Text-to-Speech dictionary for the transliteration from Japanese ideographic characters to phonetic characters.
Brltty Japanese table, mentioned above, does not cover Japanese ideographic characters at all.

Our next step will be the combination of Japanese language-depended part (which handles semantic contexts based on the Japanese transliteration dictionary) and language-independent part (which is table-oriented process that liblouis can handle).
I am not sure all the necessary process can be written as liblouis table without using C-based enhancements.

The goal is to contribute the Japanese braille translator as an enhancement of liblouis, which will be also used in mainstream version of NVDA.
However, the work takes much more time.

Comment 5 by nvdakor on 2013-02-01 08:01
Hi,
I was wondering about Japanese braille.
As for symbols and punctuation, similar problems exists with Korean table in BRLTTY. Although it worked great for displaying uncontracted braille, it causes problems with contracted braille - it appears that the work over there was based on a Wikipedia article. Thus, I came up with "proper" dictionary-based contracted braille table for LibLouis, as contracted braille in Korean is done by omitting certain dot combos.
As for assistance from LibLouis devs, if you haven't I recommend subscribing to LibLouis mailing list on Freelists - some translators are members of that list as well, and so are NVDA devs.

Comment 6 by jteh on 2013-06-26 02:59
Changes:
Milestone changed from 2013.2 to None

@nishimotz Could you please share any updates about work done on Japanese Braille support in relation to your #2736 (comment)?

Japanese Braille support of NVDAJP is implemented as follows:
https://github.com/nvdajp/nvdajpmiscdep
The braille.py of NVDAJP bypasses liblouis and synthDrivers.jtalk.translator2 is used instead.
(Our Japanese TTS and Japanese Braille translator use the same morphological analysis system)

We restarted to work with liblouis recently.
So far, our target is limited to reverse translation of Japanese phonetic symbols,
which can be used for Braille input.

@nishimotz Is there currently a way to integrate this work into the regular version of NVDA? What I mean is, can I add/replace in a regular NVDA install to make the Japanese braille support active?
I am studying this language in my spare time and I currently get by with having an NVDAJP copy running next to my regular NVDA, so I swap between them if I want to see the Japanese characters show up.
However, if there is a non-destructive way of integrating these changes into main , that would save a bit of time and hassle :)

@nishimotz: is there a related liblouis issue?

No liblouis issue so far.
I have discussed on Japanese support at the liblouis list in 2012.
At that time, "otherTrans" mode was the possible solution.
However, liblouis recently deprecated otherTrans mode.

Closed by #13141

Hmmm ... @nishimotz if I'm not mistaken this Liblouis update adds kantenji, not the braille table NVDAJP uses. Given the low usage of kantenji, should we really consider this issue closed?

There really needs to be an issue opened against liblouis for this.

Found it: blocked by liblouis/liblouis#1153

Currently NVDA support only the 8 dot kantenji braille, but not the also very commong 6 dot tenkanji braille. So the referenced issue might get reopened in the Liblouis repository.