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

I’m android and always up for helping to test anything.

As a side note, the way the current TTS says ‘Henrietta’ is hilarious and/or scary, take your pick.

Not many people are authorized to see this forum. It is titled “TTS New Voice - Testers” and currently has 34 members, 62 posts in 7 topics. It is a child of the Localization forum.

The only way I knew about the new voice, originally, was via direct email from Waze. I assume they/someone created this forum based on those who volunteered. I did not volunteer because there’s enough stuff I do for Waze and I didn’t need another thing to remember to test, give feedback for, which is then ignored.

I don’t know these editors can be added or not. I know that Orit enabled the voice for them in their clients. I already confirmed with one of the editors that they can see the and test the new voice “US Jane”.
Any idea if they can be added?

It’s not there in my client.

I sent the email. I’ll check and let you know.

Penn => Pennsylvania belongs on the list to be deleted.

This is another conflict. You cannot use a combination of letters of a real word as an abbreviation for another word. If you want to do that, you’ll have to include the period or something which makes it distinct. See Penn => Pennsylvania above.

Doing some Wiki cleanup. I noticed on the OP the link to Abbreviations and acronyms was changed in the Wiki for country specific naming some time ago. I fixed the OP to note that and then added a link directly to the US version of the page for faster linking and less confusion for people in this US forum.

In reviewing this page on Abbreviations and acronyms the first section seems out of place in the flow. I propose that we move it after the standard abbreviations section. However since the standard section is so long, I will include a note in that section pointing people to the “non-standard” section if they don’t see what they are looking for.

I also added an opening to help clarify the purpose of the page. We can add more if we think it is necessary.

GizmoGuy, I recommend when you update the Wiki with new info from this thread (as I assume you have been doing), maybe put a comment in the Wiki page in the Other Reading section saying the data on the Wiki page is current from forum feedback as of X date.

Final note. The Wiki does not like using “&” in page titles. The page above previously used an “&”, so I renamed (moved) the page to use “and” instead. There is a redirect page for any other links to the old “&” format so there are no problems getting to the page with either spelling. Over time I will search them out and replace them for general cleanup, but we will leave the redirect just in case there are external links outside the Wiki. I cover it in the Wiki forum here.

Yeah, hang on, when did that first section get there, and what’s all this ISO 3166-1 alpha-3 business? Certainly this (not abbreviating any prefixes, even directional prefixes, if I’m reading it correctly) isn’t the rule in the United States.

I’m not sure I’ve ever seen that page before. What is the providence of this:

That page needs serious copyediting. Language is very sloppy and unclear. As an example, look at the info on abbreviating “tunnel,” which doesn’t make any sense. One refers to a tunnel, but the other refers to a roadway that is a tunnel?! Perhaps if you are familiar with the roads in question (which aren’t linked), you might know that one isn’t actually a tunnel, but is an access roadway. But that’s just a guess, and even if correct, still raises serious questions about the policy espoused there.

It would be really nice if policy-setting text, anywhere in the wiki, linked to the discussion that finalized said policy. That would allow us to determine if it is truly a global standard, country-specific, or other region-specific, and whether it is good as-is or might need re-examination in light of new developments or occasional sanity.

Go right ahead, and be sure to submit it to a new page or sandbox so others can review your work.

It’s not copyediting that page needs, it’s a full rewrite, and maybe just a removal of that first section. Those are not the rules, at least in the US, and they don’t belong on a country-nonspecific page. (They are, indeed, also pretty difficult to understand.)

It looks like one of our Australian editors was making some changes for the Australian pages and then came in making changes here as well.

I would agree and I am fine if qwaletee wants to take a first crack at it.

I created a separate page linked to the original just for easy locating if we all forget about it. Whoever holds up their hand first should be given initial control over the page and then ask for input from this forum. I have temporarily assigned it to qwaletee, but if someone else steps up or wants it just change the name at the top of the page linked above.

Once we all agree or get enough consensus we can just cut and paste the new content over the old. No need to track our session edits before the final. The history will hold the original page changes for reference.

If I am reading this correct, I have an exception to this.

We have been pushing for 2 years now for Waze to adopt the USPS (and others) two letter (without punctuation) for the US States, and Canadian Provinces.

I’d like to add another item to the spreadsheet, if it make sense. I’ve had two ongoing projects, one to work Indian Reservations and the other to work Forest Service Roads. I’ve interacted quite a bit with GIS people at Bureau of Indian Affairs and the US Forest Service and am continuing to do so.

Indian Service Road/Route (ISR-xxx) seems to be in the TTS spreadsheet already from a prior effort, without the xxx part at least. I am working on other abbreviations that would be more universal or as well.

I would now like to add FS-xxxxx to the TTS now as it is something that has cross-country applicability. The base map and subsequent edits have a variety of standards such as “Forest Service Road xxx,” “Forest Rd xxx,” “F S xxx,” and others that include Route. We could standardize on this FS-xxxx as a way to simplify and make more sound the travel of Wazers on these roads.

I have quite a bit of information from the US Forest Service, particularly functional classifications, name standards and conventions for forest service roads, access to actual GIS data for anywhere in the nation, and a policy of where USFS wants people to use their roads and where not. I will start simplifying and posting this information elsewhere soon, but it would be good to get FS-xxx into the TTS list now.

I would suggest not using FSR-xxx for Forest Service Road/Route because it is longer and somewhat redundant. Just “Forest Service XXXX” would suffice as is done for “State Route xxxx,” etc.

Vector, to the uninitiated, a state route is still an obvious road designation. But to the uninitiated ear, being asked to turn onto “Forest Service 123” sounds strange and a little confusing . It may be a bit longer, but I would prefer Forest Service Road.

In case this is a poll, I vote for “Forest Service”. It doesn’t seem strange or confusing to me, certainly not as strange as “Turn right onto Old William Pennsylvania Highway” or “Turn left onto Tee 800”.

People who aren’t familiar with these “roads” should have think about it before turning onto one.

Many of the roads have a normal name ending in “Trl” which is what will be pronounced in most cases. FS-nnxnn should be used to generate a shield because the route # is always important.

Let’s just suppose that someone is uninitiated, lost, and confused. What’s the difference between “Turn right onto [unintelligible] road 123” and “Turn right onto [unintelligible] 123”?

Half the time, I don’t know what Waze is saying anyway. When it says turn, either I see the road and I turn, or I glance at the map to see where Waze thinks I should turn.

For lack of a better expression, “This.”

We’ve had a lot of discussion here on state route naming and abbreviation standards, and while a lot of it is good, some of the arguments (especially SR-/“state route” vs. State Hwy) aren’t very convincing, I think. So everyone says “highway” instead of “route” in whatever state, I really don’t think anyone’s going to be very confused when Waze tells them to turn on “State Route 526” when they think of it as “Highway 526”. There’s a sign with some shape and the number “526” on it. Unless that state’s DOT is particularly sadistic, there aren’t going to be three roads with the same number at that intersection.

What’s ironic, sketch, is around here we don’t call them state route or state hwy. We just call it ‘291.’ MAYBE ‘highway 291’ and very, very rarely ‘route 291.’ But it’s usually just ‘291.’

I’ve even caught newbie editors around here changing it to say that as well. =/

To me, there is. When you hear the word road, you have better mental context. When you hear “Forest Service 123,” you think “what the heck is that/” And when you’re already nervous because you aren’t sure where you’re going, that can be the difference between being able to talk to your navigator later tonight, or having to wait until the morning, if you know what I mean.