プロダクトを多言語展開するときの７つのヒント
こんにちは。トークアンドデザイン代表の今西(@no_imanishi)です。
独立以前サラリーマン時代に、色々な立場で、多言語対応に関わってきたんです。
８言語（くらい）対応のデジカメ - UIデザイナーとして
３言語対応のOEMカーナビ - UIデザイナーとして
３０言語くらい対応のコーポレートサイトのCMS立ち上げ、運営 - 推進リーダーとして
会社案内・環境・CSR報告書（冊子）を３言語で作り、その抜粋を10言語くらいでwebに展開する。- 翻訳PMとして
…みたいな感じです。私自身は英語も覚束ないんですけれど、翻訳会社さん（一時、language service provider / LSPってよく言ってましたけど、最近あまり聞かないですね。止めたのかな？）と一緒になって、ヨレヨレになって頑張って、ちょっとはまとまった経験になっている気がするので、まとめてみたいと思います。
立場としては、予算と時間を預かって仕事の回し方を考えるPM的なポジションでのお話しと思っていただければと思います。（翻訳は技術側の実装にも色々ありますがそちらではなく…）
1.仕事のスコープ認識を正す
多言語化というと、テキストを置き換える仕事というイメージをしがちですが、それはもう誤りです。言語が変われば波及する箇所はすごく多いです。
単位・度量衡
テキストの長短に起因するレイアウト変更（言語によって、テキスト長は全然違う）
文化に起因するレイアウト変更（日本で画面表示にあんまりファーストネーム使わないよね…など）
フォント、文字サイズ、行間など
諸々の事情による特定国向けのコンテンツの追加・削除・改変
などなどあります。ゆえに、原文を翻訳会社に渡して、戻ってきたものを流し込む仕事だと思うと、仕事の漏れの多さで破綻します。翻訳会社に丸投げはできない仕事ということでもあり、PMなりがきめ細かくデザイナーやエンジニアに必要な仕事を渡していかないと全然終わりません。
2.チェックできる体制づくりを頑張る
多言語化という仕事の辛いところの一つは、自分でチェックできない…というところだと思います。どんな外国語の得意な人でも欧州20言語（※主要なところでそれくらい）を全てカバーしたりできる訳ないですし、タイ語とかアラビア語とかは素人では文字の違いを判別することすらままなりません。
なので、翻訳会社さんの仕事は信じたいにしても、誰かにチェックをお願いする必要があり、その体制を作るのは結構大変です。多言語化プロジェクトの存在するところでは、きっと現地法人なり現地代理店なりがあって、そこにお願いするというのがポピュラーだと思いますが、場合によってはいい加減な扱いを受けることもあるし、チェックしてる人がどれだけ気の利いた人かによって、フィードバック内容が全然変わってきてしまったりもします。
言葉の問題だけであっても、人によって気の利き方は違いますし（日本語母語の人の中でも、日本語に翻訳されたテキストを見てどれだけちゃんとしたフィードバックができるか…と考えると、人によるばらつきがどれだけ発生しうるか、想像がつくかと思います）、先のお話しした様にレイアウトやフォントや文字組みといった領域まで含んでくると、その適切さを判断するのは結構高度なお仕事になります。
さらに、レイアウトされた状態でないとちゃんと判断できないというケースは往々にしてあるのですが（UIに使う短いメニュー名とか特にそうです）、レイアウトされた状態を素早く準備するのが難しいケースもあり、エンジニアなりの協力を得つつ、素早く翻訳確認できる材料を用意できる仕組み作りに力を注ぐ必要があります。
3.継続することが大事
ハードウェアプロダクトにせよ、サイトにせよ、アプリにせよ、一度作ったものには更新・改良が入ります。多言語化されているものは、その差分を翻訳プロセスに通す必要がでます。これを継続するのは、相当な体力を要する仕事です。
なので、必要な人員なり予算なりをちゃんと持っておかないと、ソース言語版だけは更新が入っているけど、その他の言語では放ったらかし…みたいなことになりがちです。
「多言語化は金がかかる」というのは肝に銘じていただきたいところです。
4.ソース言語側をちゃんと固める
翻訳元になる言語をソース言語と言いますが、ソース言語版でちゃんと内容が固まらないまま翻訳プロセスを走らせると地獄が起きます。
翻訳プロセス中に、「原文に一部修正が入りました…」というのはあるあるではあるのですが、まじで管理力問われます。あっという間に、何がどこまで反映されたのか、分からなくなります。サイクル管理が大事です。
5.用語集・翻訳メモリー・スタイルガイド
多言語化の規模や頻度が大きくなると、翻訳会社さんと「用語集」「翻訳メモリー」「スタイルガイド」という話が出てきます。
用語集：その会社や分野での専門用語をどう訳すかをあらかじめ決めておくものです。訳語案は翻訳会社さんで出してもらえるにしても、そもそもの対象語は依頼側が挙げないといけませんし、訳語の確定は依頼側の仕事になるので、先に挙げたチェックの問題になります。私も、日-英-中くらいまではちゃんとしてた（周りに信頼できる人がいた）と思いますが、欧州言語とかになると、かなりチェック品質が苦しくなってたというのが正直な思いです。
翻訳メモリー：ちょっと分かりづらい話なのですが、翻訳履歴データベースという理解が一番分かりやすいかと思います。会社情報の様な年次更新のものだと、前年度と同じ内容の部分も少なく無いのですが、差分を選び出してそこだけ翻訳会社に渡そうなんてすると一生終わらない（差分比較は簡単でも訳したものを戻すのが大変）ので、全文丸ごとを翻訳メモリーに照合して、前年と同じところと一致するところは翻訳メモリーに記録された訳文をそのまま出力、一致しない部分は翻訳者に渡す、部分的に異なる（数字だけ違うとか）ものは不一致部分がわかる様にして翻訳者に渡す、という区分けをオートマチックにやります。
大規模なものになると、翻訳メモリーが無いとやってられませんが、注意点は、最終校正段階での細かな調整等をちゃんと翻訳メモリーに反映しておかないと、そのメモリーを次回使って出力したときに「去年最終調整した内容が反映されてない！先祖返りだ！」と批判をあびます。（皆さん先祖返りを見つけた時ってほんと容赦ないんですよね……）
きめ細かく漏れなく翻訳メモリーのメンテナンスをしておくのがとても大切です。
スタイルガイド：日本語の書き方にも色々とスタイルがある（「他/ほか」「段落頭の字下げをする/しない」とか）様に、各言語ごとに色々な変数があるので、それを定めておくものです。
どっかのありものをそのまま適用することもできなくはないでしょうが、基本的に会社ごとに「うちのポリシー！」を作ることになるので、結構大変です（そのスタイルのチェック誰がするのよ…と考えるとその大変さが伝わるかと）。私はやりかけて頓挫しました。
翻訳は裾野の広い分野だけに、ノウハウもあれば、いろんなテクノロジー活用も活発ですが、依頼側がちゃんと理解しないと全然機能しないので、依頼側の理解度、とても大切です。
6.言語ごとのあるあるを知っておく
各言語ごとに、色々とハマりがちな落とし穴があります。それはやっぱり知っておく必要があります。
伸びる言語・縮む言語
同一内容を翻訳したときに、テキスト長の長さはかなり違います。
一番短くなるのは中国語で、その後、日本語→英語→その他いろんな言語→
ギリシャ語・ロシア語という感じで長くなります。
短い← 中国語 - 日本語 - 英語 - 色々な言語 - ギリシャ語・ロシア語 →長い
ギリシャ語・ロシア語はほんと長くなるので、要注意です。あと、ドイツ語も一単語がすごく長いケースがあって（Gebrauchtwagenbörse/中古車市場、Finanzierungsmöglichkeiten/購入資金調達方法、とか…※ドイツ語は単語をくっつけて単語を作れるルールがある）、アプリとかだとはみ出し要注意です。
文字サイズや段落の設定
日本語や中国語は字面が大きいのに対し、アルファベットは小文字があって字面が小さいので、同じフォントサイズ設定だと小さく見えます。
逆に、行間は同じ行間値だと小文字がある分、アルファベットの方が広がって見えます。言語ごとにこうした調整は必須です。
右から左に進む言語をやるときは覚悟を
有名な話ではありますが、右から左に進む言語（アラビア語など、RTL言語といいます）をやる場合は、レイアウト自体が全て左右反転です。ウェブサイトにロゴが左上にあるのは定番ですが、RTL言語の場合は右上になります。
とにかくいろんな素材が逆向きになるので、作り直し大量発生必至です。
単位・度量衡
ヤード・ポンドとかですね。同じ英語でも仕向先によって、メートル法になるかヤード・ポンド法になるか、プロダクトに性質と現地ニーズで相談となるでしょう。（ので、言語×仕向先でさらに管理数が増える…）
あと、数値のカンマの使い方とかも違いますね。国によって
123,456.78とする場合と（日本はこうしますよね）
123.456,78とする場合
…がある（あとカンマの代わりにスペースの国もあるのかな）ので、要注意です。
面白いところでは、タイでは年の表し方に仏暦（仏滅紀元）というのがあって、普通に使われるポピュラーなものみたいです。西暦2022年は仏暦2565年だそうです。（タイ語翻訳で大体みんな一回はびっくりしますね。）
SEO
ちょっと毛色が違いますが、例えばスペイン語のサイトがスペイン本国用とメキシコ用に2つあったりすると、メキシコでの検索結果にスペイン用ページが出てきちゃったりするので、同一言語で仕向先違いがある場合は要設定です。（詳しくはGoogleのドキュメント読んでくださいですけど、hreflangとか…）
7.どこまで本国で抱えるべきか腹を割る
多言語化は、現地サイドからあの言語もこの言語ももっと対応してほしいという要望が出続ける世界です。特に欧州EU圏内は強い要求がでます。本国側としては、つい主要5言語以外の国は英語で許してよとか言ってしまうのですが、一緒に仕事をしていた日本語ペラペラのフランス人曰く、
仲が悪いから、国が別で、言語が違うのです。
…なんだそうです。確かに、すぐ近くだからって日本と韓国を一つの言語のマテリアルでまかなってくださいと言われたら、大揉めに揉めるでしょうから、気持ちは理解できます。
一方で多言語化は金のかかる世界です。また、現地と本国の綱引きが起きやすく、本国側は「現地は信用できない。何を作っているのか分からなくなるのは困るから本国で管理する。」と言ったり、現地は「本国の作った多言語マテリアルはいつも翻訳がおかしいから、予算は本国もちで、あとはこっちで勝手にやる。」と言ったり、わがままが交錯します。
本国と現地との予算配分や人員リソース等々、変数はいくつかあるので、とにかく腹を割ることが大事かなと思います。そして、腹を割るのに英語と社内を動かす力が要ります。私はここが足りなくて、詰めが甘くなってしまったこと多いなぁと今でも思います。
おわりに
最近は「AIでサクッと翻訳！言語の壁は取り払われた！」という気楽な話もあるのですが、実際のプロダクトの多言語化はとても地道な作業と管理の積み重ねです。もし同じ様な沼にハマっている人がいれば、エールを送りたいと思います（お疲れ様！）。
最後までお読みいただき、ありがとうございました。
弊社トークアンドデザインでは、新規商品・新規事業に関わるプランニングの支援・インダストリアルデザイン・UIデザインの制作を行っています。
詳細はこちら↓から。
この記事が気に入ったらサポートをしてみませんか？