i18n: 言語リソース名の命名規則

テキストを多言語化する方法は大まかに2パターン

サイト・webサービスなどのテキストを多言語する方法はいくつかあって、詳細はググってもらうとして、（分類の仕方も色々あるけど）大雑把に以下の2つに分けられると思う。

• gettext のように、ソースファイルに含まれる翻訳元言語（英語が多い）のテキストを _() や __() といった関数で囲んで、それを抽出して他言語のリソースを作成する
• Java の ResourceBundle のように、任意の識別子（キー）と多言語対応が必要なテキスト（値）のペアからなるエントリーを含んだリソースファイルを各言語毎に作成し、それを使用する

（言葉で説明すると分かりにくいので、上の説明でピンとこない方は gettext, Java ResourceBundle などで検索してほしい。）

で、今回は後者に関して、キーの命名規則を自分達はこうしてるっていう話を書く。

ネットであまりベストプラクティス的なのが見当たらなかったので、とりあえず今やってる方法を晒して、他の人からの意見とかをもらって改善出来れば良いなあという意図。

そのうち出てくる問題点

Oracle の i18n の tutorial では、言語リソースの例として以下のようなのがあった。

英語

greetings = Hello
farewell = Goodbye
inquiry = How are you?

フランス語

greetings = Bonjour.
farewell = Au revoir.
inquiry = Comment allez-vous?

これは単純な例だけど、実際の開発ではこんな単純には行かず、以下のような問題が出てくる。

テキストの量が増えると、キーの命名規則に悩む

上の英語の例だと “greetings” というキーに “Hello” というテキストが割り当てられてるけど、開発を進めていけば “Good afternoon” や “Hi”, “Good evening” の場合はどうするんだとか、キーの命名規則をどうするのかといった問題が出てくる。

句読点の有無、大文字小文字等の違いはどうするか

上の単純な例ですら、英語の場合は “Hello” の後にピリオドがないのにフランス語では “Bonjour” の後にピリオドがある、と言ったゆらぎがある。

一般的に、同じテキストでも、使われる場面によって、以下のような違いをつける必要がある。

• ボタンのラベルとかでは句読点やピリオド・感嘆符などは（通常は）付けないのに対し、説明の文章では付けることが多い
• （日本語では関係ないが）英語などでは、タイトル、メニューの項目などは、単語の先頭を大文字にする事が多い（※）。例えば、”Pull Requests”, “Activate Your Account”

※サイトによっては、これを行わない事もある。気づいたのだと Bitbucket とか。

なので、以下のようなものは全て別々のキーである必要がある。

• “Hello” vs. “Hello!” vs. “Hello.”
• 「こんにちは」と「こんにちは。」
• “Show all issues.” vs. “Show All Issues”

英訳を頼んだ時に、punctuation, 大文字小文字が意図通りにならない

前項に関連するが、例えば以下のように

show-issues = 課題を表示する

キー名が適当だと、これの英訳を依頼した時に

show-issues = Show Issues

って英訳が上がってくるかもしれないし

show-issues = Show issues.

ってのが上がってくるかもしれない。こういう揺らぎは困る。

こんな風にしてる。意見求む。

で、自分達は開発者で検討した結果、こんな風な命名規則にした。

まずは具体例だけど、こんな感じ。

page-home.label.select-team=Select Team
feature-organization-admin.page-integration.label.title=Integration

命名規則について説明していく。

全般

<view or dialog>[.<sub-context>].<control-type>.<name>

• <view or dialog> が、2階層以上の場合は、. で分ける。
• control-type & name は、この並びで。CSS の命名規則も似たようになっている。

<view or dialog>

• <view or dialog> には、以下の prefixを付ける。
  • page
  • dialog
  • feature: 複数ページにまたがるような要素の場合、「ｘｘ機能」としてまとめる
• 具体例
  • page-top
  • feature-organization-admin
  • feature-organization-admin.page-integration-settings

<sub-context>

細かいルールは設けない。コンポーネント等、分かりやすい単位で区切る。

例

• flash: フラッシュメッセージ
• footer
• header
• sidebar
• comment-area
• search-form
• etc.

<control-type>

以下のいずれか。

• button
• label
• text: 普通の文章
• checkbox
• radio
• dropdown
• listbox
• tooltip
• alert: alert ダイアログ
• confirm: confirm ダイアログ
• placeholder

control-type によって、句読点を付ける付けない、単語の先頭の大文字小文字などが自動的に決まるところがポイント。

メリット

命名規則を決めたら、以下のメリットがあった。

• 命名にあまり悩まなくなった。
• 句読点、punctuation、大文字小文字などの表記ゆれがほぼ無くなった。

この方式で開発した結果のサイトがこちら。ブラウザの設定で英語と日本語を切り替えて、違いを確認してもらえればと。

まとめ

もっと良い命名規則はあると思うけど、とりあえず何らかの規則を設けておくと、サイト・サービスの国際化の質が上がると思う。

実際、仕事で関わっている他のサービス（日本の会社だけど英語版がある）だと、結構表記ゆれが多いので、良いサービスだけにちょっと残念。