ちょろっとメモ。の割には長くなったけど、最後の方にいいことが書いてある。

※技術英語や翻訳 Advent Calendar 2015に参加してみました。スレ違いだったらすみません。

追記: taka-oyamaさんの記事「多国対応ウェブアプリを開発する前に知っておきたかったこと」も参考になります。

追記: 「17ヶ国の多言語対応Tips」で当記事を紹介いただきました。素晴らしいスライドです。

追記: 「本当にあった怖い誤訳」によると、今でも機械翻訳をそのままウェブページで使っている自治体があるそうです。怖す。

概要

Web アプリやモバイルアプリを問わず、アプリで当てたらそれ英語化だ多言語化だ国際化だ、となることは多い。しかしアプリの作りなどさまざまな原因によって、他所の国の言葉に翻訳してもらっても実は現地の人から見たら微笑ましくも残念な結果になっていたということがざらにある。

そしてこれは翻訳者を灰になるまで酷使すれば解決できるような問題ではなく、アプリを最初に設計する時点でいつ多言語化してもいいように準備しておくべき。これをやるのとやらないのとでは、かかるお金が数倍違ってくると断言する。そして品質も数段違ってくると断言する。

といってエンジニアやウェブデザイナーがあらゆる自然言語と取っ組み合って共通の法則を抽出する時間など当然あるはずもない。ここでは、アプリケーションを多言語化するうえで押さえておくべき最小限のポイントについて記述する（実際には日付・時刻やタイムゾーンなど、はるかに膨大なノウハウがあるので、これですべてと思わないこと）。

以下特記ない限りUTF-8世界を前提とする。また、英語以外の単語は説明のために適当に引っ張ってきたものなので当てにしないこと。

なお、多言語化は専門の会社に依頼する方が結局早い（価格や品質のことまでは関知しないけど）。多言語化を自力でやろうとするのは車輪を200個ほど再発明するのに等しい。しかし依頼する側にとって、これらのノウハウを押さえておくことで節約できる時間とコストは途方も無く大きい。

そして依頼先を選定するうえでも大きく役に立つ。ここに書かれていることを確認しようともしない会社はたぶん検討に値しない。

法則1: 多言語化すると、たいてい文字列が長くなる

日本語や中国語は漢字という強力なシンボルのおかげで、たとえば危険を知らせるのに「危」一文字で済む（情報理論っぽく言えば「エントロピーが高い」）けど、アルファベット圏ではそうはいかない。

ラテン系言語 (スペイン語・フランス語・イタリア語、ポルトガル語、ルーマニア語など)

言葉を後ろから形容するので長くなりがち。Orquesta De La Luz みたいに、後ろにdel なんちゃらだのde la うんちゃらだのがぶら下がる。少なくとも英語の2倍から2.5倍(日本語からなら少なくとも3倍)の長さの表示領域を確保しておく必要がある。(英語はハイブリッドなので Mac the Knife みたいに後ろからの形容もあれば domain admin みたいに前からの形容もある)。

たとえ「OK」みたいにちっぽけなボタンでも、ラテン系に翻訳するだけで一気に倍の広さが必要と思っておくこと。OK ボタンはスペイン語では [Acceptar] とされることが多い。

ついでながら、いわゆるノーブレークスペース(nbsp)は、本来こういうなんちゃら del Solみたいなひと続きの言葉が途中で改行されないようにするために、通常のスペースの代わりとして使う。あるいは、商品名や企業名などの固有名詞が途中で改行されるのを防ぐのにも使う。句読点の前以外はどこで改行されても原則OKな日本語圏にいるとnbspの使い道はなかなか気付きにくい。

例: こういう改行が残念であるのと同様に、

大日本株
式会社

こういう改行は現地の人にとって残念。

Orquesta De
La Luz

●の位置にnbspを使えばそこで改行されなくなる。表示エリアが狭ければ当然切り捨てられる。

Orquesta●De●La●Luz

ゲルマン系言語 (ドイツ語、オランダ語、ベルギー語など)

単語が合体して複合語になれる(漢字の熟語のようなイメージ)ので、知識のない人からは予想できないぐらい長ったらしい単語が使われることがしばしばある。たとえば英語の domain はドイツ語では「Herrschaftsbereich」となる。英語と比べても3倍増しだ。日本語のことしか考えずにボタンやメニューのレイアウトを作ると、後で泣きを見る。泣け。もっと、泣け。

