Feat/stt control #78
Feat/stt control #78
Conversation
Codecov Report
@@ Coverage Diff @@
## dev #78 +/- ##
==========================================
+ Coverage 49.08% 50.67% +1.58%
==========================================
Files 115 117 +2
Lines 9720 10049 +329
==========================================
+ Hits 4771 5092 +321
- Misses 4949 4957 +8
Continue to review full report at Codecov.
|
* feat/multi_lang_limited_voc - add support for loading multiple languages, allows for lang to be set by request - add support for OpenVoiceOS/ovos-core#78 authored-by: jarbasai <jarbasai@mailfence.com>
NeonJarbas
force-pushed
the
feat/stt_control
branch
from
633ce8d to
3c6e818
Compare
- new bus api to preload/unload a STT language - new bus api to define limited vocabulary for transcriptions
JarbasAl
force-pushed
the
feat/stt_control
branch
from
ec40902 to
7429a53
Compare
|
needs OpenVoiceOS/ovos-utils#34 for tests to pass |
| lang (str): default to system lang | ||
| top_words (bool): default True, augment vocab with 10k most common words for lang | ||
| english_fallback (bool): default False, use en res files if lang file not found |
There was a problem hiding this comment.
Would it make more sense to specify an optional fallback language here? English makes sense in many cases, but maybe for Portuguese or Catalan, Spanish would be a more logical default for example?
There was a problem hiding this comment.
fallback is for failures of main STT, not for extra langs, fallback should be in same lang....
lang being session based the aim is that each engine can support multiple langs, and many of them can, but main stt could for example throw a UnsupporteLang exception. The take away is that each engine should account for the lang being requested inside the plugin itself
There was a problem hiding this comment.
oops, i misread, you mean voc fallback, i kept this because mycroft does it in their res files....
maybe we should remove this, its not like STT would pick it up...
There was a problem hiding this comment.
I see.. If we keep it, I think it should be a configurable language.. I'm not sure if something like pt falling back to es would yield usable results (2 most similar languages that come to mind). I have no strong feelings about dropping it though..
| LOG.exception(f"Failed to unload fallback STT lang: {lang}") | ||
|
|
||
| @staticmethod | ||
| def load_limited_vocabs(message=None): |
There was a problem hiding this comment.
Add return annotation and/or docstring
| @@ -0,0 +1,10000 @@ | |||
| the | |||
There was a problem hiding this comment.
consider a more descriptive name for this common_words.voc, essential_words.voc?
There was a problem hiding this comment.
funny, those were my initial names but i found limited_stt more descriptive...
There was a problem hiding this comment.
limited_stt seems ambiguous to me; my first assumption was that it included intent-related vocabulary.. maybe base_vocabulary, basic_vocabulary, foundational_words? I see this as the set of words that a domain-specific vocabulary might be added to (i.e. load a list of medical terms for some medical application or a list of product names for a retail application)
| self.timeout = timeout | ||
|
|
||
| def get_adapt_intent(self, utterance, lang="en-us"): | ||
| def get_adapt_intent(self, utterance, lang=None): |
There was a problem hiding this comment.
should we try to read language from messages using dig_for_message here? Since we're generating new Message objects in these methods, this is the last place we have a chance of resolving the originating message
We could make a decorator for this that could be applicable to every other method that looks up user language
- fix streaming STT - handlers for load/unload lang - handlers for limited vocab related OpenVoiceOS/ovos-core/pull/78
|
reopen in ovos-listener if needed |
3 participants
feat/stt control
requires #77