意味は合っているのにズレている？ WebページやUIの翻訳で気をつけたい問題とその解決策

というわけでこの記事では、原文コンテンツの趣旨からズレていることがひと目でわかってしまう訳の一例として、レイアウトの目的からズレている翻訳を取り上げ、その問題点と解決策をご紹介します。

Webページやスライド資料、UIなどのコンテンツを作成する場合、「読者の目にどう映るか」を考えたレイアウト調整は必須事項です。そのため翻訳においても、「見出しは見出しらしく、UIはUIらしく、本文は本文らしく翻訳する」ことは必要不可欠。つまり、「この原文が表示される場所は見出し？本文？UIボタン？メッセージ？」というように、レイアウトの目的を意識することは欠かせません。

しかし、いざ翻訳されたコンテンツを元コンテンツどおりのレイアウトで配置してみると、「意味はわかるけれど、なにかズレている」状態になることもしばしば。具体的には、次のようなものがあります。

• • Webページのタイトルなのに、「～です」「～ました」のように、地の文と同様に訳されている
  • Webページの見出しなのに、長々しく一息で読めない日本語に訳されている
  • UIボタンのラベルなのに、翻訳後のラベルを読んでも何のボタンかわからない
  • UIボタンのラベルの表現がなにか重々しい

こうした具体例について、実在の文章を改変したものを引き合いにしてそれぞれの問題点を整理した後、原因と解決策をご説明します。

なお、具体例は抜きにして「レイアウトの目的に合っている翻訳」を実現するための解決策が知りたいという方は、「レイアウトの目的からズレている翻訳をなくすにはどうすればよい？」まで進んでいただいてかまいません。

あるツールの「データの送信方法を解説した記事」のタイトルが、次のように訳されていたケース。

原文：Send Data

訳文：データを送信します

タイトルはコンテンツの顔であり、その目的は、「読者にコンテンツの内容を想像してもらい、読む気を引き出すこと」。とはいえ、実は文体にも注意が必要です。日本語では、文章の想定読者や配置場所に応じて、「ですます調」、「である調」、「体言止め」などを使い分けるもの。特にタイトルでは、「である調」あるいは「体言止め」が使われるケースが一般的です。

もし、解説記事やマニュアルで項目のタイトルが「～します」となっていたら、ちょっとびっくり…というよりも、「ちゃんと推敲されたページなのかな？」と不安に思われるかもしれません。

あるソフトウェアのWebページで、ソフトウェアのダウンロードを勧める見出し。

原文：Get the most efficient DevOps tool!

訳文：他に類を見ないほど効率性に優れたDevOps向けツールをぜひご活用ください！

見出しの目的はややタイトルと似ていますが、「なんらかのメッセージを簡潔に伝えること」。レイアウトのスペースの観点からも、視認性という観点からも、「ひと目で全文が目に入る」ことが理想です。この訳文は原文の倍近い長さになってしまっているので、元のスペースに収まることはないでしょう。その結果、訳文がスペースをはみ出して表示され、全体のレイアウトがガタガタになってしまうかもしれません。

とは言え、翻訳者は「原文の意味」を誤解なく伝えようとさまざまな思考を巡らせるものです。レイアウトの制限があるとわかりきって思えるような場合でも、特に要望がなければ「原文の意味を伝えよう」とていねいに（つまりは冗長に）表現してしまうケースも少なくありません。

そのため、翻訳依頼時には、スペースや文字数などの制限事項を明示すること（SNSへの投稿文なら「規定の文字数」、Webページ上のコンテンツなら「何行以内におさまるようにして欲しい」、など）をおすすめします。

昨今おなじみのCookieの利用に関する丁寧なメッセージに並べて表示する、同意ボタンのUIラベル。

原文：I got it!

訳文：なるほど！

アプリケーションやWebページになくてはならないUI（ユーザーインターフェース）。こうしたUI要素にラベルをつける目的は、「UIを操作すると何がおきるのか？」をユーザーに知らせることにほかなりません。

「Cookieの利用に同意してください」というメッセージの横に「わかった！」というボタンがあっても、ボタンの意味が「利用に同意する」ことだとユーザーに伝わるかどうかは怪しいところです。もしかすると、「わけのわからないボタンがあるから、このWebサイトを見るのをやめよう」と敬遠され、Webサイトだけでなく会社そのものに対する信頼性も失ってしまうかもしれません。

