The TTS engine is built into Waze and we cannot influence the pronunciation at this time. Are you positive it's just not saying it unclearly and sounds like seminary?

CBenson wrote:Sure sounds like Seminary to me too. I think Alan is correct that its just the way the TTS says Cemetery.

Is there a way to upload sound files to forum posts?

Probably not. And last time I checked the quota limit was reached and no response from Waze.

Best bet is to put the recording in your public dropbox folder and paste the URL into a post.

What do we do about different pronunciations of the same spelling?

For example Houston, TX and Houston St, New York City - Spelled the same, Pronounced ˈhjuːstən for TX & HOW-stən for NYC (pronunciation keys taken from WikiPedia, so don't blame me when they aren't right)

sketch wrote:The TTS engine has some crazy ideas. For instance, it pronounces "Iberville" as "d'Iberville", every time.

To my knowledge, Waze has only modified the way it talks to the TTS engine once—to add a pause for every slash—and that took about a year. I wouldn't expect any modifications for relatively small mispronunciations of street names, which are everywhere in every speech engine.

Goes to nuance website
Type in your street name and listen how the TTS pronounce it.
Modify the world till TTS
PROMOUNCE it correctly

Send this new "word" as TTS extension to Waze

Street name = modified street name

And ask to add it to your TTS DATABASE
once they added ,you need to clean up the TTS cache in your device , otherwise you will never get correct pronunciations

Inviato dal mio HTC Sensation con Tapatalk 2

Hi!
We have an idea how to improve TTS pronunciation. Basically we suggest to use Alt City/Street name to correctly pronounce names. The name could be even transcripted.

Please support if you like the idea!

Thanks!

TonyG-UK wrote:Abusing DB fields for whatever purpose gets a resounding no!

Well, it's just a suggestion. For instance, AndyPoms mentioned Houston, so I'll use it as an example:
Street: Houston St
Alt City: #tts Alt Name: how-stən street

TonyG-UK wrote:The correct way is to ask Waze to add additional DB fields for what you need (and yes, I know what the chances of it actually happening are).

TTS for the majority of the names works correctly. So adding a #tts property fixing 1% of the names rather than a DB field for every single segment on the map seems more reasonable to me

Kuhlkatz wrote:And what do you suggest for countries with more than one primary language.

I suggest Waze simply switch TTS off when you leave your language province.

But we're talking here about a relatively small amount of streets with incorrect pronunciation like 'how-stən' and 'ˈhjuːstən', right?

Kuhlkatz wrote:You are suggesting that editors and developers put effort into a hack for a once-off solution that is not reusable anywhere else, using a field that is already populated with valid data. Whether that data is currently of any use is another debate.

You can add as many alt names as you like, so already existing data would not be harmed. All suggested properties start with the hash (#), so it's easy to distinct property and alt name for server, client App and editors.

Kuhlkatz wrote:With the future WME editor supporting localization, they should rather design around using a separate tts override field based on the language that you are editing in, tying that pronunciation into that language code and storing the info in a field dedicated for that purpose.

You mean 11 fields, right? Because there are some countries with 11 official languages

We suggest to use alt names because it's already there. But ok, let's forget about alt names. Let's assume that it's another attribute-value pairs or properties that could be attached to any segment in Waze. Wouldn't it be cool instead of waiting for implementation of a new feature (like shields, for instance), Waze could just provide us with such info:

Hey guys, we are about to implement shields, so please use this new property as follows:
Key: #shield Value: <color><shape>:<text> -- if present, Waze display <text> on a shield shaped/coloured as <color><shape>

Example:
Key: #shield Value: GR:E40 <- green rectangular shield with E40 text

And that's it! While they implement shields we prepare the map. And sure, internally, they could store our properties wherever they like: in a database fields or a text file

Kuhlkatz wrote:Populating 4 / 5 different attributes in a single free-form field is a bad idea from a design perspective.

Tell it to Google, Microsoft, OpenStreetMaps... And don't forget the Wikipedia!

Kuhlkatz wrote:Searching through this large string of gobbledygook to get & verify the free-form TTS for every segment used, check if a shield should be generated or not, etc. would create havoc on performance, instead of searching through dedicated fields of the smallest required storage.

I keep saying that we shouldn't speculate about internals of Waze databases. Most probably, everything about segment's address in Waze is already designed as "properties" attached to segments IDs, because it consumes much less space.

Adding one empty (NULL) field to a database with millions of records leads to gigabytes of wasted (NULLed) space. Adding a property to a segment ID consumes just what it is. Google for Database Normalization

Kuhlkatz wrote:In my opinion the Suffixes should also have been split from the street names, as that is a lot of free-form text being duplicated where not required.

+1 Did you suggest it before?

Kuhlkatz wrote:Summary of the stuff above = 'Not a good idea'.

Then we should probably keep waiting for "magic fields" which will solve our problems with abbreviations, shields, TTS, time-restricted segments/turns etc? I hope those "magic fields" will take into account your (11 languages) country specificity

Modern SQL database systems have stored procedures to validate/normalize data. So text fields and key names (like #shield=GR:E40) could be validated and represented as small tiny bits internally. Street prefixes and suffixes as well.

Another point. Waze has a periodic tile update process. So the information from the WME database is being transformed into another database or whatever. Which means:

1. Data representation in WME database doesn't really affect search/client/live map performance.
2. Most of those suggested Keys could be analyzed and processed during this update process.

I suggest if you like the idea of Key-Values or at least some of its part, please go to the original topic and discuss it there. Let the Waze staff handle bits, bytes and internal representation of data. It doesn't really matter.

Thanks!