ついでながら、ドイツ語の名詞は必ず大文字ではじめなければいけないという文法ルールがある。逆にオランダ語はドイツ語を小文字中心にしたような塩梅。

ついでながら、ドイツ語の動詞はまるで日本語のように文の最後に置くこと「も」ある。

ついでながら、「ドイツ」(Deutsche)と「ダッチ」(Dutch)は語源が同じ。

メモ: 単語の途中で改行したい場合

ドイツ語みたいに単語が超長くなりがちな言語では、ソフトハイフンがしばしば使われる。ソフトハイフンを単語の途中に仕込んでおくと、普段は見えないが、単語がポキっと折れて改行されたときだけ切れ目にニョキッと生えてくる。

Herrschaftsbereich
↓
Herr-
schaftsbe-
reich

HTMLであればブラウザのレンダリングエンジンが自動でこれをやってくれるが、自前のアプリであればこれを自分で処理しないといけない。
ただし、なが～い単語のどこにハイフンを置くかは、現地人に聞かないとわからない。勝手にハイフンを置くととんでもないことになるし、ハイフンを置く場所を機械的に決定できるルールもない。

ついでながら、英語圏の新聞社にはハイフン専門の校正係がいるという。それほどまでにハイフンの扱いは厄介ということ。

キリル系言語(ギリシャ語、ロシア語、ブルガリア語、ウクライナ語など)

（コメント欄にいただいたツッコミもご覧ください）

1文字が日本語で言う「全角文字」と同様のバイト数になる。なので1文字=1バイトではないことがほとんどであるうえに、表示上もアルファベットの倍の幅を取る。当然、同じ文字数でも英語の倍の幅を取る。ハングルも同様。

East Asian Ambiguousなる概念があるらしく、文字数のカウントに注意が必要とのこと。また、フォントによっては全角並の幅を取ることもある。

ついでながら、ロシア語は割りと合理的に整備された言語で（エカチェリーナ二世の側近ダーシュコワ夫人の功績だろう）、格変化などによって文章の情報密度が高く、ロシア語から他の言語への翻訳は割りとやりやすいと伝え聞いたことがある。

キリル文字はたまに恐ろしくマイナーなエンコードを施されていることがあるので注意。知らずにUTF-8なんかで開くと文字化けるのだけど、ロシア語を読めない人にはどこが化けたのかわからないというすごく微妙な化け方（日本語でいうとたとえば「め」が「ぬ」になってるみたいな感じ）になっている可能性あり。

追記: ロシア語などのスラブ系言語には、英語で言う「冠詞」（aとかtheとか）の概念がないのだそうだ。その点だけは日本語と似ているかも。英語の冠詞にヨワイのは日本人だけじゃない。

ハングル

詳しくは知らないけど、かつて文字コードの大移動があったらしい。古いテキストで注意が必要かもしれない。縦書きもありなど、日本語と似た特性だけど、日本語にない「スペース分かち書き」がある。

裏はとってないけど、縦書きでは句読点を「。、」、横書きでは「．，」にするのが普通らしい。

中国語（簡体字・繁体字など）

句読点の位置が日本語と微妙に異なるのは既におなじみと思う。日本語では句読点が隅に置かれるが、中国語では中央に置かれる。海外にアウトソースすると、たまに日本語の句読点に中国語のそれが使われてしまうことも。

タイ語

文章の末尾に句点（ストップマーク）がないという驚きの文法。複数の文の間は半角スペースで区切るそうだ。文末でちょうど改行されるときはそのスペースすら消滅する。さらに文中の英語の前後にスペースを置くことが多く、句点を前提とする処理が厄介になる可能性がある。

番外編: モンゴル語

使う機会はあまりないかもしれないけれど、モンゴル語は縦書きするにもかかわらず、行が左から右に進行するというすさまじい特性を持っている。これはアラビア語からの影響によるものらしい。
縦書きのモンゴル語に、英語とアラビア語が両方含まれると、英語とアラビア語が横に寝た形で表示されるのは仕方がないとして、両者の天地は互いに逆になる。

メモ: 長い単語の切り詰めは極力避けるべし