タイムゾーン変更ボタンという、必要な人だけがクリックするUIにつけられていたラベルの例。

原文：Change your timezone

訳文：タイムゾーンを変更してください

UIラベルの目的は、先述のとおり「このUIを押したらどうなるのか？」をユーザーに知らせること。文体は「体言止め」または「である調」が一般的で、データの送信ボタンに付けるラベルなら「送信」とだけ書くことがふつうです。

ただ、この例のように「別に必要な人だけが使うUI」に「～してください」というラベルをつけるのは、目的からズレていると言わざるをえません。「タイムゾーンを変えないとまずいことになるのかも…？」と思ってクリックするユーザーが殺到してしまうかもしれません。

「レイアウトの目的からズレている翻訳」の具体例を確認したところで、ここからはその原因を考えていきます。具体例ごとに別々の原因があるようにも思えますが、実は根本的な原因は共通しています。その原因とは…

1. 1. 機械翻訳をそのまま使用した
   2. ソースファイル（原文ファイル、もしくは原文のレイアウトがわかる資料）がない状態で翻訳した
   3. 翻訳メモリに記録されている訳文をそのまま使用した

それぞれの原因と個別の解決策を以下に示します。

最近成長著しい機械翻訳。そのスピードは人間を大きく上回り、プロ翻訳者並みの品質を実現できるとされています。しかし現状では、「機械翻訳をそのまま公開できる  」ケースはあまりなく、機械翻訳の出力を人間がレビューして調整・修正する「ポストエディット」という作業が欠かせません。

というのも、機械翻訳では「レイアウト」や「文脈」はさほど考慮されないからです。そのため、「タイトルが地の文として訳される」ことも、「妙に重々しく訳される」ことも起こりえます。

原因が「機械翻訳でレイアウトや文脈が考慮されない」ことにある以上、解決策は機械翻訳の出力を確認して調整することです。少なくとも当座の間は、「レイアウトや文脈を考慮できる存在」、つまりは人間の手で訳文をレビューすることをおすすめします。

また、機械翻訳サービスによっては、「翻訳エンジンに正解を教えることでカスタマイズし、適切な訳文が出力される確率を上げることも可能」とされているものもあるようです。ただ、やはりこの場合にも、適切な訳が得られるようになるまでは人間の手が必要です。

最後に、ポストエディットの注意点をひとつ。

ポストエディットでは「機械翻訳をレビューする（ゼロから翻訳するわけではない）」ので、料金は「人間の手による翻訳」よりも割安です。しかし、翻訳エンジンの性能が十分でない場合には、訳文を人間の手でイチから書き起こす事態も起こりえます。

その結果、ポストエディットを導入したのに思ったように翻訳スピードが上がらないというケースも珍しくありません。すでにポストエディットを導入されている方は、定期的にポストエディット前後の訳を比較分析して、人間の手がどれくらい入っているのかを確認することをおすすめします。

ポストエディットで軽微な修正が少し加えられているだけなら、費用節約の面でも時短効果の面でも問題はおそらくないでしょう。しかし、毎回大幅な修正が加えられているようなら、一度機械翻訳ありきの作業フローを見直したほうがよいかもしれません。

機械翻訳でうまくいかないなら人間の手で…とは言うものの、人間による翻訳でもレイアウトからズレている翻訳は生じてしまいます。その一番の原因は、翻訳時点で原文のレイアウトがわかる資料（ソースファイル）がないことです。

翻訳作業では、原文ファイル（Word、PowerPoint、HTMLなどなど…）を翻訳用ファイルに変換し、変換後のファイルを翻訳支援ツールに読み込んで翻訳します。そのため、ソースファイルがない場合、レイアウトがわからない状態で作業することになってしまいます。つまり、「この文章はなんとなくタイトルみたいだな…」や「これは画像の代替テキストだろう」と、翻訳者の推測頼りになるのです。

というわけで、人間の手で「レイアウトに合う翻訳」を実現するには、ソースファイルの存在が絶対に欠かせません（Webページなら原文ページのURL、スライド資料なら原文のスライド一式など）。

