Fwd: SpeechDispatcher for LSR

[Peter Parente]

> So it might be some conflict between python-gtk and python-pygtk?
> Anyway, this whole behind-the-scenes removal from a global variable
> looks extremely ugly to me. So I just wait if you have something to add
> and will fill it as a bug in pygtk.

Nothing to add. Sounds like you know more about it than I do now. I
would file it as a bug against pygtk or at least ask on the pygtk
mailing list about it.

> So I don't know, maybe some component was
> crashed.

It could be related to this Ubuntu bug:
https://launchpad.net/distros/ubuntu/+source/at-spi/+bug/56452. The
at-spi registry daemon isn't the most stable in the world. When it
goes does, the whole desktop becomes inaccessible until it restarts.
Usually it's able to restart itself but not always.

> I would add it to the Speech Dispatcher driver and send you a patch, but
> I'm not sure about the exact format. The doc string for the variable
> only vaguely speaks about ISO language and country code, but it doesn't
> say if by ISO language code it is meant ISO 639-2 or ISO 639-1 or both.
> Also, how is language code joined with the country code in the string?
> Then, I'm not sure if this combination (language, country) is really
> appropriate. Maybe (language, dialect) is what was intended. For example
> the only suitable ISO codes (language, country) for Czech language are
> (cz, cz). This however still represents at least three main dialects of
> the language. We struggle with this question in TTS API too and so far
> we decided to use (language, dialect) where language is ISO 639 (-1 or
> -2) and dialect is a non-standardized string :( We keep them as two
> separate entries, as quite often the users don't care much about the
> dialect.

We didn't know what to do here either, and that's why the doc string
is very vague. Basically, the design for supporting language is
incomplete right now. We were looking at the languages supported by
IBM TTS as a guide to get us started. For instance, there are two
separate runtimes for UK English and US English. How would those two
be exposed as separate options in your scheme? The language is clearly
"en", but what's the distinguishing dialect? This is where we were
planning on using the country code "us" versus "uk." Like you point
out, this doesn't help with Czech where the country and language are
the same, but there are still three dialects.

So what would you recommend? Is (country, language, dialect) too much?
Can we treat "us" versus "uk" as different dialects and just have
(language, dialect)?

> Is there any key combination for setting language in LSR? How would I
> type in the language code (or similar run-time settings)? Through some
> pop-up dialog?

We're implementing the settings dialog for LSR 0.3.0. About half of it
is complete in CVS. The intention is to let the user select the
language (and country and dialect if that's what the final design ends
up being) from a list of choices supported by the currently configured
speech library. This assumes the speech engine is able to report what
languages are available. If it cannot (which I believe is the case for
many engines), we'll have to list all the known possibilities and
simply ignore choices that aren't supported by the engine.

I want to avoid having the user type in a raw string since we're quite
capable of listing the finite set of possible choices. We're aiming
for recognition rather than recollection.

Pete
_______________________________________________
Speechd mailing list
address@hidden
http://lists.freebsoft.org/mailman/listinfo/speechd