"Theme locations" / "Menu Locations" when editing a nav menu are confusing labels

[helen]

First: the fact that there are two different labels (admin screen vs. customizer respectively) is pretty terrible. But beyond that, neither really makes a lot of sense in the context of being a setting for the nav menu you are currently editing. IMO it should be "Display location", as in "this is the display location (or locations) I want for this particular nav menu I am currently editing". I don't really want to do an awkward "Display location(s)" type of string - the checkboxes hopefully indicate that you can display the same menu in more than one place, but in practice as far as I've ever seen that's not particularly common.

[celloexpressions]

I wonder if just "Locations" might work? Although that's probably too vague.

[lukecavanagh]

The two current flows end up being

Appearance > Menus > Edit Menus
Appearance > Menus > Manage Locations

Appearance > Customize > Menus
Appearance > Customize > Menus > Menu Locations

Would it make sense have them both set the same, so Menu Locations?

[celloexpressions]

Visible edit shortcuts bring users directly to the selector for a given location, within the locations section. We should consider potential impacts on that flow as well.

[helen]

Specifically talking about when you are editing an individual nav menu, where the setting applies to that individual menu. "Menu Locations" as a standalone concept is not the issue at hand.

[lukecavanagh]

@helen

Do more users edit menus via Appearance Menus or Appearance Customizer Menus?

Appearance > Menus > Edit Menus
Appearance > Customize > Menus

[helen]

Replying to lukecavanagh:

Do more users edit menus via Appearance Menus or Appearance Customizer Menus?

What is the goal of this question? .org installs do not currently have any method of usage or click data collection, so I'm not sure where you expect that stat to come from or what impact it has on this ticket.

[lukecavanagh]

@helen 

I guess my end goal is this ticket just related to the customizer for menu editor or improving the menu editor in appearance?

[helen]

I do not know how to be clearer. I am proposing changing two strings to one different string that makes more sense in its shared context. It affects both.

[lukecavanagh]

@helen 

No that was clear enough.

[Fencer04]

I think using Menu Locations in both areas makes the most sense. If that is a consensus I can work on a patch today.

[helen]

@Fencer04: My preference would be to rename those two settings to "Display Location", per the ticket description:

IMO it should be "Display location", as in "this is the display location (or locations) I want for this particular nav menu I am currently editing".

Open to arguments for/against, as always.

[Fencer04]

Updated menu editing locations to all use Display Location rather than either Menu Locations or Theme Locations.

[Fencer04]

I added a patch that changes the text to Display Locations so people can check that verbiage out. One question I had was whether or not we should change the variable name. It is currently $menu_locations. I haven't touched it since it's working but didn't know what the normal protocol is.

[lukecavanagh]

This would need to be updated to reflect the change for users.

​https://codex.wordpress.org/WordPress_Menu_User_Guide#Adding_Your_Menu_to_Your_Site

[helen]

I don't want this to keep lingering so I will massage the patch and commit - however, I want to note that what I was looking for here was only changing the setting label while editing an individual nav menu. "Menu Locations" is still a perfectly good term for the locations themselves, as referenced in other places.

[helen]

In 39098:

Menus: Use a label of "Display location" for individual nav menu settings.

While "Menu/Theme locations" was descriptive of what the choices listed were, in the context of editing an individual nav menu it is more descriptive to use a setting label that tells you what it is you are affecting for that nav menu, which is where it will be displayed. Technically multiple locations can be chosen, but in practice that appears to be rare enough that we can avoid an awkward "location(s)" type string.

props Fencer04 for the initial patch.
fixes #38525.