LexiconCode

> > > Well, when we touched translations way back, bothering people writing grammars with writing `_(spec)` instead of `spec` (gettext) seemed too much. This seems to have a bit...

Some further thoughts for discussion. What I've considered an API in the context of Caster is a stable interface for customizing existing commands. Given that definition of scope as for...

Ultimately, Through filter rules (soon to be Ttransformers) I plan to solve the 90% of user customizations straight through a UI. This editing command/action, adding new and removing commands from...

> > What I've considered an API in the context of Caster is a stable interface for customizing existing commands. Given that definition of scope as for adding new, editing...

> > > > I would prefer a mechanism for generating translations from existing grammars as seen with the dragonfly config implementation. Does mean we have to use it but...

> Since extras is actually python code and not just a string, how would we represent it in the configuration file? It could be a method call for all we...

I would love to see a Grammar API and a mechanism to update in engine user customization rather than changing source code. However... The transformers have been dropped from the...

I've reopened the issue. A grammar API opens the door for multilingual support as long as the speech recognition engine supports the language. However there are some challenges that need...

@mrob95 [considered](https://github.com/dictation-toolbox/Caster/pull/451) automatically converting items to RegisteredActions. At the time I wasn't fully convinced to automate conversions however I think I've been convinced otherwise since then. However reimplementing AsynchronousAction then...

> > > Let me be a little more explicit about what I meant with "enables ContextSeeker and AsynchronousAction". If you look in `stack.py`, you'll see the rube goldberg machine...