さっきのドイツ語のHerrschaftsbereichに限らず、どうやりくりしても入りきらないということもあるだろう。実は「省略形」(abbreviation)というものがあり、たとえば「Herrschafts.」みたいなふうに末尾にピリオドを付けて切り詰めることが一応できる(トルコ語みたいにピリオドを付けずに切り落とす言語もある)。

ただし、いくら可能だからといって翻訳者に気軽に切り詰めを指示しないこと。当然ながら、切り詰めれば切り詰めるほど文章は見苦しくなり、ボタン名は何を意味しているのか現地の人にもさっぱりわからなくなる。切り詰めは即品質の低下と思った方がいい。

たとえば日本語の「終了」というちっちゃなボタンを、何も考えずに各国語に翻訳したとする。そのままでは当然入りきらない。ここまでの説明だけでも、このサイズのボタンに他の国の言葉を押し込めるとどんな無残なことになるか、何となくお分かりいただけると思う。

切り詰めを強要された現地の翻訳者は、たとえ口には出さなくても「お金をもらっている以上やれというならやりますよ。でもこんなに切り詰めたら誰にも読めやしない。どうなったって知らないよ。馬鹿じゃなかろうか。」と内心あきれているはず。

さんざんお金をかけて翻訳した結果がこれでは悲しすぎる。そうならないためにも、文字列は多言語化で量が最大で3倍ぐらいまで膨れ上がるという前提で、余裕をもったレイアウトにすべき。せっかく液晶大画面が普及してきたのだから、レイアウトをぎゅうぎゅうに詰め込まないこと。

文字数制限は極力避けること。それならティッカー（電光掲示板）のように流れ表示する方がまし。

英語圏など海外のWebデザインが、おしなべて広々とした余裕のあるレイアウトになっていることが多いのは、ひとつには多言語化を常に意識していることがあげられるだろう。特にヨーロッパの小国では、自国語版以外に最低限英語版も作らなければまるで稼げない。

ひるがえって日本のWebデザインはというと、Bootstrapだなんだとテンプレートを駆使しても、新宿や香港の裏通りの看板のような雑然としたものになりがちだったりする。平たく言えば、ダサい。

法則2: 数字に気をつけろ

日本語や中国語は発音が漢字に覆い隠されているおかげで数字の活用形(ひい、ふう、みい、ようなど)の問題に直面せずに済んでいるけど、たいていのアルファベット系言語では、文章に含まれている数字だけを差し替えると、とんでもないことになる。

英語はこの手の活用がかなり衰退しているけど、それでも「単数形」と「複数形」というものがあり、いやでもこれを使い分けないといけない。とりあえず以下を見ればおわかりと思う。(なお以下は説明のためのものであり、実際には英語をアラビア数字から開始するのは非常に嫌がられる。箇条書きと間違えやすいからだろう。)

1 user
2 users

文章形式だとこうなる。user/usersだけではなく、be動詞is/areも使い分けなければならない。

There is 1 user.
There are 2 users.

日本語(や中国語)なら全部「1ユーザー」「2ユーザー」と数字だけ差し替えても何の問題もないのに、単数か複数かで訳語を表示しわけないといけないとは何と面倒臭い。しかしこれはまだ生易しい方。では数字が0だったり0.5だったり-1だったりしたらどうするか。

1 unit -- 単数
0 units -- 複数(!)
1.0 units -- 複数
0.5 units -- 複数 (ただしコンテキストによって異論あり)
-1 unit 単数 (不足を表す場合)
-1 units 複数 (数学的マイナス)
2 units 複数
100 units 複数

英語ですらこれだけの使い分けが必要になってくる。特に0が複数形扱いというのは日本人から見ればなぜ?と思うのが普通だろう(エンジニア的には、バイナリのゼロにはプラスとマイナスの2種類があるという屁理屈もあるかも)。

結局英語圏でも、「1以外は複数」でえいやっと丸めるしかなかったと思われる。英語の文法が整備されたのはたかだかここ400年ぐらいの話だし。

なおRubyなどのライブラリには英語の単数複数をよしなにやってくれる機能があったりするけれど、不規則な活用には手が回らない可能性もあるのでご注意。

では英語以外の言語はどうか。

少なくともヨーロッパの言語の多くは、「単数」「複数」という生易しい区別だけでは勘弁してもらえない。単数複数の他に、「1から5までの数のときの活用形」とか「5から10までの数のときの活用形」など、もっと細かい区分があるものもある(アラビア語やロシア語など)。

