Working a UR at the moment where the user is complaining that directions to “Sutton Ln N” are read out by TTS as “Sutton Lane en”. Which I’ve just confirmed it is, using Serena with a freshly cleared TTS cache.
I then went hunting around the map for other roads with abbreviated cardinal suffixes, and found that if the suffix was E, W or S it always seems to be handled by TTS correctly, whereas N is always pronounced as “en” if preceded by “Ln”, but does get correctly pronounced as “North” if preceded by “St” or “Rd”…
IIRC this is true, in that a bracketed direction suffix will always be read out as the corresponding direction rather than as a single letter, as is required when adding (N), (S) etc. onto the end of the real road name to provide additional information for the user, or to match up with direction-based instructions present on road signs.
However, IIalsoRC, where the real road name itself included the directional suffix (e.g. Sutton Lane North), it was considered acceptable to abbreviate both the road type (Road, Avenue etc.) and the direction - thus Sutton Lane North collapses to Sutton Ln N rather than leaving the direction in full as Sutton Ln North.
So now we have the situation where there are quite a few roads with abbreviated unbracketed directional suffixes, most of which seem to be handled by TTS just fine, but where in certain specific combinations of suffix and road type (Ln + N we now know about, there could be others) the suffix isn’t seen as a directional abbreviation and so gets pronounced as a letter instead.
Question is, is this just an oversight in the way the TTS was set up to handle these abbreviated suffixes (i.e. something that could “easily” be fixed by tweaking some regex or similar on the TTS server) or is it a fundamental limitation in the TTS system that would require significant effort to resolve?
If it’s the latter then fair enough and we should then probably start to think about adopting a new consistent practice for road name abbreviation - i.e. one where all directional suffixes are treated the same way, rather than one where we end up with a mismash of styles to accommodate the nuances of the TTS system.
OTOH, if it’s the former then it’s probably something that ought to be resolved by tweaking TTS to be consistent rather than by renaming the affected roads.
In both cases there’s a corresponding “South” - here and here - where the suffix is correctly pronounced. Mellow Lane East and West then prove it’s only the North suffix which causes problems for Lanes.
I’ve tested a couple of the examples you’ve given with the beta voices that Waze is currently testing, and they also say “Lane En”, which make me think it’s a problem with the abbreviations rather than the voices themselves.
I’ve made a few tests in Ireland (here) where the cardinal “N” is pronounced as a letter with “St/Ave/Rd”.
It could be interesting to have “N” retested in UK with the latest TTS “Kate”…
All the 24 UK abbreviations and the 4 cardinals (N, E, S, W) have been tested (TTS Kate) in Ireland (results here).
The only issues that I could find were:
N (North): N is pronounced as “enn” when used as suffix only and without parentheses (Tested with “Something St/Rd/Ln/Ave N”)
Gdn (Garden): Gdn is pronounced as “gardenS” with the “S”
You probably have the same results in UK.
Just retested “Ave N”, “Ln N”, “St N”, “Rd N”.
I can confirm that the issue with suffix “N” has been fixed by Waze (Thanks Tim for the info)
Kate and Thomas pronounce “North” from now now on, no more “ehnn”.
Don’t forget to clear your cache by searching for “cc@tts”