ソースファイルのメリットは、「レイアウトからズレた翻訳」がなくなるだけではありません。実際のレイアウトをつかめる資料が手元にあれば、翻訳者は「ここは見出しだから簡潔に訳そう」、「これはUIだから文字数を切り詰めよう」のように工夫を凝らすことができます。その結果、よりコンテンツの趣旨に即した訳文が納品される可能性が高まります。

人間の手で翻訳する場合、一般には前述のように「翻訳支援ツール」というものが使用されます。この翻訳支援ツールを利用するメリットの1つが、「原文と訳文を対応させて記録する」翻訳メモリ（詳しくは当社のこちらの記事をご覧ください）。翻訳メモリに記録されている原文と同じ文章が登場したら、同じく翻訳メモリに記録されている訳文を流し込んで翻訳完了！時短やコスト削減などの効果が見込める便利機能です。

…ところが、そんな翻訳メモリの弱点はなんと言ってもレイアウト。通常の翻訳メモリにレイアウトの情報は入っておらず、「メモリ内に記録されているものと同じ原文が登場したら、対応する訳文を機械的に流し込む」だけ。つまり、過去にタイトル以外の箇所で使われていた訳文がタイトルに再利用される、なんてことも起こりがちです。

このケースの原因は「文脈に合わない訳文が流し込まれる」ことなので、解決策は流し込まれた訳文が文脈に合っているか人間の手で確認することです。

ところが、翻訳会社によっては、「翻訳メモリに記録されているものと同じ原文については、翻訳メモリに記録されている訳文をそのまま流用」という作業体系になっていることも。そのため、翻訳会社に翻訳を依頼される場合には、「翻訳メモリを使用するかどうか」と「翻訳メモリを使用する場合、流し込まれた訳文をチェックするかどうか」を確認しておくほうが安全です。翻訳メモリ頼みでなく、最後に人間の手を加えるようにすれば、満足のいく納品物に仕上がるかもしれません。

「レイアウトからズレた翻訳」、いかがでしたでしょうか。本記事では、「レイアウトからズレた翻訳」の具体例と問題点、およびその解決策についてご説明しました。

翻訳会社に翻訳を依頼した際に、「レイアウトを意識した翻訳が納品されない！」、「翻訳された文言が、調整しないととても公開できたものじゃない！」となるケースは好ましくありません。しかし、上記原因1～3で説明したように、機械翻訳頼みの場合、ソースファイルなしで翻訳を依頼した場合、翻訳メモリにまかせてレビュー工程を省いた場合には、こうしたケースが発生する確率は残念ながら大きくなります。

特に、翻訳者にとってソースファイルなしでの翻訳は、設計図なしで機械を組み立てるようなもの。熟練の翻訳者であっても、ソースファイルなしでは「刺さる」翻訳を生み出すのは至難の業です。

後工程でのレイアウト調整や文言修正にかかる時間や手間を抑えるためにも、ソースファイルの共有と人間の手によるレビュー作業は可能な限り作業フローに組み込んでください。

なお、ソースファイルを共有し人間の手でレビューしているのに、文字数や改行などのレイアウトが考慮されない翻訳が納品されるのであれば、翻訳会社が「原文通りの翻訳」にとらわれている可能性があります。つまり、翻訳の方向性について翻訳会社との間に認識の相違がある状況です。

こうした場合には、翻訳会社からヒアリングを受けた際に、翻訳の成果物に対するイメージを共有することをおすすめします。たとえば、「若者向けにフレンドリーで読みやすいWebページにしたい」、「日本人スタッフが営業でそのまま使える、キャッチーなスライド資料にしたい」、「簡潔ながら、広い層の意識に深く刺さる字幕にしたい」、「専門家から信頼されるような、威厳のあるPDFにしたい」など、ざっくりとした要望でかまいません。

なお、テクノ・プロ・ジャパンでは、原文の翻訳だけでなく、PDFやスライド資料のDTP、字幕の調整、成果物のレイアウトチェックまで、一貫した翻訳業務を承っています。これまでに「レイアウトからズレた翻訳」でお困りの方も、レイアウトにぴったりの刺さる翻訳が欲しいという方も、どうぞお気兼ねなくお問い合わせください。