詳細は説明しきれないので、興味のある方は世界の言語の数体系などを参照して欲しい。

要は、文章の途中にある数字や文字を差し替えるようなUIを作るなということ。でないと自分が泣きを見る。以下に「多言語的にダメダメなUI」の典型例を示す。これを見たら何も言わずにその場から逃げるべし。

参加者は [10] 人です

上の [ ]の部分はドロップボックスを表す。仮にこれを多言語化すると、それだけのために何とおりもの言葉の使い分けが必要になってくる。そしてその使い分けはほぼ確実にプログラマーがやらなければいけないのだ。

なお、中国語と中国文化の影響を受けた言語(日本語など)は、数体系が整っていて理不尽な点がほとんどないというありがたい特徴がある。このことはもっと感謝していいと思う(誰に?)。たとえば日本語では3角形、4角形...n角形と数字を入れ替えれば済むけど、たとえば英語はtriangle, square, pentagon...n-gonと煮ても焼いても食えない(これはギリシャ語由来だけど)。日本語ではその代わり、敬語を含む「相手によって使い分ける言葉」が非常にややこしく発達しているけど。

追伸: 現代中国語の「命数」は致命的な問題を抱えていることを知った。誰かがmegaという接頭語を「兆」と訳してしまい、それが定着してしまって変えるに変えられなくなってしまったとのこと。

中国では、近代まで万万進と万進が混用されたままであった。それに加えて、メートル法の接頭辞のメガ（10^6）に「兆」（下数における 10^6）の字をあてたため、さらに混乱が生じた。今日では、「億」は中数の 10^8、「兆」は下数の 10^6 の意味となっており、兆より億の方が大きくなっている。日本でいう兆（10^12）は「万億」といい、京以上については、例えば 10^16 は「万万億」または「億億」のように呼んでいる。台湾には日本の命数法が導入されていたので、兆は 10^12 であるが、京以上の命数はほとんど用いられていない。
https://ja.wikipedia.org/wiki/%E5%91%BD%E6%95%B0%E6%B3%95#%E5%A4%A7%E6%95%B0 より

追伸: カシオがインドで販売している電卓では、インド独自の桁表記が採用されている。

法則3: ジェンダーに気をつけろ

そしてこれがフランス語やドイツ語やスペイン語になるとさらに恐ろしいことになる。ジェンダー(Gender:性別)というものが加わってくるのだ。「男性名詞」「女性名詞」というあれだ。フランス語では太陽は男性で月が女性、みたいなあれだ。ドイツ語になるとさらに「中性名詞」というものまである。

ジェンダーが要注意なのは、ジェンダーが変わるとその語だけではなく、主に冠詞など周りの言葉まで変更しなければならなくなるという点だ。むしろ、名詞は冠詞がくっつかないと完成しないと考えてもいいくらい。

英語は幸いこのジェンダーがほぼ絶滅していて、船や国を指す時にsheと呼ぶぐらいしか残っていない。しかしフランス語はもちろん、ロシア語やアラビア語などに至るまで、たいていのヨーロッパ言語にはこのジェンダーが深く食い込んでいる。(ジェンダーとは違うが、日本語にも話し言葉の言い回しに「男言葉」「女言葉」というものがある。しかしこちらは急速に絶滅しかかっていたりする。昔の映画の字幕などで役割語として「〜ですわ」などとしたりするぐらいか。)

追記: ロシア語を含むいくつかの言語では、人名の姓（ファミリーネーム）が人物のジェンダーによって活用されるのだそうだ（http://www.worldsys.org/europe/tips-russian-names/）
たとえばドストエフスキー（Достоевский）は男性用の姓であり、同じ姓であっても女性はドストエフスカヤ（Достоевская）と表記・発音するらしい。姓でソートする場合につまづきの元になりそう。

フランス語は20進法が基本になっていてただでさえ数の数え方がややこしい(もっとも英語にも12進法的な要素が混じってるけど)うえに、そこにジェンダーも考慮しなければいけない。つまり、何の数を数えるかで言葉が違ってくるのだ。フランス語やスペイン語にいたっては、序数(英語で言うfirst, second)までジェンダーに影響される。

