文書翻訳で表はどう変わるのか？
TABLE OF CONTENTS
すべての行と列が残っていても、翻訳後の表が正しく機能するとは限りません。長くなった文章、異なる改行位置、右から左に書く内容、ローカライズされた数字、失われた見出しのメタデータにより、見た目は整った表が誤解を招く情報に変わることがあります。
表を翻訳すると何が変わるのか？
文書内の表には3つの層があり、それぞれを個別に確認する必要があります。
| 層 | 期待される結果 | 起こり得る問題 |
|---|---|---|
| 内容 | 見出し、ラベル、注記、本文が翻訳される | テキストの欠落、重複、誤訳、原文のままの残存 |
| 構造 | 行、列、結合セル、見出しの関係が維持される | 変換によるセルの分割、結合範囲の変更、構造メタデータの消失 |
| 表示 | 罫線、塗りつぶし、フォント、幅、配置が実用的な状態で残る | テキストの折り返し、切れ、縮小、重なり、別ページへの押し出し |
翻訳時に表を一から作り直すべきではありません。文書形式に対応したワークフローなら構造とスタイルを保持できますが、保持されるからといって、翻訳後も各セルが同じスペースに収まるとは限りません。
W3C は、翻訳文の長さは変わりやすいため、狭い固定幅の領域ではなく柔軟なレイアウトを推奨しています。短い見出しほど狭いセルに配置されがちな表では、特に重要です。W3C の例では、ドイツ語の複合語は同等の英語表現より自然な改行位置が少ない場合があり、非ラテン文字の一部では文字幅や行の高さがより必要になることも示されています。
こうした影響について詳しくは、翻訳後に文書が長くなる理由をご覧ください。
翻訳後も通常保持される表の要素
編集可能な元ファイルを形式対応ツールで翻訳すると、次の要素が出力に引き継がれる場合があります。ただし、確認せずに正しいと判断してはいけません。
| 要素 | 期待される結果 | 確認事項 |
|---|---|---|
| 行と列 | 同じ論理グリッド | 行、列、セルの欠落や重複はないか？ |
| 罫線と塗りつぶし | 同じ視覚的グループ | 色と罫線は意図した分類を伝えているか？ |
| 結合セル | 行または列にまたがる同じ範囲 | 各見出しは正しいデータを覆っているか？ |
| 見出し行 | 同じラベルと繰り返し動作 | 見出しは正しい列に対応し、改ページ後も繰り返されるか？ |
| セルのスタイル | 同じフォント、強調、余白、配置 | フォント置換や自動調整で読みにくくなっていないか？ |
| 数値と数式 | 同じ基礎値とロジック | 符号、区切り文字、単位、数式、参照が変わっていないか？ |
| 注記とリンク | 同じリンク先と関連付け | 各注記やリンクは正しいセルに対応しているか？ |
形式変換には別のリスクがあります。W3C の表のアクセシビリティガイドラインは、コンテンツを形式間で移動すると構造化された表のマークアップが失われやすいと警告しています。そのため、見た目は正しくても、支援技術に見出しとデータの関係を伝えられない表になることがあります。
表でよく起きる5つの問題と修正方法
1. テキストがはみ出す、または行が高くなりすぎる
翻訳後のラベルは長くなったり、文字幅が広くなったり、別の位置で折り返されたりします。行の高さが固定されていると最終行が切れ、自動調整では表が改ページをまたぐことがあります。
**次の順で修正します。**手動改行を削除し、行の自動拡張を許可し、最も狭い列を広げ、不要なセル余白を減らし、適切な場合は対象言語のハイフネーションを使います。意味が失われないことを言語レビュー担当者が確認してから表現を短くしてください。フォントサイズを小さくするのは最後です。
対象文字が四角形、分離した文字、想定外の書体で表示される場合は、はみ出しではなくフォントの問題として扱います。翻訳後にフォントが崩れる理由の確認手順に従ってください。
2. 結合セルが正しいデータを示さなくなる
元文書の結合見出しが3つの商品列にまたがっているとします。変換時に行や列が挿入、削除、移動されると、言葉の翻訳が正しくても、見出しが誤ったグループの上に表示されることがあります。
**元文書と照合して結合範囲を確認します。**複数の列や行にまたがる各見出しから、対応するセルまでをたどってください。翻訳したラベルを収めるためだけに結合セルを追加せず、幅や折り返しを調整します。
Microsoft はアクセシビリティのために単純な長方形の表を推奨しています。分割セル、結合セル、入れ子の表、空白の行や列は、スクリーンリーダーによるセルの数え上げや識別を妨げる可能性があるためです。複雑な結合範囲が必要な場合、目視確認だけでは不十分です。
3. 見出しとデータセルの関係が失われる
先頭行の太字は目の見える読者には見出しに見えますが、外観だけでは構造を定義できません。W3C のガイドラインでは、支援技術が該当する行と列の文脈を読み上げられるよう、見出しセルとデータセルを識別して関連付ける必要があります。
**編集可能な文書で意味的な見出しを復元します。**先頭行を見出しとして指定し、複数ページの表で見出しが繰り返されることを確認し、アプリケーションのアクセシビリティチェッカーで複雑な表をテストします。書き出した HTML または PDF でも、変換後に見出しの関連付けが残っていることを確認してください。
4. 数値、数式、識別子が気づかないうちに変わる
不自然な文章は気づきやすくても、小数点記号、マイナス記号、割合、モデル番号、スプレッドシート参照の変化は見落としがちです。読者向けにローカライズすべき値がある一方、識別子と計算ロジックは正確に維持しなければなりません。
**データだけを比較する工程を設けます。**文章は無視し、数字、通貨コード、パーセント記号、単位、範囲、合計、数式、脚注記号、セル参照を比較します。対象ファイルでスプレッドシートの数式と合計を再計算してください。意図したローカライズ変更を記録し、レビュー担当者が原文の形式に「修正」しないようにします。
5. 右から左のテキストで句読点や配置が乱れる
アラビア語とヘブライ語は右から左に進みますが、埋め込まれたラテン文字の用語や数字は左から右に進みます。そのため、Unicode はこれを双方向テキストとして扱います。また、個別の表セルを独立した段落として扱い、セルまたは段落単位で文字方向を設定できると説明しています。
**セルごとに修正します。**正しい基本方向を設定し、製品コード、日付、割合、括弧、スラッシュ、ラテン文字の横にある句読点を確認します。数字を手作業で逆順にしないでください。文字方向と鏡像化はレンダリング動作なので、編集可能な文書と書き出した PDF の両方を確認します。
翻訳前チェックリスト
- 可能なら編集可能な DOCX、PPTX、XLSX から始める。
- 余白調整のためだけに使われている空白の行と列を削除する。
- 可能な場合、レイアウト用の表を通常の文書レイアウトに置き換える。
- 本物の見出し行を指定し、データが許す限り表の構造を単純に保つ。
- 行の自動拡張を許可し、翻訳対象セルの高さを固定しない。
- 結合セル、数式、合計、保護対象の識別子、翻訳禁止用語を特定する。
- 原文の言語を正しく設定し、対象ロケールを記録する。
- 承認済み原文の外観をレビュー担当者が確認できるよう、参照用 PDF を保存する。
これらの手順により、ツールや翻訳者がファイルに触れる前に曖昧さを減らせます。また、後の問題が翻訳、変換、元の表設計のどこで生じたのかも判断しやすくなります。
翻訳された表の確認方法
工程を分けて確認してください。言語、データ、構造、レイアウトを一度に確認すると、小さなエラーを見落としやすくなります。
- **グリッドを比較します。**表、行、列、結合範囲、見出し行、注記の数を元文書と照合します。
- **内容を比較します。**すべてのセルが1回ずつ翻訳され、正しい見出しの下にあることを確認します。
- **データを比較します。**文章を編集せず、数値、符号、単位、数式、合計、識別子、リンクを確認します。
- **レイアウトを確認します。**切れ、過度な行の拡張、不適切な改ページ、自動調整で小さくなった文字、代替フォント、不揃いな配置を探します。
- **文字方向とアクセシビリティを確認します。**RTL セル、見出しの関連付け、読み上げ順序、繰り返し見出しを検証します。
- **書き出して再確認します。**納品する PDF などの最終形式を開き、編集可能な元ファイルだけで承認しないでください。
OpenL Doc Translator は PDF、DOCX、PPTX、XLSX などの文書形式に対応しています。公式ページによると、フォント、色、表、ページレイアウトを保持し、各ジョブで翻訳版と対訳版が提供されます。可能なら編集可能な元ファイルを使って結果をプレビューし、上記の構造化レビューを終える前に対訳版を比較してください。
書式の保持は再構築の手間を減らしますが、品質保証は不要になりません。表の確認後は、対訳文書レビューのチェックリストで文書全体を確認できます。
人による確認が不可欠な場合
表に次の内容が含まれる場合は、必ず人のレビュー担当者を割り当ててください。
- 財務合計、比率、予測、監査済み数値
- 法的義務、コンプライアンス上の制限、用量、安全データ
- 数式、シート間参照、計算フィールド
- 多段見出し、結合範囲、入れ子の表
- OCR に依存するスキャンまたは画像ベースのセル
- 右から左と左から右の文字が混在するテキスト
- 拡張余地のない固定印刷レイアウト
このような表では、「ファイルが開いた」「表が似て見える」だけでは合格基準になりません。元文書の構造との一致、対象言語での意味、すべての重要な値、最終納品形式を確認して初めて承認できます。
表の翻訳で守るべきものは、長方形の枠だけでなく関係性です。内容、構造、データ、レイアウト、文字方向、アクセシビリティを個別に確認すれば、書式の不具合がデータエラーに発展する可能性を大幅に下げられます。
Sources
- W3C: Text size in translation - Explains text expansion, constrained layouts, compound words, character width, and line-height differences across languages.
- W3C WAI: Tables Tutorial - Explains header-to-data relationships, complex table markup, screen-reader context, and metadata loss during format conversion.
- Microsoft Support: Make your Word documents accessible to people with disabilities - Recommends simple tables, header rows, accessibility checks, and avoiding split, merged, nested, or blank structures where possible.
- Unicode Standard Annex #9: Unicode Bidirectional Algorithm - Defines display ordering for mixed right-to-left and left-to-right text, digits, punctuation, and direction at paragraph or table-cell level.
- OpenL Doc Translator - Lists supported document formats, formatting preservation, free preview, and bilingual review output.
