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

Comments

Projects
None yet
4 participants
@nvaccessAuto
Copy link

nvaccessAuto commented Jan 1, 2010

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

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Jan 1, 2010

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

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Feb 6, 2015

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

@nvaccessAuto

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Feb 6, 2015

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

This comment has been minimized.

Copy link
Author

nvaccessAuto commented Feb 9, 2015

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

This comment has been minimized.

Copy link
Collaborator

leonardder commented Jul 18, 2017

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Collaborator

Adriani90 commented Jul 12, 2018

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

This comment has been minimized.

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.

@jcsteh jcsteh closed this Jul 13, 2018

@jcsteh jcsteh added the wontfix label Jul 13, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.