なお、前のセクションで文章の数字を差し替えるととんでもないことになると書いたけど、同様にたとえば文章の中で製品名のような固有名詞を差し替えるのもまずい。日本語では製品名だけ差し替えてもたいてい問題はないが(英語は何とかなる場合もあるが、単数複数にひっかかる可能性に注意)、ジェンダーを持つ言語では前後の単語を製品名のジェンダーや単数複数に合わせて変えないといけないことがあるからだ。上述のドイツ語ルール「名詞の1文字目が必ず大文字」によっても言葉の差し替えが制限されることがある。フィンランド語にいたっては、固有名詞そのものがコンテキストによって語尾が変化するという恐ろしい特性がある。

さっきのダメUIをもう一度引用する。

参加者は [10] 人です

フランス語やドイツ語だと「参加者というのは男か女かどっちの方が多いのか」と翻訳者から質問が来る可能性がある。ジェンダーが決定されないと訳語の周りの冠詞などが決まらないのだ。

また、製品名について「この製品は男か女か」という愉快な質問が来ることすらある。「トイレその後に」は果たして男か女か、「ブルーレットおくだけ」は男か女か。

追伸: ヨーロッパの多くの言語の源流のひとつとなっている古代ギリシャ語の時点で、既にジェンダーがびしばしにあるのだそうだ。それじゃあ仕方がない。今は男女平等の観点からヨーロッパでもジェンダー表現を減らそうという動きがあるらしい（英語でもchairman -> chairpersonとか言い換えようとしている）けど、道は遠い。

追伸: 中国語にもうっすらジェンダーがあるらしい。「他」は三人称の男、「她」は三人称の女で、発音はまったく一緒。

法則4: コストはプレースホルダの数に比例する

今更だけど、このように文章の途中に埋め込まれる変数的なものを「プレースホルダ」(placeholder)と言う。ここまでの説明でおおよそおわかりいただいたとおり、プレースホルダは使えば使うほど多言語的な困難とコストを増大させる。

しかも厄介なことに、翻訳に出されるとき、プレースホルダの前後の言葉が別々にぶった切られてしまうことが多い。

[だるま] さんは [2] 回ころんだ

こういうプレースホルダを無邪気に使った UI を見てぞっとするようになったら合格。これが翻訳に出されるとき、たとえば以下のようにプレースホルダのところでぶった切られてしまうことが多い。

原文	訳文
さんは
回ころんだ

こんな切れっ端だらけの表だけ見せられて訳文を入れてくれと言われて、いったい何人の翻訳者が元のプレースホルダ入り文章を想像できるだろう。当然、前述の数体系やジェンダーに対応できるはずもない。そもそも翻訳した時に地の文やプレースホルダの順序が入れ替わることなど普通にある(下は無理やりな例だけど)。

[だるま] さんは [2] 回ころんだ
[2] times [Darma] rolls

少なくともこれだけは言える: 切れっ端になった言葉を翻訳させれば、後で組み立てたときに破綻する。以下が典型的な例。

To:
↓
「開始時間:」か?「宛先メールアドレス:」か?それとも別の何かか?

あとこんなのも。

せめて、実際のUIのスクリーンショットは必ず添えてあげること。そしてすべてのUI文字列には可能な限り詳しい説明(種類、機能、目的、プレースホルダに何が入るのかなど)を付けること。翻訳者には原文の切れっ端だけ渡しとけば全部よしなにやってくれると思ってはいけない。

なおUIの「種類」とは、「メニュー項目」「チェックボックス項目」「ラジオボタン」「警告文」「ウィンドウタイトル」「ボタン名」みたいな種別を指す。これも翻訳のために重要な情報。情報を提供しない者は死刑ですよまったく。

勝利のコツは翻訳者への指示を「クイズにしない」こと。人によって解釈がぶれることのないようにする。小学生の女の子相手に根気よく説明するぐらいの気持ちで、誰が読んでも確実に理解が一致するように書くこと。何十種類もの言語を扱うとき、指示にあいまいさが少しでもあれば大きな傷になる。

多言語の翻訳者相手に「このぐらいわかるだろう」という期待は一切持ってはならない。「説明していないことは絶対にやってもらえない」のだ。そしてそれが普通だ。

