第5章

第10章 · i18n設計とコンテンツ品質

翻訳ファイルの追加ではなく、言語・国・形式・画面状態を含む製品契約としてi18nを設計する。

この章で扱うこと

Separate locales from country profiles
Translatable assets and SSOT
Layouts for length, format, and state
Parity validation and operations

i18nの対象を分けて考える

i18nは翻訳ファイルを増やす作業ではない。利用者が異なる言語と地域でも同じ仕事を完了できるようにする製品設計である。localeは文字列、日付、数値、並び順に関係し、country profileは規制、通貨、データ提供者、公開範囲に関係する。

二つを一つの設定として扱うと、表示文の変更が業務規則の変更になる。言語は読み方、国プロファイルは適用する規則として、責任者と検証を分ける。

確認項目	意図
locale	文章と形式
country profile	規制とデータ
コンテンツ	表示文と代替文
識別子	コード・URL・パスは翻訳しない

標準: 利用者選択 → locale形式 / 国プロファイル規則

文章と構造の単一ソースを維持する

翻訳を画面に直接散らすと、ある言語だけでボタン、エラー、ヘルプ、空状態が欠ける。基準言語をSSOTにし、メッセージキー、画面構造、状態一覧、用語集を一緒に管理する。

キーは単なる実装名ではなく意味の契約である。画面構造を先に複製し、可視の文章だけを翻訳すると、実習とリンクも同じ形で保てる。

確認項目	意図
基準言語	構造の基準
キー	安定した意味の名前
用語集	一概念一表現
変更記録	文章と構造を区別

標準: 基準コンテンツ → キー・用語集 → 翻訳 → 構造確認

演習

キーは単なる実装名ではなく意味の契約である。画面構造を先に複製し、可視の文章だけを翻訳すると、実習とリンクも同じ形で保てる。

{
  "review": {
    "approve": "승인",
    "returnForChanges": "수정 요청",
    "empty": "검토할 보고서가 없습니다."
  },
  "errors": {
    "network": "연결을 확인한 뒤 다시 시도하세요."
  }
}

長い文字列と地域形式を設計入力にする

言語によって文の長さは変わる。固定幅のボタンと表は文章を切ったり画面外へ押し出したりする。日付と数値は文字列結合ではなくlocale対応の形式化を使い、実際の言語版で改行を確認する。

通常画面だけでなく、空、エラー、権限なし、読み込み中も翻訳する。長い名前、0件、通信失敗を各言語で確認する。

確認項目	意図
柔軟な幅を使う。	言語による文字数差が画面を壊さないため。
locale形式化を使う。	文字列を手で組み立てる際の形式誤りを避けるため。
長くなる表とボタンを確認する。	翻訳後のはみ出しを公開前に発見するため。
解決行動と代替文を翻訳する。	翻訳漏れで復旧経路とアクセシビリティが切れないため。

標準: メッセージ・形式 → 柔軟な部品 → 状態表示 → 言語プレビュー

利用者の仕事が同じかで同等性を確認する

自然な翻訳でも、ある版で保存、警告、リンク、実習手順が欠ければ同等ではない。自動検査は見出し、コード、リンク、検索登録を比べ、人の確認は用語、文体、切れ、国規則を確認する。

基準言語を先に確定し、すべての言語版を同じ変更セットで更新する。配布前には言語切替、空・エラー状態、日時・通貨、アクセシブルな名前を確認する。

確認項目	意図
1. 見出し・実習・リンクは同じか。	翻訳版が基準言語と同じ構造を保つか確認するため。
2. コードとURLは変わらないか。	翻訳がコードと資源経路を壊していないか確認するため。
3. 長文と解決行動が見えるか。	実レンダリングで切断とはみ出しを確認するため。
4. 国設定が言語を変えないか。	国設定変更が言語文を汚さないか確認するため。

標準: 基準変更 → 翻訳 → 自動比較 → 画面確認 → 承認

自己確認

翻訳版が基準言語と同じ見出し・実習・リンクを保つか、どう検査するか。
コード・経路・URL・識別子を翻訳しない理由は何か。
文が長くなる言語向けのレイアウト・UI確認はいつどう行うか。
国設定変更でlocale文が汚れないよう何を確認するか。

← 前へ