Per a UR in New Jersey, the pronunciation of Netcong needs to be corrected.
the pronunciation is "Net-kong", not "Net can't"

PL to UR: https://www.waze.com/editor/?env=usa&lo ... st=7352681

and PL to the segmnet with the name: https://www.waze.com/editor/?env=usa&lo ... s=32025917

I believe this would be the place for this link?

Edinger is pronounced as

Ed Ing GRRRRRR With GRR like someone growling or like ti- GER

I feel it should be

Ed In GER with GER sounding like "Ger"-on-I-mo, or "Ger"-man-y

As far as I am aware Pke does indeed work. I would have no problem adding it onto the abbreviation list.

Is it for things like Turnpike etc., not being Turnpke?

Hi,

In South Africa we use the N,R,M naming convention for major routes : N - National, M - Metropolitan and R - Regional, supposedly.

I do not always have a headset plugged in, nor have it connected to the Radio via Bluetooth. I do however always have the radio on and barely ever listen to TTS.
I recently noticed that that TTS prompts me to turn onto the 'North One North' or 'North One South' where the road designations are 'N1 North' or 'N1 South'. It's named with no spacing between the N and the 1, so I would typically assume this should be pronounced 'Enn One'.

I would assume that the English version of TTS is global and not Country specific as this is likely handled with the 'nasal twang' for US voices and the occasional 'Keep left, mate' instead of 'Keep left' for Aussie versions

Is there any way we can override this behavior with other naming conventions, or how do we handle this ?

AlanOfTheBerg wrote:As is mentioned in this thread and elsewhere, we have no ability to influence TTS pronunciation. We have requested a phonetic field which would help in many cases, but would not likely be able to influence accents.

Alan,

The post reason was twofold. Confirmation that N# produces 'north number' in TTS despite no spacing and I'm interested to know if there is a current 'workaround' for this.

I'm not concerned about the accent, but it would be cool if Waze had this bit customized with voice files like Garmin and other providers.

The TTS override as discussed elsewhere is a good idea, but if the current Livemap does not even indicate reality, this is likely also far off.
It might actually happen in my lifetime still, you never know...

davidg666 wrote:I ask because there's an issue that affects TTS here in Ireland - and presumably also in South Africa, where they use similarly-named roads - that could easily be resolved by making the TTS behave slightly differently.

David, I have been following this thread with some new interest, as we indeed have the same problem. I drive on the 'North One South' and 'North One North' daily, so it is a bit of a thorn in my side, especially since I have seen quite a few URs on this and know I can do nothing to fix it.

We can likely live with the 'N'1 N / 'N'1 (N) or 'N'1 S naming convention if Waze 'tweaked' TTS slightly, but I was not happy with resorting to the 'n'1 N or 'n'1 S convention to work around this.

I'm just curious as to how the name actually looks and displays in the client, and how visible the single quotes are.

Instead of just 'tweaking' this every time, Waze devs should possibly just look at using or defining some opening character and closing character that will likely NEVER appear in any actual names, and use that as a 'literal' indicator, where anything that apears inside the literal is not subjected to testing for abbreviations.

Something simple like the square brackets or even the curly braces. Naming it [N]1 N, or even [N1] N, and they simply drop the brackets in the displayed name, and do not pronounce [N] as 'north'. Even something like ~N~1 N, where the single 'tilde' characters are ignored. I presume fixed 'opening and closing' delimiters would be simpler to search. They could even be used as an indicator that this character sequence should be pronounced individually instead of treating it as a word, like [QE]2 or even [NY] being explicitly overridden as 'Queue Eee Two' or 'Enn Why'.

Something like this would be far simpler to implement in code, instead of having to populate an additional DB field to use as a TTS override using phonetics, where 99% of all existing named segments would likely never make use of the phonetic override.
It just requires some simple string manipulation during Back-End parsing which they likely do already.

Per a UR in Ohio, the pronunciation of Loudonville needs to be corrected. Here is a segment that has the name: https://www.waze.com/en-US/editor/?env= ... s=38475688

UR:

Ll'nville is how it was pronounced. Proper is "Loud" with a w replacing the d, "Don" with emphasis on the d, and "ville"

Mispronunciation of "Oso"
Voice: English (UK) (Thomas)
Says: oh-es-oh
Should be: OH-zo

So, I already mentioned this to Weezer but I noticed for the very first time today the TTS for CONST ZN was "Kahnst Zee N" and not the intended Construction Zone. I can also confirm this was previously not a problem as I heard it correctly within the last couple of months (not sure exactly when since I don't routinely travel this area). Any thoughts or anyone else noticing this problem all of a sudden?