もうひとつ勝利のコツは「言葉よりもスクリーンショット」。100の言葉より1枚のスクショとよく言われるが、多言語相手ではこれはマストと言ってよい。指示をだらだら書いていたら、多くの言語ではまずまともに読んでもらえない。スクショを活用しまくってポイントを赤枠で囲み、確実に指示が行き渡るようにすること。指示書が5ページを越えたら読み飛ばされる危険が一気に増大する。

以上からわかるように、UIの翻訳は逆説的に「短いものほど難しく、時間がかかる」。これを助けるには必要かつ的確な情報(特にスクショ)を提供すること。それ以外の銀の弾丸も魔法の杖もない。

ではどうすればいいのか? コロンだ、コロンを使うのだ!

プレースホルダを扱ううえで、実は(知っている限り)ほぼどんな言語でも通用する黄金のパターンがひとつだけある([]はボックスを表す)。

Unit: [1]
Unit: [1.0]
Unit: [0]
Unit: [-1.0]

おお、美しい。どんな数字が来ようともびくともしない。言葉にいささかの変更も必要ない。

The number of users: 1
The number of users: 10
The number of users: 100

ここでは英語で書いたけど、フランス語だろうとロシア語だろうとフィンランド語だろうと、このようにコロンに続けてプレースホルダを置くパターンを厳守すれば、単数複数にもジェンダーにも影響を受けることなく翻訳でき、しかもコロンのおかげで意味も明確になる。コロン万歳。

転んだひと: [だるま]
転んだ回数: [1]

唯一、アラビア語やヘブライ語のように右から左に書く言語は、さすがにレイアウトを右から左へと変えないといけない。しかし上のコロンの法則は変わらない(と思う)。

原文	訳文
転んだ人:
転んだ回数:

スクショと詳しい説明とともにこういう原文を渡してあげれば、現地の翻訳者から「お、こいつはわかってるねぇ」と一目置かれることは請け合い。ところで、コロンだと転んだを掛け言葉にしておいたのをどなたかお気付きになりましたでしょうか。

幸い、昨今の Web フォームやモバイル UI では、コロンとの親和性の高いこのような中央揃えのUIが使われることが多くなってきている。このような表レイアウトになっていれば最終的にコロンはなくても済むけど、意味上はあった方がよい。

この種の中央揃えUIスタイルはおそらくiOSの設定画面から始まったように思うけど、たぶん偶然ではない気がする。想像するしかないけれど、Appleは最初から多言語コンシャスなUIとしてこうした中央揃えUIを採用したのではないか。AppleはOS 9以前の昔から多言語化用にリソースフォークを採用するなど多言語に積極的だったので。

もちろん中央揃えUIスタイルだけで何もかも解決するというわけではないけど、プレースホルダをカジュアルに文章に埋め込んだバッドUIを徹底的に避け、コロンでプレースホルダを導く中央揃えUIを利用することにはこのようなメリットがあるということを言いたかった。そっけないといえばそっけないけれど。

翻訳後には表示テストを行うこと

翻訳が終わった後、UI に訳語を流し込んでもそれで終わりではない。その画面を必ず翻訳者に見せて修正を行う必要がある。これを表示テスト (Visual test) と言う。

たとえどれほど用意周到に翻訳を進めても、実際の UI に流し込んでみると必ず訳語の修正がどこかで必要になるし、場合によってはソフトウェア自体のバグも見つかる。言語ごとの表示テストを行わないソフトウェアは必ずや残念な結果になるだろう。

もちろん表示テストにもさまざまな準備が必要になる。Webアプリやスマホアプリであれば画面を表示するための操作法を翻訳者に渡す必要がある。量が少なければスクショを渡すという手もある。

当たり前だけど、そのためには表示テストの料金も翻訳者に払う必要がある。ただでやってもらおうとすると商法違反になる。

翻訳にかかるお金をケチるべからず

今はGoogle翻訳を始めとして何となく翻訳できるツールが山ほどある。これで済むならいいじゃんと思うなら思えばいい。

エンジニアにわかりやすく書くと、こうした機械翻訳の品質は、Excelの操作レコーディングで生成されたVBAと比べてもはるかに劣る。そんなにダメなのかとお疑いの方は、ゲーム翻訳地獄道をお読みいただきたい。

無料で使える機械翻訳の最大の弱点は、分野や製品といったコンテキストを指定できないために、どうやっても中途半端な訳にしかならないことだ。多言語化するとどんな雰囲気になるかをちょっと試してみるのに使うのが関の山だったりする。

