- From: Glen Shires <gshires@google.com>
- Date: Thu, 7 Mar 2013 10:30:47 -0800
- To: Eitan Isaacson <eisaacson@mozilla.com>
- Cc: "public-speech-api@w3.org" <public-speech-api@w3.org>
- Message-ID: <CAEE5bciQfo7=d9mwEQZU_zKJK04UxnnWYw8AC3ucQjT_n5mD3A@mail.gmail.com>
I believe it's most useful to define a set of enums (similar to SpeechRecognitionError ErrorCode), so that JavaScript can programmatically handle different errors. Thus, one criteria for evaluating which enums errors should be included is to understand understand for which conditions a script might want to take specific/different actions (examples: retry with a different voice, or inform the user that audio output is not available or configured properly.) If we also choose to add a message attribute, it should be "primarily intended for debugging and developers should not use it directly in their application user interface", similar to reco: https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#dfn-message So one criteria is: do we envision that there will be messages that will provide more info beyond the enums we define. I propose we first reach consensus on whether we need "message" string in addition to "error" enum code. Then let's decide whether to re-use SpeechSynthesisEvent or define a new SpeechSynthesisErrorEvent. Glen Shires On Thu, Mar 7, 2013 at 10:26 AM, Eitan Isaacson <eisaacson@mozilla.com>wrote: > This all looks great, a quick tangent below.. > > On 03/07/2013 10:11 AM, Dominic Mazzoni wrote: > > "language-not-supported" // unsure if necessary, since > > should use getVoices() > > The way I understand the voice matching, an API consumer could simply > send an utterance to speak with a language specified without doing > getVoices() before, and trusting the user agent to find the best match. > For example: > > The app specifies en-GB in an utterance. First the UA searches for an > en-GB default voice, if that is not satisfied, it searches for an en-GB > non-default voice, if that is not satisfied, it searches for the first > "en" prefixed default voice, if no luck it searches for an "en" prefixed > non-default voice. So hypothetically, the matching voice might be en-US. > If there are no English voices, then a "language-not-supported" error > could be raised because there is no voice that could synthesis the > utterance. > >
Received on Thursday, 7 March 2013 18:31:56 UTC