Please fill out the pull request template

Instead of "dot" please use "braille". This is similar to what other synthesizers or screen readers provide.

Instead of "dot" please use "braille". This is similar to what other synthesizers or screen readers provide.

Personally I've only ever read it as "dot", and it should be fast. "Braille dot 1" I suppose I've heard, but that's even clumsier.

This could be made a configuration option perhaps, but I don't know how to hook that.

I would guess that sequences might be simplifiable (e.g. "braille dots 6, 125, 24, 256" by using the regex based version and something to trigger the right pause length, but again, don't know how that part works and didn't try to make it perfect.

Right now it's an improvement from ignoring it altogether. Feel free to improve it in future revisions.

Please fill out the pull request template

I believe I addressed all of it I could in my description. It's not code, so there's not really anything to test, add-on issues, etc AFAICT. Kinda simple, really.

With no context, a screen reader user reading the symbol as "dot 3" will have no idea that the symbol refers to braille. In a given sentence "dot 1 3 5" is not as obvious as "Braille 1 3 5". "1 3 5 Braille dot" might be better so users can skip the end when reading many of these in a row.

I don't think there is a way to hook into symbol pronunciation like that without doing work similar to what was dropped in #12710

Filling out the template allows your work to be understood clearly by other contributors.
Without filling out the template fully this PR will not be accepted, and NV Access or other contributors will have to schedule picking it up.

With no context, a screen reader user reading the symbol as "dot 3" will have no idea that the symbol refers to braille. In a given sentence "dot 1 3 5" is not as obvious as "Braille 1 3 5". "1 3 5 Braille dot" might be better so users can skip the end when reading many of these in a row.

I've added a complex sequence regex to capture the beginning and end of a braille sequence and say this.

I think it's better to not have each cell have a long reading, because that requires manual character by navigation to skip the extra language. This way, it can read them quickly as a paragraph.

I don't think there is a way to hook into symbol pronunciation like that without doing work similar to what was dropped in #12710

🤷 I've no idea either way.

Filling out the template allows your work to be understood clearly by other contributors. Without filling out the template fully this PR will not be accepted, and NV Access or other contributors will have to schedule picking it up.

What other info can I supply that's in the form, not already given, and relevant here?

• AFAICT there's no applicable testing; https://github.com/nvaccess/nvda/blob/master/tests/system/robot/symbolPronunciationTests.py seems the closest and doesn't seem to be used for specific mappings like this.
• No API effect or documentation need AFAICT.
• I discussed UX above.
• It's in the English locale file, so obviously other languages will need to override to get localised versions; though I do speak several others, but I don't know how blind people natively pronounce braille cells in other languages.
• Change log seems something for devs to edit, not me.

So… what have I omitted?

@saizai the template fields are almost empty and you have put your description at the beginning.
As indicated in the PR's initial description edit box when you first open it, you can look at Creating PR's on the NVDA project documentation to know how to fill each paragraph.

First of all you should probably split the content of your initial description in the applicable paragraphs, mainly "Summary of the issue" and "Description of how this pull request fixes the issue".

If a paragraph should not contain any information, please add "N/A" so that it is more explicit.

Regarding testing, you should describe how you have tested your changes. Probably, you have done manual testing, i.e. you have read a series of braille unicode character and have checked that they are now reported vocally.

Regarding the change log, it's your role to provide a short description of your work which will appear in the change log page. When this PR is merged, NVAccess people will then copy what you have written in the change log file.

At least regarding the "Code Review Checklist", as indicated in the documentation, you should check the checkbox to indicate that you have considered these tasks. For example if you check the "Documentation" item that means that you have thought to the documentation, either because you have actually updated some documentation or because you have confirmed by checking this checkbox that no upgrade of the documentation is needed in this PR.

But again, all is in the documentationdocumentation to know how to fill each paragraph.

You can also look at the initial description of already-merged PRs to see other examples of PR initial description.

HTH

@saizai, do you plan to move forward with this PR? It's something that would be extremely useful to say the least, and not filling out a template seems like a pretty silly reason to block it from being merged, on both sides. It seems NVAccess has been given enough info to merge this, but I also don't see why you won't just do it.

For the actual speaking, I like how VoiceOver on iOS does it . Braille dots 1 3 5, braille dots 1 3, braille dot 1, braille dots 1 3 4 5 6.

@TheQuinbox - as mentioned by Cyrille, information on testing is missing. As the PR stands right now, it is unclear what the new UX is, e.g. there is no example of speech.

As I mentioned earlier, without @saizai doing the work, someone else must do it instead. With ~50 open PRs, I have added this to the schedule to be picked up later. In the mean time, anyone willing to do the tiny amount of work remaining is welcome to do so.

It would be ideal that these symbols were displayed on braille devices as readable braille as well

It would be ideal that these symbols were displayed on braille devices as readable braille as well

@seanbudd In most (all I'm regularly using) LibLouis tables their are. Have you tested this and found a case in which they aren't?

Closing in favour of #14548

The strategy in this PR has been abandoned as:

• sequences starting and ending are needlessly verbose
• sequences starting and ending were not being detected correctly when manually testing the following cases

# Read one symbol as: 1 dot
⠁
# Read two adjacent symbols as: start Unicode braille 1 dot 2 dot end Unicode braille
⠁⠂
# Read two symbols with spacing as: start Unicode braille 1 dot 2 dot end Unicode braille
⠁ ⠂
# Read a sentence with a mix of braille and text as: start Unicode braille 1 dot 2 dot foo 1 dot bar 1 dot 2 dot end Unicode braille
⠁⠂foo ⠁bar ⠁⠂
# Read a sentence with a mix of braille and text as: foo start Unicode braille 1 dot 2 dot bar 1 dot end Unicode braille lorem
foo ⠁ ⠂bar ⠂ lorem