さらに、機械翻訳では「not」を取りこぼして、意味がまったく逆さになってしまうことなどもざらにある。意味が逆さになると苦笑ではすまない。

どんな自然言語であっても、否定表現は非常に注意深く解釈する必要がある。否定表現は「どこからどこまでを否定するか」というスコープがあいまいになりやすい（部分否定）からだ。

lispみたいにかっこで徹底的に囲めばどうにかなるかもしれないけれど。詳しくは知らないけど、一部の論理学ではこれを正確に表そうとするために「（〜である）ではない」みたいな大変うっとうしい表現を使うことがあるらしい。

英語でお馴染みの落とし穴表現: 「You can't win them all.」は「まったく勝てない」ではなく「欲しいものをすべて手に入れられるわけではない（=もういいじゃん、いい加減あきらめろよ、となぐさめるときなどに言う）」。

なお昨今の機械翻訳はこの反省から、分野や製品を限定し、かつディープラーニングを始めとする機械学習の成果を投入して品質を上げようとしている。こうすることで確かにある程度の品質向上は期待できないわけではないのだけど、当然ながらそんな生データも学習済みデータもタダでは手に入らない。相当の額を請求されると思っておくべき。

それでいて、機械翻訳の品質は結局元となるデータの品質以上になることは決してない。そして出力結果である訳文と原文を比較して正確に評価できるのは、結局プロの翻訳家しかいない。

分野と製品を限定し、プロの翻訳家が本気で機械学習のデータを育成するようになるまでは、実際にはものにならないだろう。

余談: データベースの照合順序について

日本語アプリしか作っていないと、データベースの照合順序のような設定が何のためにあるのかよくわからなかったりする。

あれは主に、ドイツ語やフランス語など、いわゆるアクサン・ウムラウト付きの文字がある言語で、アクサンやウムラウトがあってなくても同じように検索できるようにしたいという要請から来ている(はず)。日本語のカタカナ/ひらがなを区別するしないの方があと付けのはず。

Anderung
Änderung

上の語で検索しても下がひっかかるようにしたいということ。もちろん大文字小文字を区別する/しないも指定したいだろう。

気を付けないといけないのは、この照合順序はテーブル(下手するとデータベース全体)の作成時にしか設定できなかったりすることがあるらしいことだ。詳しくは知らないけど、おそらくデータベース製品によってこのあたりはいろいろ違うはずなので各自で調べていただきたい。

たとえば、日本語のことだけ考えて作ったデータベースのテーブルを多言語でも使用しようとすると、ヨーロッパ言語がアクサンなしで検索できないことが判明し、対応するためにはデータベースを作り直してインポートしなければならず(あるいはインデックス設定を変更して再作成)、そうしたら今度は同じテーブルに入っている日本語でカタカナとひらがなを区別できなくなった、などというシナリオが考えられる。

アプリケーションの多言語化を見据えるなら、データベースを作成するときの設定にも気を付けたい。なお、ベトナム語のアクサンの種類の多さはやばい。

訳語の使い回し

Ruby on Rails の i18n のように、各国語をYAMLなどの形式でパラレルに持つことができるようになって、多言語化が多少やりやすくなっている。昨今はCLDRのような仕組みも提案されているらしい。
しかし、多言語周りをこれらのインフラにもろもろ任せきりにするのは大変危険。上述の注意点や各言語ごとの特性をすべて認識したうえで、それらの使用を支援してもらう形にするのがよい。縁なき衆生を救うためのものではない。

ここでひとつ注意。UI に使う言葉はプログラム側で使い回さないこと。訳し分けが必要になるかもしれないからだ。

典型的な例は「Update」の訳。

Update
↓
「更新」か?「更新する」か?「更新プログラム」か?「新着情報」か？

UI で同じ言葉が10回出てきたら、YAMLにも10個のエントリーを置くこと。YAMLに1個だけ置いてそれを使いまわしたりすると、たぶん多言語化したときに怒り出す言語が出てくる。

もちろん、メッセージのように完結した文(センテンス)であれば使い回せることもあるかもしれないけれど、使い回すなら文ではなくパラグラフ(段落)単位にしておく方が安全。うんと短いメッセージ(例: エラーが発生しました)がいつジェンダーや単数複数の影響を受けないとも限らない。

