翻訳した文書が長くなる理由
Chromeに追加 
TABLE OF CONTENTS
翻訳された文書は、内容が増えていなくてもページ数が増えることがあります。単語の長さ、文の構造、改行ルール、フォントのメトリクスが異なれば、同じ意味を表すのに必要なスペースも変わります。
短い答え
翻訳文書が長くなるのは、対象言語のテキストが原文より多くの横方向または縦方向のスペースを占めるときです。これは、翻訳がより多くの文字数を使う、単語が長くなる、行を折り返せる箇所が減る、字形が広くなる、行間が広がるなど、さまざまな理由で起こります。
つまりページ数はレイアウトの結果であり、翻訳品質を測る信頼できる指標ではありません。簡潔な翻訳でもページがもう1ページ必要になることがあり、逆に内容を省いた粗悪な翻訳は短くなることがあります。
最も役立つ計画の原則はシンプルです。レイアウトは動くものと想定する。特に原文がぴったり収まるように設計されている場合はなおさらです。
同じ意味がより多くのスペースを取る理由
短い英語ラベルは大きく膨らむことがある
英語と中国語は、情報を簡潔に表現することがよくあります。そのため、これらの言語からの翻訳は長くなりやすく、特に原文に短いラベルが含まれる場合に顕著だとW3Cは指摘しています。
W3Cのテキスト拡張ガイドラインは、英語をヨーロッパの言語へ翻訳する際の、次のような平均的な計画範囲を示しています。
| 英語原文の長さ | 原文に対する翻訳後の平均的な長さ |
|---|---|
| 10文字まで | 200〜300% |
| 11〜20文字 | 180〜200% |
| 21〜30文字 | 160〜180% |
| 31〜50文字 | 140〜160% |
| 51〜70文字 | 151〜170% |
| 70文字超 | 130% |
これらの数値はレイアウト上の余裕を示すものであり、特定の言語ペアに対する保証ではありません。ここから得られる有用な教訓は、最も短い原文の文字列ほど、比例して大きな安全マージンを必要とすることが多いという点です。2語の表見出しや注記は、段落全体よりも問題を引き起こすことがあります。通常はより小さな枠の中に収まっているためです。
文法は単語の数を変える
言語は同じようには意味をまとめません。ある言語では語形変化で表す考えを、別の言語では冠詞、前置詞、助動詞、説明的なフレーズを使って表す必要があります。語順によって、修飾語や条件が余分な行を生む位置へ移動することもあります。
だからといって、ページ数を保つために翻訳者が原文の構造をそのまま写したり、必要な語を削ったりしてよいわけではありません。翻訳はまず完全で自然であることが優先され、レイアウトはそれに合わせて調整されるべきです。
長い単語は折り返しの選択肢を減らす
W3Cは、英語のフレーズ「Input processing features」の代わりになる複合語の例として、ドイツ語の Eingabeverarbeitungsfunktionen を挙げています。英語のフレーズはスペースの位置で折り返せますが、ドイツ語の複合語は、文書に言語に応じた適切なハイフネーションがなければ、1行のまま（折り返されず）収まってしまう可能性があります。
Unicodeの改行標準は、これが重要である理由を説明しています。ソフトウェアは、使用中の文字と言語に許可された改行機会の中から改行位置を選びます。狭い段組み、表のセル、テキストボックスでは、その機会が限られると、より早く破綻します。
文字数は視覚的な幅と同じではない
翻訳文は文字数が少なくても、より多くのスペースを占めることがあります。W3Cは英語の desktop と日本語の デスクトップ を比較しています。日本語の語は文字数が少ないものの、通常はより大きな横幅を必要とします。
フォント置換によって結果はさらに変わります。代替フォントは元のフォントより幅広だったり背が高かったりして、かつて1行に収まっていた行を2行にしてしまうことがあります。翻訳後のファイルで、はみ出しに加えて字形の欠落、分離した文字、予期しない書体が見られる場合は、翻訳後にフォントが崩れる理由のガイドを使って別々に診断してください。
スクリプトによってはより多くの縦方向のスペースが必要
アラビア語、中国語、デーヴァナーガリー、日本語、韓国語、タイ語、チベット語などのスクリプトは、ラテン文字より背の高い字形や広い行間を必要とすることがあります。そのため、行数が変わらなくても段落が縦方向のスペースを増やすことがあります。
これが、フォントを縮めることがめったに最善の初手にならない理由です。テキストは収まっても、対象スクリプトが読みにくくなったり、記号同士がぶつかったりする可能性があります。
テキスト拡張が文書を壊す箇所
長い本文の段落は通常、折り返しによって自然に流れます。問題は、原文に合わせてサイズを決めた枠に集中します。
| 文書要素 | よくある不具合 | より良い対応 |
|---|---|---|
| 見出し | 行が増えて本文が別ページへ押し出される | 折り返しを許可し、見出しを次の段落と一緒に保つ |
| 表 | 行が伸び、列が狭くなりすぎ、テキストが切れる | 重要な列を広げ、行の伸びを許可するか、ページの向きを変える |
| テキストボックスと注記 | テキストがはみ出すか自動縮小される | ボックスを大きくする。意味を確認したうえでのみ短縮する |
| フォーム | ラベルが入力欄とぶつかる | ラベルを入力欄の上へ移すか、ラベルの幅を広げる |
| ヘッダーとフッター | テキストがページ番号や余白と重なる | 繰り返しテキストを簡素化し、すべてのセクションを確認する |
| キャプションと脚注 | 参照が対象から離れる | 関連する要素を一緒に保ち、ページ割り付けを更新する |
| スライド | 箇条書きが密集するか、読めないほど小さくなる | スライドを分割するか、翻訳前に原文の内容を減らす |
1行の変化がファイル全体に波及することがあります。表が高くなればキャプションが動き、キャプションが動けば改ページが変わり、改ページが変われば目次が変わります。文言がまだ変わり続けている間にページを修復するのではなく、テキストが確定した後に文書全体を見直してください。
翻訳前に原文を整える
1. 手動の改行を削除する
原文の見た目を整えるために挿入された改行は、対象言語に合わないことがほとんどです。実際の段落区切りは残しつつ、通常の文は自動で折り返されるようにします。
2. 狭い枠に広がる余地を与える
翻訳前に表、サイドバー、フォーム、グラフ、テキストボックスを確認します。スペースがある場合に限り余白を増やし、行の伸びを有効にし、重要なテキストには固定高さのボックスを避けます。
3. 段落と見出しのスタイルを使う
スタイルを使えば、全体をまとめて修復できます。翻訳後の見出しに異なる間隔や行の高さが必要なら、すべての見出しを手作業で編集するより、スタイルを1つ変更するほうが安全です。
4. 正しい文書言語を設定する
言語設定は、対応ソフトウェアが綴り、ハイフネーション、改行の挙動を選ぶ助けになります。また、編集ソフトが原文言語のルールを翻訳後のテキストに適用してしまうのを防ぎます。
5. 変更してはいけない用語を保護する
製品名、コード、URL、変数、法的な識別子にマークを付けます。短い原文ラベルに頼るのではなく、略語には文脈を翻訳者に与えてください。短い原文ラベルには、簡潔な対応表現が存在しないことがあります。
6. 編集可能なマスターファイルを保つ
可能であれば、DOCX、PPTX、スプレッドシート、デザインの元データでレイアウトを修復します。Google Cloudの文書翻訳ガイドラインは、結果をPDFへ変換する前にDOCXやPPTXを翻訳することを勧めています。これらの形式は一般にPDFよりレイアウトとスタイルをよく保つためです。PDF固有の準備については、書式を失わずにPDFを翻訳する方法のワークフローに従ってください。
膨らんだ翻訳を損なわずに直す
視覚的な修復が言語の問題を生まないよう、次の順序で進めます。
- 重複した内容がないことを確認する。 見出しの順序、リスト、表、繰り返し段落を原文と比較します。
- 原文言語の改行を削除する。 文字の体裁を変える前に、対象テキストを自然に流れさせる。
- 枠のサイズを変更する。 列を広げ、テキストボックスを深くし、表の行が伸びるようにする。
- 間隔を調整する。 スクリプトを窮屈にせず、過剰な段落間隔や余白を減らす。
- 言語に応じたハイフネーションを適用する。 対象言語と文書スタイルにとって正しい場合にのみ使う。
- ローカルに書き直す。 意味とトーンを保ったまま見出しやラベルを短くするよう、適切なレビュアーに依頼する。
- フォントサイズの縮小は最後に行う。 本文と繰り返し要素の一貫性を保ち、収まるためだけに孤立した箇所を縮めない。
元のページ数を取り戻すために、限定語、例、警告、法的条件を削除しないでください。1ページのフォームや2枚のスライド要約など、固定の制限が必須の場合は、翻訳前にその制限を定義し、翻訳者が与えられたスペースに合わせて書けるようにします。
レイアウトを保つ翻訳ワークフローを使う
テキストを単純な翻訳ツールへコピーすると、レイアウトが依存している表、スタイル、テキストフレーム、関連性が失われます。編集可能な文書をアップロードすれば、文書を理解するツールが保てる構造をより多く得られます。
OpenL Doc Translator は、PDF、DOCX、PPTX、XLSX、EPUB、SRT などの形式に対応しています。公式ページには、フォント、色、表、ページレイアウトを保ち、翻訳版とバイリンガル版の両方を提供すると記載されています。バイリンガルファイルは、レイアウトの変化が正当なテキスト拡張によるものか、内容の欠落や重複によるものかを確認するのに役立ちます。
書式の保持は手作業での再構築を減らしますが、すべての言語を同じスペースに収めることはできません。最後に、バイリンガル文書レビューチェックリストを使って、バイリンガルとレイアウトのレビューを別途行ってください。はみ出し、表の伸び、改ページ、ヘッダー、フッター、目次、そして最終的に書き出したPDFを確認します。
納品前の最終確認
- テキストが切れたり、隠れたり、重なったり、承認したサイズを下回るまで自動縮小されたりしていない。
- 表が行と列の関係を保ち、読める状態になっている。
- 見出しが、それが導く内容と一緒に保たれている。
- キャプション、脚注、注記、ページ参照が正しい場所を指している。
- フォントが対象言語のすべての文字とスタイルに対応している。
- 目次と相互参照が更新されている。
- 編集可能なファイルと書き出したPDFの両方を確認済みである。
- ファイルを収めるために内容が失われていないことを、バイリンガル比較で確認している。
翻訳文書が長くなるのは、通常、言語とレイアウトが相互作用している証拠であり、何かが失敗した証拠ではありません。拡張のための余地を計画し、文書構造を保ち、翻訳が完了してからレイアウトを調整しましょう。
Sources
- W3C: Text size in translation - Explains systematic text expansion, compound words, character width, line height, and flexible-layout planning.
- Unicode Standard Annex #14: Unicode Line Breaking Algorithm - Defines line-break opportunities, line fitting, and language-sensitive hyphenation considerations.
- Google Cloud: Translate documents - Explains document-format support, layout preservation, and why DOCX or PPTX sources generally retain layout better than PDF.
- OpenL Doc Translator - Lists supported formats, layout-preservation features, and bilingual review output.
