Skip to content
← Alexa Skills - Developer Voice And Vote

How can we improve Alexa Skill development services and tools?

Alexa Skills - Developer Voice And Vote: Other

Categories

JUMP TO ANOTHER FORUM

(thinking…)

SSML - Interpret As character - Doesn't respect case

Interpret-as tag allows you to have the device speak characters, numbers, addresses, etc.

One thing I noticed however is it doesn't respect case. I was wondering if something can perhaps be added to address this? If you echo out the below ssml you will just get a-b-t-h back. Ideally it would say Capital A, lowercase b, Capital T, lowercase h. I have a skill that echos back password values that are generated with different case. Right now I have to pass this into a function and do this mapping on my own, would be nice if it was something built in.

<speak> <say-as interpret-as="characters">AbTh</say-as>. </speak>

2 votes

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Mike Paine shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • amazonjames Huang commented  ·   ·  Report

    This is due to lack of support for SSML spec for format glyph and character - see below excerpt from SSML spec.

    3.4 Character string

    Specifying "characters" as the interpret-as value indicates that the enclosed text should be spoken as a series of alpha-numeric characters. (It is thus a generalization of the concept of digit string.) The text may include punctuation. The pronunciation of the individual characters is not indicated. For example, the digit '0' may be pronounced in English 'zero' or 'oh' or 'naught' at the discretion of the synthesis processor.

    The format attribute

    The format attribute can have one of the following two values:

    "glyphs"
    "characters"
    If the format attribute is not specified, it defaults to "characters".

    Format: glyphs

    This indicates all characters should be read with glyph information, explicitly specifying uppercase/lowercase, accents, diacritics etc.

    The purpose is to render the enclosed text in such a manner that it is unambiguously clear to the listener what the written text (glyphs) look like.

    This is useful, for example, for arbitrary product numbers, passwords, given names, URLs, source code statements, formulas, and other similar character strings.

    Example:
    <say-as interpret-as="characters" format="glyphs">Jö_4 2</say-as>
    capital J, o with umlaut, underscore, four, space, two

    Format: characters

    Reads all characters but doesn't provide distinction between different glyphs that could be used for the same character. For example, this format doesn't read uppercase/lowercase information.

    The purpose is to render the enclosed text in such a manner that it is unambiguously clear which characters the text contains.

    This is for example the case for spelling ordinary words or names if exact spelling (with accentuation) is not needed.

    Example:
    <say-as interpret-as="characters" format="characters">W3C</say-as>
    double-you, three, c (and not capital double-you, three, capital C)

  • Robert G Schaffrath commented  ·   ·  Report

    IMHO you are doing it correctly now by having it specifically say "Capital". I have a skill that speaks time in UTC. I had to map "UTC" to "U.T.C." otherwise it attempts to pronounce UTC as weird sounding word. I should not I could have used <say-as interpret-as="spell-out">UTC</say-as> too as it is in a private custom skill. However is NOT an option for Flash Briefing skills since those skills do not support SSML. I assume if this idea were implemented I would now hear "Capital U. Capital T. Capital C".