そもそも、「バリデーションエラーが発生しました。」みたいなエラーメッセージを大量にこしらえるより、上述のように「エラーが発生しました: バリデーション」とコロンを使って後ろをプレースホルダにすれば、メッセージの種類が激減し、より安全に翻訳コストを下げられる。

ただし、プレースホルダに使われる側の言葉を翻訳に出すときは「これがプレースホルダ用の言葉であること」「それがどのメッセージで使われるのか」という説明を必ず書いておくこと。さもないとどんなふうに訳されるか予測不能になる。

繰り返す。翻訳者に原文だけ渡せば適切な訳語をもらえると思うな。情報だ。情報が必要なのだ。

まさかそんな手が！「多言語化しない」という選択肢。

楽器を演奏する人なら、シンセサイザー、エフェクターをはじめとする各種電子機器の表示が最初から英語になっていることにお気付きかもしれない。

そう、楽器業界では、日本で作るときからすべて英語表記にするのが当たり前になっている。そしてヨーロッパ発の電子機器もほぼそうなっている。エフェクトの名前も全部英語のまま（おそらく）世界中どこでも通用している。

むしろ、下手に多言語化するとかえってユーザーが混乱するし、楽器の貸し借りで途方もない不便が生じる。

大昔のゲーセンのアーケードゲームも、ほとんどが英語表記のみで作られていた。昔は解像度が荒くて日本語など表示できなかったという事情もあるし、多言語化する金もなければそもそもそういう発想がなかったりした。

イケアのマニュアルみたいに、文字をまったく使わないことで翻訳費用を完全に浮かすという手もある。その手が通じないものの方が多いだろうけど。

追伸: 本当かどうか知らないけれど、中近東ではシンセサイザーの外装を金ピカにしないと売れないらしいとの記事を昔どこかで見かけた。

ソート順

言うまでもなく、ソートは対象となる自然言語に強く影響される。

英語のソートでくそ面倒なのは、フレーズ冒頭の「a」や「the」などの冠詞を除外しないといけない場合だったりする。辞書や、論文の参考文献なんかで、ABC順に並べるために冠詞をよけてリストアップしているのをご覧になった人も多いだろう。でないと、ほとんどのエントリがAとTのところに集中してしまう。

詳しくは知らないけど、他の言語ではもっと凄い目に遭う可能性が十分考えられる。

そもそも、中国語のソート順って何順なんだろうか。考えるだけでも恐ろしい。

RTL言語

ヘブライ語やアラビア語など、右から左に書く言語はRTL（Right to Left）と呼ばれる。
詳しくはhttp://d.hatena.ne.jp/fkm/20131118/p1をどうぞ。

当然ながら、こうした言語にも製品名などで英語やアラビア数字（←アラビア文字の数字にあらず）が交じるのだけど、これらは英語と同じ順序で表示される。

英語交じりのアラビア語テキストを、秀丸などの開発用エディタで開いてカーソルを走らせてみるとわかるけど、右矢印キーを押すとカーソルが左に走り、英語のところだけ突然ジャンプして右に走り、英語が終わるとまたジャンプして左に走る、という非常に気味の悪い動きをする。

なおGoogle翻訳などではもっとインテリジェントな動作になっていて、英語交じりのアラビア語でも矢印キーは常にその方向に動くよう最適化されている。ただしDeleteキーはアラビア語部分ではカーソルの「右を削除する」ので死ぬほどびっくりするだろう。でもこれは仕方がない気がする。

ついでながら、アラビア文字そのものはアルファベットの一種（むしろラテン・アルファベットの先祖という方が近い）でしかないので、アラビア文字=アラビア語では全然ない。アラビア文字で表される言語は、ペルシャ語などいろいろある。アラビア語に翻訳されても、アラビア文字圏全体で通じるはずなどない。

ついでながら（裏はとってないけど）、イスラム文化圏では「アッラー」に相当するアラビア文字（下）に「似ている」デザインは、それだけで不敬とされると聞いたことがある。

الله

おまけ

http://validator.w3.org/i18n-checker/ はW3C公式の国際化チェッカー。自分のサイトがどのぐらい国際化コンシャスなのかを手っ取り早くチェックできる。

エンジニア・Webデザイナー必読: アプリケーションを国際化・多言語展開する前に知っておくべきこと

概要