I noticed that Waze doesn't approach bilingual countries just like GMM does.
For example, in GMM, we can write multiple names for the same road in 2 different languages and based on the user's current phone language chosen, the map changes accordingly.
Unfortunately that doesn't happen in Waze, we are stuck in 1 language only, even if we add "Alternative" name.

Here in Kuwait, we use both Arabic and English (Even street signs are written in both Arabic and English) , in Google Maps we are having no problems since most of the roads in the map are written in both Arabic and English. But in Waze, it is way different.

This is causing problems since most of the locals here prefer the map in Arabic, but also there are people who use the map in English.

My suggestion is:
In WME, when selecting a segment, we should have at least 2 fields to name the selected segment, there also has to be a drop-down menu to choose the wanted language.
The user's map should display the correct language based on the user's language settings in his/her phone.

The current 100% anonymity of UR reporters makes it impossible for editors to detect reporting patterns of specific Wazers. If URs showed a fully anonymized but user-unique handle for the reporter, editors could identify problematic or abusive patterns. This would save editors time and energy, and allow them easily to report such patterns to community leadership or to Waze for potential action.

Specifically, editors have long suspected that certain Wazers may: (1) repeatedly flag an issue, or a kind of issue, on which they refuse to accept the editing community's past analysis; (2) submit multiple URs for no clear reason, yet never engage when approached for clarification; or (3) traumatize responding editors with a pattern of strongly negative language. Being able to detect these patterns would support and protect the editing community and free up time for more productive work, without compromising reporters' anonymity.

Critically, the "Closed by" signature would have to be adjusted to ensure that, if the UR is closed by the reporter, the anonymized handle is given rather than the true user ID (or it could simply say "Closed by Reporter").

The restrictions tool used to be simpler a few years ago. Today it allows to setup not only time/days restrictions but also permits/passes, number of passengers, toll roads and more. With new options such as "allowed", "toll free" and "prohibited" it became confusing even for higher rank editors sometimes.

I've lost count of how many times I checked editors that made 1-2 edits and that added a 24/24h 7/7d permanent restriction on what should be a simple "private road". Or even setup a freeway pass on a simple street.

This tool has become extremely complex and powerful, especially since routing was changed years ago to treat any segment with a restriction applied to behave as a "Walking Trail", not routing into the segment but stopping at the junction node if the address is on the segment.

Applied restrictions are almost impossible to detect or keep track of. Without scripts or selecting and opening menus, we cannot easily differenciate a useful restriction from a wrong one. The UI also makes it harder to see, compared to a wrong red/green arrow, missing segment or other more obvious errors.

For all of those reasons it should be possible to restrict its usage per level and per country.
I would personally make it available only at L2, as 3000 edits is usually enough time to figure out that segment types exist and what their penalties are vs adding restrictions.

To branch off the discussion from the WME release topic:

RichardPyne כתב:
I would find GPS points much more useful if they were color coded by age rather than direction. Th arrows provide useful direction, but in areas where traffic patterns are changing due to construction, knowing the age of the trace would be far more useful.

dchary2418 כתב:
It could help if the GPS traces were the same original color, but shaded darker for older data.

Glodenox כתב:
I'd be all for somehow showing the age of the GPS points. Especially the more recent data seems of interest to me. Something like "last 7 days", "last 30 days" or "older" would work great as brackets for colouring, I think.

The issue with that is probably that it would allow you to track certain users in areas with not as many users. With no indication of age, this is a lot harder to do right now. But in theory this could be taken into account by not showing the age when there is little data.

Currently if you add a URL in the top comment box of a Map Comment it is not clickable. You have to save the map comment then add a URL as a conversation comment to get it to be clickable. Please make URLs in the top comment box clickable. This is the comment box that is editable after saving. Here is a link to picture of the problem. https://imgur.com/2Bz4fVt In the picture you can see the top https://www.waze.com/ is not underlined so you can't click it to open the URL. However, the bottom https://www.waze.com/ is underlined and you can click it to take you to the URL. Thanks for your consideration.

(Copied over from https://www.waze.com/forum/viewtopic.php?f=1525&t=229014)

If you try to delete unneeded junction node, but it can't be deleted due to a conflicting option between then, at the moment you need to inspect each segment to see what the differences are. This is especially frustrating when there may be a hidden speed limit set on a one way segment.

Can a dialog box pop up on deletion of a junction node if there is a conflict to allow the editor to select one of the conflicting settings for the newly joined segment?

OR

Create an error message saying the junction node cannot be deleted because of <a-b speed limit> conflicting, for example.

WME shows two kinds of closures:
- effective closures, affecting routing and visible on livemap
- suggested closures, non affecting routing and not visible on livemap. Those suggested closures always have a duration equal to a multiple of 24 hours, starting and ending at the same time of day (on different days, obviously), and are usually created by editors having a layer lower than 3. Those suggested closures result from closure reports made from the app.
The WME displays both kind of closures using exact same visuals: it is necessary to open and examine the closure, to determine if it is effective or suggested.
I suggest enhancing the WME to allow visually identifying the type of closure.

Here is how I suggest you do this: when any segment entering a JB is 'touched' in a way that would currently cause a 'flag' to warn the user that the segment is locked, WME would instead 'take a quick snapshot' of everything involved in the JB and save that information.
A pseudo picture of the JB would be created where every segment entering the JB would be 'cut' where it crosses the boarder line of the JB.
The portion of each segment within the JB would retain the current segment # and other information as appropriate. The portion of the crossing segments remaining outside would be assigned NEW 'temporary' segment # and get their data as if the segments had actually been cut at the border at the time the JB was originally created.
When a 'save' is done, the process would be reversed with restoration of original data where nothing has been touched. Where changes were actually made outside the JB to a segment that entered the JB, appropriate data merger would take place automatically, retaining the segment # for the portion of the segment entering the JB and assigning a new number to the portion that has been created by the cutting.