search

dialogos-project / dialogos

The DialogOS dialog system.
https://www.dialogos.app
GNU General Public License v3.0
21 stars 8 forks source link

Strings missing localization in ASR node #109

Closed alexanderkoller closed 6 years ago

alexanderkoller commented 6 years ago

Some strings seem to be missing a German localization in the node properties window of ASR nodes:

Do we also want to localize "DirectGrammar" and such?

screenshot

alexanderkoller commented 6 years ago

The strings also don't have an English localization.

In the DynamicGrammar, the EditExpression button is also missing a properly localized label.

The intended labels are visible here: https://github.com/dialogos-project/dialogos/wiki/Knoten#spracherkennung

alexanderkoller commented 6 years ago

@timobaumann I have added the missing localizations. They are in Diamant/src/main/resources/com.clt.diamant.DiaMant.properties, at the end of the file.

Could I ask you to double-check that both the English and the German localizations (both on the "Speech Recognition" tab and the "Options" tab) are correct terminology?

Also, do you know what the "Recognize in background" option does? I don't think it is documented anywhere.

timobaumann commented 6 years ago

@alexanderkoller : I'd prefer DirectGrammar=<Generate from alternatives> (<Aus Alternativen generieren>) instead of <Generate from keywords>. keywords implies that you can say other stuff as well (you can't) and doesn't imply that you can have arbitrarily complex rules in there (you can -- or at least should be able to).

I'm not sure about recognize in background. When I check it, the recognition ends immediately. I don't know if further recognition results are integrated later, though. (A theoretical use-case could be to listen for ASR while saying something via TTS; obviously, in that case the flow can't depend on what branch is taken. It could work together with writing the result to a variable, though, which would only be filled once the recognition completes. I don't know whether/how this is integrated, though.) Can you open a bug on that?

alexanderkoller commented 6 years ago

Ad "generate from alternatives": I'd like to use the same word in <Generate from X> as in the title of the keyword list right below the dropdown for the languages. The latter used to be called "input words", which I found unclear. That's why I changed it to "keywords".

I'm not married to calling them "keywords". I don't quite understand what you don't like about "keywords" and why you find "alternatives" better - could you elaborate? (To me, "alternatives" seems too vague - many things can be "alternatives". Also, if "enable garbage" is on, you can say things that are not the keywords and the keywords will still be recognized - at least if the documentation is correct, I haven't tried it.)

Ad "recognize in background": Will do.

alexanderkoller commented 6 years ago

-> #119

alexanderkoller commented 6 years ago

I'm struggling with the negation in "Keywords doesn't imply that you can have arbitrarily complex rules in there". If I understand you correctly, you mean to say that DirectGrammars can have arbitrary patterns in the "keywords" list, and calling them "keywords" doesn't reflect that.

But as far as I can tell, the keywords can basically just be keywords and not arbitrary patterns; see our discussion on #110 . That's basically why I called them "keywords".

timobaumann commented 6 years ago

re: arbitrarily complex rules: rules, not regexps. specifications that the grammar can generate from, i.e. things with parentheses, kleene stars, alternative pipes. no non-terminals.

timobaumann commented 6 years ago

re: keywords/alternatives/whatnot the code that is concerned here is https://github.com/dialogos-project/dialogos/blob/master/Diamant/src/main/java/com/clt/diamant/graph/nodes/AbstractInputNode.java#L1000 and following lines. In essence, we're taking the content of the "keyword/input words" lines and joining them with "|" pipe symbols that indicate alternatives in the grammar.
Each "keyword/input words" line can contain anything you want, as long as we end up with a grammar in the end. That's why I find keywords too limiting.

Garbage is handled further downstream: when exporting the grammar to JSGF, we insert a garbage rule (that expands to any sequence of phones) between all terminals in the grammar. This also works for grammars from expressions or grammars that you have defined yourself.

alexanderkoller commented 6 years ago

Oh, interesting. So basically a DirectGrammar "alternative" can be anything that can be on the right-hand side of a grammar rule, except without nonterminals?

Then "keywords" is indeed not the correct word.

I just tried this with patterns like "(yes)+" and such, and Sphinx only recognized a single "yes" every time. Can you show me an example dialog where this actually works as intended?

timobaumann commented 6 years ago

it seems like + doesn't work. It works with yes yes*

timobaumann commented 6 years ago

if JSGF supports +, then this is a Sphinx bug and we should report it. if JSGF doesn't support it, we'll have to fix our export from the DialogOS grammar to JSGF.

alexanderkoller commented 6 years ago

Wow, cool. Yes, looks like yes yes* works. I had no idea.

JSGF supports +: https://www.w3.org/TR/2000/NOTE-jsgf-20000605/#20071 -> 4.5.2 Plus Operator

Can you construct a minimal example (for the JSGF grammar that DialogOS actually generates - could be that we are not translating the plus correctly, after all) and submit the bug report to Sphinx?

In the meantime, let me think about the keywords vs. alternatives.