Can't save entry with "#" as pattern in speech dictionaries

[nvaccessAuto]

Reported by briang1 on 2010-10-03 13:25
The changes added in snap 8372 make the dictionary entries a whole lot more powerful, but they do have some peculiarities which, in my view need addressing.
Firstly, some characters seem to work as detailed, ie...

can be replaced by the word hash, but this only works in the current session, rather as if it were in the temp dictionary. I tested it in both voice and default and it was deleted after a reboot of nvda, although a similar rule changing ^ to say up arrow was still there.

This makes no sense to me at all.
Secondly, if you decide to change a punctuation mark such as apostrophe ' to say the word. It will still say the word even in doc read via say all and keypad plus. This contradicts the punctuation setting of speak no punctuation, set for this mode. ! if changed to the word exclamation, does the same.
As you know in the uk, # sometimes says number sometimes hash, likewise, ! can say bang or exclamation and I was hoping this would fix this!

This is probably not a good outcome.
I have not exhaustively tested every possible character and group to see if there are other problems, but I believe there is a previous ticket saying this change also affects specially configured voices as well, as used in non English speaking systems. ticket 956.

It may of course be that Espeak which was being used here has something to do with some of it.

Blocking #444

[nvaccessAuto]

Comment 1 by pvagner on 2010-10-03 15:09
The issue which has something to do with ability to replace # with hash or number is because # character is used for adding comments into the speech dictionaries.
I don't know how we might be able to sort this out without breaking compatibility with dictionaries all the people may have created over time.
Changes:
Milestone changed from None to None

[nvaccessAuto]

Comment 2 by briang1 on 2010-10-03 17:03
Well interestingly, if you load the dictionary into notepad and change the # to## the only problem is that all comments are preceded by #. There might be some issue with the ##00 at the end, I don't knowhat this is for. However it seems to me that it would be relatively easy to detect a dic file with only one # and convert it to two, so the routine could look for 2# signs rather than just one. Just a thought.

[nvaccessAuto]

Comment 3 by jteh (in reply to comment description) on 2010-10-06 07:09
Replying to briang1:

The changes added in snap 8372 make the dictionary entries a whole lot more powerful, but they do have some peculiarities which, in my view need addressing.

These issues were present before that change as well. Also, they are two separate issues.

Firstly, some characters seem to work as detailed, ie...

can be replaced by the word hash, but this only works in the current session, rather as if it were in the temp dictionary.

This makes no sense to me at all.

This is a bug. :)

Secondly, if you decide to change a punctuation mark such as apostrophe ' to say the word. It will still say the word even in doc read via say all and keypad plus. This contradicts the punctuation setting of speak no punctuation, set for this mode.

Speech dictionaries have no concept of whether a character is punctuation or not. Redefining punctuation like this should be covered by #332.

Morphing this ticket to cover the "#" bug.
Changes:
Changed title from "Quirks in user dictionaries since snap 72" to "Can't save entry with "#" as pattern in speech dictionaries"

[nvaccessAuto]

Comment 4 by briang1 on 2010-10-06 09:56
Yes, thought this was a good idea now the changes to the dictionary have been regressed. I have already added my comments to the other older ticket a few days ago. Suffice to say that it will confuse if punctuation is able to be changed if turned off.

[nvaccessAuto]

Comment 5 by mdcurran on 2012-10-05 00:01
Fixed in f601639. Now all # characters within dictionary entry fields are encoded as # in the .dic files.

[nvaccessAuto]

Comment 6 by mdcurran on 2012-10-05 00:02
Changes:
Milestone changed from None to 2012.3
State: closed