WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#13640 closed enhancement (wontfix)

"Navigation Menu Items" Label

Reported by: johnjamesjacoby Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords:
Focuses: Cc:

Description

Got to thinking about how the internal post types work. It's late in the game to change things, but here's my two thoughts.

  1. Change "Navigation Menu Items" to "Navigation". The other descriptions are all one word, and I think the latter is effective.
  1. If the theme doesn't support menus, why even initialize this post type? No sense in adding any additional code options that let plugin authors assume something exists when it really doesn't.

I made a simple post type switcher plugin, and the UX problem with the way menus are currently setup is that they show as an option even though the theme doesn't support it, and the label is really long and looks out of place.

Attachments (1)

post-types.png (13.0 KB) - added by johnjamesjacoby 4 years ago.
Screen shot of post-type-switcher plugin

Download all attachments as: .zip

Change History (8)

johnjamesjacoby4 years ago

Screen shot of post-type-switcher plugin

comment:1 nacin4 years ago

  • Milestone set to 3.0

I see no problem with going with "Navigation," but I don't think these need translations anyway -- see also [14262] where we stopped generating useless labels for internal post stati.

The theme could also support widgets for us to need to initialize a post type, which most themes do. We're not saving ourselves much by wrapping it in an if, though at the same time that's not a bad idea.

comment:2 johnjamesjacoby4 years ago

The labels aren't entirely useless if they're also translated in the main admin navigation (Posts, Pages, Media, and Menus).

If I switch my admin language to Spanish and use my little post-type-switcher plugin, and it doesn't translate the internal post types but it does translate the admin navigation, makes for bad UX.

I'm also of the opinion that something called a "label" even if used internally should still be translatable. There's a likelihood it could be used by a plugin or somewhere else in the UI later, and having that string in the core translation files beats trusting a plugin author to include it on their own.

comment:3 johnjamesjacoby4 years ago

Not trying to be a jerk, just sayin' is all... :)

comment:4 ryan4 years ago

We need to always register because if someone created menus for a theme and then switched to a theme that doesn't support menus, we would have stuff in the DB we need to know how to handle. Also, menus work with any theme that supports widgets, which is almost all of them.

comment:5 nacin4 years ago

Many post types will be internal storage mechanisms, such as nav menus, or Core Control's logging... Shouldn't the post type switcher avoid post types that could get it into trouble? Not sure if there are flags in place to necessarily get to that point, but show_ui seems sensible enough.

comment:6 ryan4 years ago

We're past the string freeze, and it does seem like non-public types should be excluded from the switcher. Would excluding !public types work for you jjj?

comment:7 nacin4 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.