メニュー項目に名前を付けるための良いルールは何ですか？
アプリケーションの メニューバー からアクセスするアイテムに名前を付けるためのスタイルガイダンスを確立しています。
メニュー項目の命名に関する一般的に受け入れられているルールは何ですか？
メニュー項目の名前はいつ動詞で始めるべきですか？形容詞？名詞？
省略記号はいつ必要ですか？ （例：「ツール>オプション...」）
このページでPaul Hibbittsによって引用された標準 は、いくつかの一般的な命名ガイドラインを提供し、省略記号の使用方法も説明します（ヒント：「ツール>オプション...」は間違っています）。
他のさまざまなソースからまとめられたいくつかの追加のガイドラインを次に示します。
メニュー名は、読みやすく、認識しやすいように、短く、明確、簡潔にする必要があります。理想的には、名前は単一の単語である必要があります。各Wordは、メニュー項目の機能とメニュー項目の相互の区別に関するほとんどの情報を提供する「価値の高い」ものでなければなりません。これは以下を意味します：
文章は使用しないでください（たとえば、コピーを使用します。これをコピーしてはいけません）。
記事を含めないでください（たとえば、Generate the Networkではなく、Generate Networkを使用します）。
エチケットを使用しないでください（たとえば、「ネットワークを生成してください」を使用しないでください）。
説明テキストは含めないでください（たとえば、ここをクリックしてネットワークを生成するを使用しないでください）。
コマンドに実装を含めないでください（たとえば、Network Generation Wizardを使用しないでください）。
通常、名前には動詞を使用し、メニュー項目がコミットするアクションまたはメニュー項目が提供する目的を示します（コピー、元に戻すなど）。エンティティまたは状態の名前を避けます（例：コピー機能、復帰を使用しない）
同様のコマンドと区別する必要がない限り、「Now」を追加しないでください（たとえば、「Generate Network Now」を使用しないでください）。コマンドがではない（-===-）の場合、ユーザーからの入力がさらに必要なため、省略記号を追加します。
動詞を使用する場合、ユーザーからコンピュータへのコマンドとしてのアクティブな音声でのWord（例：ネットワークの生成）。受動態を使用しないでください（ネットワーク生成を使用しないなど）。ユーザーへの質問としてWordを使用しないでください（たとえば、Generate Your Networkを使用しないでください）。
メニュー項目が何かの属性を変更する場合は、形容詞を使用します。形容詞は、物が想定する属性値です（太字、斜体など）。単に「変更」を意味する「空の」動詞を含めないでください（たとえば、「太字にして斜体に設定」を使用しないでください）。
メニュー項目がユーザーをレビューまたは変更のために属性またはオブジェクトのウィンドウにナビゲートする場合は、名詞を使用します。ここで、名詞は宛先です（オプション、在庫など）。同様に、名詞を使用して、現在のウィンドウのビューまたはパースペクティブを変更します（例：印刷レイアウト）。 「これを取得する」という意味の空の動詞を含めないでください（たとえば、[開くオプション]、[在庫の管理]、[印刷レイアウトで表示]を使用しないでください）。
名詞は、プルダウンまたはカスケードメニュー名の文法的な意味で直接オブジェクトとして使用することもできます（たとえば、挿入>ページ番号、フォーマット>ボーダーを使用します。挿入>ページ番号の追加、フォーマット>ボーダーの設定ではありません）。
ところで、これらのガイドラインは、プルダウンメニュー項目だけでなく、すべてのコマンド（コンテキストメニュー項目、サイドバーメニュー、コマンドボタン、リンクなど）の名前にも適用されます。
出典：
Ameritech Graphical User Interface Standards and Design Guidelines（Schumacher RM、1996）。
Apple OS Xヒューマンインターフェイスガイドライン（2012）
Windows 7およびWindows VistaのMicrosoftユーザーエクスペリエンスインタラクションガイドライン
ユニバーサルWindowsプラットフォーム（UWP）アプリのMicrosoft Windows 10ユーザーエクスペリエンスガイドライン
ユーザーインターフェイスソフトウェアの設計に関するMITRE Corporationのガイドライン 、（Smith SL＆Mosier JN、1986.ESD-TR-86-278）
米国国防総省人間工学 （MIL-STD 1472G）
US Federal Aviation Administration Human Factors Design Guide Update（Report Number DOT/FAA/CT-96/01）： A Revision to Chapter 8-Computer Human Interface Guidelines （Ahlstrom V＆Longo K、2001、DOT/FAA/CT-01/08）
それはアプリケーションごとの決定だと思います。ルールがあるのは良いことです。
私が作った最後のメニューのルールは：
- オブジェクトの作成は常に：新しい[もの]
- それ以外の場合は常に動詞から始め、[もの]を削除し、[もの]をアップロードするなど
- 常にアイコンを使用する
- セパレータを使用して、グループ化します。
- 同じ種類の例を探し、一貫性を保つようにしてください
- 楕円はありません
- 「下書き/編集/承認」メニューオブジェクトの特定のケースにインデントが使用されました
- いかなる場合でもサブメニューを使用しないでください
これは一般的なパターンではありません。それは私が持っていた場合にうまくいきました。例：
開発するプラットフォームのUXガイドラインに従ってください。 Iガイドラインのモンスターリスト