ユーザインターフェイスの語句にこだわる

GUIソフトウェアの開発には多くのプロセスがあり、プログラミングそのものの他にもグラフィックインターフェイスデザイン、チーム開発メソッドやテストやデプロイ手順など様々なレイヤーで議論がされています。
個人や小さなチームの開発では一人が複数のレイヤーの業務を兼任することは一般的ですが、そのときに忘れられがちなものとして、設定画面やアラートメッセージなどユーザインターフェイス上の語句の推敲があります。開発者がグラフィックの作成やローカライズを外部にアウトソースすることはよくあると思いますが、母国語のメッセージ文の作成まで外注することはあまりありません。ユーザインターフェイスに現れるメッセージ文を考えるのは多くの場合プログラマ自身なのです。

我々日本語を母国語とする開発者が外国語である英語ローカライズには腐心するものですが、日本語の語句の選定にも外国語と同様注意深い配慮をする必要があります。
自然言語で書かれたラベルやアラートなどのテキスト（本稿では便宜上以下「メッセージ文」と呼びます）は開発者とユーザをつなぐ架け橋です。開発者が思い描く・提供したいサービスや操作をユーザが理解できるかできないかはこのメッセージ文にかかっていると言っても過言ではありません。美しい調和がとれたグラフィックがアプリケーションの質を高めるのと同様に、美しく調和のとれたメッセージ文が端正でわかりやすいアプリケーションを作るのです。

私にとってGUIソフトウェアの開発といえばmacOS用アプリケーションなので、macOSでの流儀からその方法と着目すべきポイントをこの投稿で試みようと思いますが、iOSやWindows, Androidなど他のプラットホームでも同様のことが言えると思います。それぞれの開発者が、もっと GUI上のテキストに気を配るきっかけになれば幸いです。



## 最初の1歩

では語句の選定において、具体的には何に気をつければよいのでしょうか。基本的には普通の書籍の校正と同様の配慮があるでしょう。

### アプリケーション内で表現を統一する
 「です」「ます」調や体言止めなど、アプリケーション内・エレメント内でスタイルを合わせます。これはアプリケーション内のテキストをすべて同じレベルに置く必要はありません。設定項目は名詞か体言止め、アラート文は「してください。」と丁寧語を使うなどのレイヤーごとの統一が望ましいです。しかし、同じ設定画面内で、片方では「データを同期する」と書き他の項目では「最後の空白を削除」と書いていたのではちぐはぐです。

### 語句を統一する
雑なローカライズで散見しますが、片方では「改行コード」と書いていたところを別のところでは「行末コード」と呼ぶ、のように同じものを指すのに単語が異なっていたらユーザは混乱してしまいます。アプリケーション内で語句は統一しましょう。

### 記法を統一する

同様に、英単語の前後は半角空白を入れるのか、カッコは半角か全角か、アラート文の最後に句点を打つのか、などの表記は統一されていなければなりません。

### プラットホームに合わせた語句を使う

例えば、macOSではウィンドウのことを「ウインドウ」と書きます。大きな「イ」です。ここで「普通『ウィンドウ』って書くじゃん、俺のソフトは初心者とか別のプラットホームから移ってきたユーザも多いからより一般的な『ウィンドウ』を使うぜ」ではダメです。ウインドウはウインドウです。「コンテキストメニュー」と「コンテクストメニュー」、「ゴミ箱」と「ごみ箱」など、この小さな違いが宗教戦争にまで発展することもあります。軋轢は避けなければなりません。


## Human Interface Guidelines

macOSのアプリケーションを開発するということはAppleの流儀に従うということです。

Appleはかの有名なHuman Interface Guidelinesの中で“Terminology and Wording”という章を設け、ユーザインターフェイスでのメッセージ文のスタイルを規定しています。
このガイドラインでは英語での語句の選定にのみ的を絞っていますが、中で触れらていることのいくつかは、日本語でも共通して使えます。

