Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A new, extensible speech dictionary type for nvda #219

Closed
nvaccessAuto opened this issue Jan 1, 2010 · 19 comments
Closed

A new, extensible speech dictionary type for nvda #219

nvaccessAuto opened this issue Jan 1, 2010 · 19 comments

Comments

@nvaccessAuto
Copy link

Reported by aleksey_s on 2008-11-02 14:00
sometimes one dictionary must be applied to more than one voices or even synthesizers. it is possible when user wants to handle voices of one manufacturer or one language.
So nvda must have functionality to make such dictionaries.
i offer to implement a new type of speech dicts: smart dictionary. this one besides list of entries will have regular expression pattern, which must match with current voice and synthesizer for this dictionary to be active. for users, who are unfamiiliar with regular expressions, nvda will offer dialog with all voices of all available synthesizers, where user can check items and regular expression will be constructed.
i have allready implemented smart dictionaries, for now i am working on gui for manipulate its.

here is a log of my local bzr branch:
2263 Алексей Садовой 2008-10-31
*core.py: fixed some inconsistend logging.

2264 Алексей Садовой 2008-11-01
* speech dicts: implemented a new type of dictionary, smart dictionary. this one can be applied to all synthesizers and voices, if some regexpr matches synthesizer-voice string. we can have many such dictionaries at a time loaded and processed.
* some fixes to existing speech dictionaries implementation

2265 Алексей Садовой 2008-11-02
speechDictHandler.py:
* now dictionary files can have native characters in names.
* Smart dictionaries now have name. file name will be constructed on this name.

  keyboardHandler.py:
   * fixed one typo

Blocking #212

@nvaccessAuto
Copy link
Author

Attachment diff.2.txt added by aleksey_s on 2008-11-09 13:33
Description:

@nvaccessAuto
Copy link
Author

Attachment diff.txt added by aleksey_s on 2008-11-22 22:13
Description:
bzr merge-directive

@nvaccessAuto
Copy link
Author

Comment by aleksey_s on 2008-11-02 14:11
(In #212) functionality, requested in this ticket is implemented in #219

@nvaccessAuto
Copy link
Author

Comment 2 by aleksey_s on 2008-11-09 00:56
initial GUI support added. now only dialog with multiselect list of all voices and synthesizers is required. diff.txt - bzr merge directive.

@nvaccessAuto
Copy link
Author

Comment 3 by aleksey_s on 2008-11-09 13:34
maked changes to reflect last revision

@nvaccessAuto
Copy link
Author

Comment 4 by aleksey_s on 2008-11-22 22:18
updated feature to match main branch. Core developers, are you going to review it?..

@nvaccessAuto
Copy link
Author

Comment 5 by ragb on 2008-11-27 16:27
Another related idea is to have application specific dictionaries. This was discuced in NVDA's portuguese list, it seems some users use it extensively in JAWS and request this feature in NVDA.
Should I fill another ticket for this suggestion?

@nvaccessAuto
Copy link
Author

Comment 6 by aleksey_s on 2008-11-28 22:49
for further progress, see bzr branch at http://bzr.nvaccess.org/nvda/smartDictionaries

@nvaccessAuto
Copy link
Author

Comment 7 by jteh on 2009-05-01 01:29
Changes:
Milestone changed from 0.6 to None

@nvaccessAuto
Copy link
Author

Comment 8 by Bernd on 2009-07-04 14:09
Hi, is someone still working on this enhancement?

@nvaccessAuto
Copy link
Author

Comment 9 by aleksey_s (in reply to comment 8) on 2009-07-04 15:06
Replying to Bernd:

Hi, is someone still working on this enhancement?

It is already done and waits the core developers decision about six months.

@nvaccessAuto
Copy link
Author

Comment 10 by Bernd on 2009-10-21 17:13
Hello core developers,

as I just saw, this ticket could be closed since more than a few months. Would it be possible to merge this ticket if 2009.1 is released?

@nvaccessAuto
Copy link
Author

Comment 11 by leonarddr on 2015-02-06 16:10
Changes:
State: closed

@nvaccessAuto
Copy link
Author

Comment 12 by bdorer (in reply to comment 11) on 2015-02-06 17:22
Replying to leonarddr:
please don't close tickets as fixed if they aren't.
Changes:
State: reopened

@nvaccessAuto
Copy link
Author

Comment 13 by leonarddr (in reply to comment 10) on 2015-02-09 13:53
I'm sorry, I misinterpreted comment 10 as a request for closure.
What is the current status of this? Is current patch even suitable for inclusion in the code, I wonder?

@leonardder
Copy link
Collaborator

CC @bdorer

Anyone knows whether aleksey is available on github? I'd be happy to mention him if I know his github ident.

@jcsteh: May be you could reprovide the attachments?

@jcsteh
Copy link
Contributor

jcsteh commented Jul 19, 2017

No need; the code is available in the smartDictionaries branch in the official repo.

  1. I've always been very dubious about this. It seems overly complex to me and I'm not clear on real world use cases.
  2. We don't "support" manual editing of files these days, so a regular expression isn't a good fit.
  3. Even if users used multiple synthesisers for a single language, would they go through the effort of configuring something like this?
  4. I think profile specific dictionaries are probably more versatile.

@Adriani90
Copy link
Collaborator

I agree, we should continue with profile based dictionaries. Synth based dictionaries are hard to handle because it often depends on the voice you are using. This is fair too much work to maintain such things, especially for synths which are updated on a regular basis like Cereprog or eSpeak.

@jcsteh
Copy link
Contributor

jcsteh commented Jul 13, 2018

Closing as per #219 (comment), and also because no one is interested in actively working on this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants