Test of Text-to-Speech (TTS) Abbreviations in Waze Clients

[rcenteno_davis]

We also have some usage of "Pkwy" in my area and TTS does say "parkway" as expected. The doc has an entry for PKWY (in all caps). Do we need to add a separate row?

[GizmoGuy411]

The same for me.
"Pkwy" is reading out "Parkway" on the client and is more consistent with road signage.
Could someone finish this test and add to the TTS Log FIle?

Thanks,
Hagay.

... Do we need to add a separate row?

I've added "PARKWY, parkwy, Parkwy, PKWAY, pkwy, Pkway, PKWY, pkwy, Pkwy, PKY, pky, Pky, PKWAYS, pkways, Pkways" to the test rig for completeness, and will update the list in a couple of days, once the map tiles update and I can listen to the results.

[rcenteno_davis]

GizmoGuy411, I still don't see the entry for "Pkwy" (only P capitalized), but for "PKWY" (all caps).

[AndyPoms]

Only tested "Pkwy" (first letter capitalized, rest lowercase) in response to another thread...

On a side note "Waze" isn't pronounced correctly - not even close.

[GizmoGuy411]

The list was updated yesterday with the results for most of the abbreviations and capitalization variations for:

Boro, Borough, Center, Centers, Centre, Estate, Estates, Rail Road, Ranch Road, Ranch to Market, Rural Route, State Highway, Township, Township Road.

Update: Parkway and Parkways also added to list.

The most significant change was the addition of a new column to reflect the test results for both audio files that are created by Waze.

After tweaking the text more today, here is the note that was added to the file to explain the change:

• Waze creates two TTS audio files for every routed road segment on the Android. One file speaks just the names contained in the segment name property. The other prefixes the segment name with the word "at". (On iOS devices, only the prefixed files have been found thus far.) It was not until late 2012 that a distinction in the TTS results between the two files was noticed. Testing of both files started on 2013-01-12, when a second result column was added. Therefore, until all items are re-tested, an entry in the Non "at" prefixed audio file column, will be either for the prefixed or the non-prefixed results if the "at" prefixed audio file column is empty.

I have not yet edited the opening post to reflect this.

[txemt]

I have confirmed, about 5 minutes ago, that Clle reads out as "call"

[AlanOfTheBerg]

I have confirmed, about 5 minutes ago, that Clle reads out as "call"

I thought we decided a while back to just spell out "Calle" as it's only a single character different.

[txemt]

I pick something that hasn't been recorded from that list, put it into my apartment complex parking lot, then wait to see what it says. There wasn't any confirmation about "Clle" so I tried it.

[Alice2]

Wonders will never cease!! After weeks of hearing TTS announce U T South A, I finally heard all the letters pronounced as letters - U T S A. It was written as U T s A with no single quotes around the lower case s. Did I miss something about not requiring single quotes to get the letter pronounced as a letter instead of a direction? It still seemed peculiar because it appeared as all upper case letters on the client.

[gettingthere]

I have confirmed, about 5 minutes ago, that Clle reads out as "call"

I thought we decided a while back to just spell out "Calle" as it's only a single character different.

Yes, I was involved in that thread and that was the recommendation for the USA. This is what we have done throughout San Diego. Although the abbreviation from the base map import in San Diego was Cll vs. Clle.

The recommendation for Spanish speaking countries that are using the Spanish TTS was to use C. But I don't know if that is actually parsed correctly.