- [OS X Human Interface Guidelines: Terminology and Wording](https://web.archive.org/web/20160901012119/https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html)<sup>4</sup>
- [iOS Human Interface Guidelines: Terminology and Wording](https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/FeedbackCommunication.html#//apple_ref/doc/uid/TP40006556-CH56-SW1)

この中には「[メニュータイトルはCapitalizeすべし](https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/20000957-CH15-SW4)」「[下位項目ラベルを導く項目ラベルはコロンで繋ぐべし](https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/20000957-CH15-SW8)」など、英語のスタイルに関する規定が多いですが、「回りくどい言い回しは避けるべし」や「テクニカルタームを避けユーザがわかりやすい語句を選択すべし」などは他の言語でも同様でしょう。
また、このような多岐にわたって細かく指定されたガイドラインがある<sup>1</sup>、という事実自体の認識も大切ですが、それ以上にポイントなのは、__メッセージ文を書くときはこのくらいのレベルでこだわらなければいけない__、ということです。

もちろん英語メッセージ文を書くときは、ここに挙げられている項目はすべて準拠すべきです。

### 開発者用語を避ける

この中でも“Avoid developer terms”（開発者用語を避ける）は、プログラマが忘れがちな視点です。“dirty document”でなく“unsaved document”、“sheet”でなく“dialog”など、「Appleの公式リファレンスで呼ばれているのだからこれが正式な呼び方だろう」という早合点は避けるべきであることがわかります。開発者内で共有される語彙とユーザの語彙は別なのです。


## “Use proper Apple terminology” −−Appleらしい語彙を使う

Human Interface Guidelinesでは「チェックボックス項目を選択」というひとつの言い回しでも、“check”や“click”、“turn on”ではなく“select”を使え、と指定しています。他の単語を使っても意味は通るし自然な英語です。しかし、macOS全体で調和したユーザインターフェイスを提供するために、アプリケーションを超えて同じ操作は同じ言葉で説明することを求めているのです。

これもまた英語のドキュメントになってしまいますがHuman Interface Guidelinesのほかに、Apple Style Guideというものがあります：

- [Apple Style Guide](http://help.apple.com/applestyleguide/)

このドキュメントはAppleが使う用語のスタイルを規定した辞書です。ファイル名のことは“file name”と書かずに“filename”と一単語にする、 X軸、Y軸は“x-axis”、“y-axis”とハイフン付きで書く、ただし“x and y axes”と併記するときはハイフンをつけない、など厳しい指定がアルファベット順で並べられています。英語ローカライズをする人はこの文書はとても役に立つと思います。

### 日本語もしくは他言語ローカライズ

では、日本語はどうでしょう。残念ながらAppleはApple Style Guideのようなローカライズの規定を言語ごとに用意していません。だからといって自由というわけではありません。Human Interface Guidelinesでも「システムの標準的なUIパーツに注意を払え」と書いています。Appleのやり方を真似れば良いのです。

#### システム環境設定

ゲームなどの対話式のアプリケーションでない限り、ローカライズすべき語句の多くは環境設定のようなコントロールUIとアラート文でしょう。環境設定に関しては大変便利なお手本があります。システム環境設定パネルです。

![Screen Shot 2015-09-09 at 18.13.24.png](https://qiita-image-store.s3.amazonaws.com/0/6520/20507abe-5234-0d11-5aaa-ec32f8848707.png)

これだけ多岐にわたる設定ジャンルがあります。チェックボックスラベルやユーザがやるべき操作の説明方法、追記的な解説の入れ方など、様々なタイプの設定パーツの例が見られます。自分のアプリケーションで提供しているインターフェイスや操作と似たものを探し表現を模倣しましょう。

もちろんFinderやPreviewなどAppleが提供する他のアプリケーションの環境設定や操作パネルも参考になるでしょう。

#### Glossaries

操作パーツは多くの場合短い名詞句だったり体言止めの文だったりしますが、一方ダイアログ文などの比較的量の多い文章の場合はどうでしょう。わざわざ変な操作をして欲しい文に似たアラートを探し出すのは大変ですね。このときはApple Developer Center内にある[Glossariesデータ](https://developer.apple.com/downloads/?name=Glossaries)が便利です。

![Screen Shot 2015-09-09 at 18.29.37.png](https://qiita-image-store.s3.amazonaws.com/0/6520/087e8aeb-52a9-525d-be5d-ad279017b719.png)

これは本来AppleGlotというローカライズを半自動化するための開発者向けアプリケーションのための言語別 XMLデータ集なのですが、要はLocalized.stringsのように元の英文とローカライズされた文が対で入っているので、気になる単語で検索をかけて日本語表現を見る、などという用途に使えます。
システムからmacOSで標準で入っているアプリケーションまでほぼすべてのローカライズデータが詰まっているので、例えば自分が開発しているアプリケーションが動画に関するものならQuickLookのローカライズデータを見てみる、フィアル操作に関するものならFinderのローカライズデータを見てみる、などをすると良いでしょう。
文章の表記でも英文で“Are you sure you want to…”は「〜してもよろしいですか？」と書く、などの法則がすぐに見えてきます。

#### Human Interface Guidelines

また、Appleが標準となる英語表記の時点でどのような縛りをつけているかを知っていることも日本語ローカライズテキストを作成する上では大切です。それを知った上で初めて、それら英文でのルールを日本語にしたときにどう適用させるのかに注意を払うことができます。
例えば、macOS では続く操作があるメニュー項目は三点リーダ「…」を使うことは知られた事実ですが、これを日本語にローカライズするときはAppleは三点リーダ記号「…」ではなくピリオド3つ「...」に置き換えることが多い<sup>2</sup>です。それ以外にもドイツ語の場合は単語の後に直接三点リーダを繋げる（Open…）のではなくスペースを一つ開ける（Öffnen …）など、言語ごとに異なる明文化はされてないデファクトスタンダート的な仕様も見えてきます。
先ほどの“Are you sure you want to…”も、英語でユーザに操作の確認をするときにこの定型句を使うことを知ってればこそ対応する日本語表現がわかるのです。

#### サードパーティ・アプリケーション

Appleが提供しているアプリケーションやサービス内で収まらない表現については、他社製のアプリケーションの表記を参考にするという手もあります。しかし、気を付けてください。それらベンダーが Apple と同じレベルで語句選択に注意を払っているとは限りません。あくまで、macOSを愛している信用ができるベンダーや開発者のアプリケーションを参考にするに留めてください。iOSゴールドラッシュから「macOS版も出したよ」みたいなのは「macOSらしさ」という観点でみると怪しいものです<sup>3</sup>。


#### そのほか

日本語ローカライズに特化したオンライン記事はあまり目にしませんが、そのなかでもZumuyaさんのまとめている：

- [Mac アプリケーションの日本語表記ルール](http://zumuya.com/documents/MacAppsJapanese/)

はよくまとまっていて大変助かります。まずはここに書いてあることから自分のアプリケーションを見直してみてはいかがでしょうか。


## まとめ

以上、macOSでメッセージ文を書くときに参考にしているドキュメント、注意すべき点などをまとめてみました。一時期気を使って修正しても、ときの流れとともに当時決めた作法を忘れてしまったり、別の開発者が加えたコードで別の表記がまざってしまったということはままあることです。これを機にあなたの.stringsファイルを見直してみるのも良いのではないでしょうか。
あと、スペスミスなどの単純なタイポも見直すと、意外と見つかったりして過去の自分にがっかりします。


--- 
1. これを書くにあたってiOS版のHuman Interface Guidelinesも読みましたが、iOSのTerminologyの項はmacOSと違い随分あっさりとしていて正直がっかりしました。
2. これは実のところApple内でも一貫されておらず、意見が分かれるところでもあります。ただ、中核のなるシステムや Finder などでこの法則が活きているので、Apple的にはこちらが標準なのだと個人的には思っています。
3. 筆者の偏見も含まれます。
4. [2018-01 追記] このページ、現行のHIGではなくなってしまいました。いい内容だったのに…。