Windows Terminal version

1.20.10572.0

Windows build number

10.0.22631.3235

Other Software

No response

Steps to reproduce

Display the tab contextual menu, preferably with a second pane open to show all options.

There are several problems with this menu.

First: Excessive capitalization

If you check out the style guide: https://learn.microsoft.com/en-us/style-guide/text-formatting/formatting-common-text-elements
You'll see that UI text or strings should use Sentence-style capitalization, this is further described at https://learn.microsoft.com/en-us/style-guide/capitalization

capitalize the first word and lowercase the rest.
Exceptions: Proper nouns, including brand, product, and service names, are always capitalized.
If a title or heading includes a colon, capitalize the first word after it.

Tab, New, Window, Right are not brands, products, or service names, they should not be capitalized.
This looks worse in other languages as determiners make the capitalized words lose their vertical alignment, as seen in #16819.

Second: Misuse of … (ellipses)

From the Windows UX design guide: https://learn.microsoft.com/en-us/windows/win32/uxguide/text-ui#guidelines

Ellipses mean incompleteness. Use ellipses in UI text as follows:

Commands: Indicate that a command needs additional information.
Don't use an ellipsis whenever an action displays another window only when additional information is required.
For more information, see [Command Buttons](https://learn.microsoft.com/en-us/windows/win32/uxguide/ctrl-command-buttons).

(… more details about truncated text, use in data and labels not included here)

I know this is getting out of style, but … and > next to menu items were originally designed to provide predictability.
The … after a menu item means selecting it will display a follow-up dialog or window asking for more options before completing the selected action, while > after a menu item means selecting it will display a cascading submenu, finally, neither means selecting it will perform the action immediately.
Therefore, they are mutually exclusive, you cannot have … and > on the same menu item, clicking it either displays a dialog/window, or a submenu, it cannot do both.

More modern Windows UI is trying to get rid of … on menu items, trading discoverability and predictability for the sake of visual style, but including it when it doesn't mean a subsequent window will get displayed breaks both the UI guidelines we had since Windows 3.x, and the modern look. Those Close… have to go.

Note the tab contextual menu was taken as an example because it contains all the problems I wanted to mention, but other menus also contain similar errors.

Expected Behavior

UI consistency (didn't there used to be a UI guidelines check before inclusion as a Windows component?).

Actual Behavior

Unpredictability and confusion 🤪