利益:
- ローカリゼーションと翻訳を区別し、プレースホルダーの整合性、テキストの長さ、日付/金額/メジャーの形式を正しく管理する機能
- 複数のルールや右から左へ記述する言語などの技術的特徴をターゲット ロケールに適応させる機能
- 現地の専門家の観点から文化的要素を評価し、QA を使用して人工知能のプレースホルダーと文化的リスクを把握する能力
アプリの「保存」ボタンを「保存」に変えるのは変換です。しかし、アプリケーションの日付形式、通貨、右から左への記述、ボタンの長さ、文化的イメージ、法的文章をターゲット市場に適応させることがローカライズです。この単元では、ローカリゼーション、その技術的特徴 (プレースホルダー、長さ、コーディング)、このプロセスにおける AI の役割、および文化的適応について学びます。目標は、ローカリゼーションの専門家のように考えて、「言葉ではなくターゲットの文化に製品を適合させる」ことです。
基本的な概念
ローカリゼーション (L10n — ローカライゼーション; L10n は「l」と「n」の間に 10 文字があるため) は、製品 (ソフトウェア、Web、ゲーム、アプリケーション) を特定の言語と文化に完全に適応させるプロセスです。それは翻訳を含みますが、それを超えています。国際化 (i18n — 国際化) は、言語に非常に対応できるように製品をゼロから設計する行為です (テキストをコードから分離し、長さの柔軟性を可能にします)。これはローカリゼーションに先行して有効になります。
文字列は、ソフトウェアで翻訳されるテキストの一部です。プレースホルダーは、実行時に変数「Hello {name}」、「{count} items」が設定される文字列内のマークです。ロケールは、言語と地域 (tr-TR、en-US) の組み合わせです。日付、時刻、数値、通貨の形式を指定します。
ローカリゼーションは翻訳とは異なります。意味だけでなく、機能や文化的適切性も伝えます。 「2026 年 3 月 4 日」という日付は米国では 3 月 4 日であり、トゥルキエでは意味がありません (03.4.2026 と書きます)。 「$」の代わりに「₺」を使用します。赤という色は、ある文化では警告であり、別の文化では祝祭である可能性があります。
ヒント: 翻訳者がローカリゼーションで最も見逃しやすいのは、日付/時刻/数値形式、通貨、測定単位 (マイル/km)、名前の順序、住所形式、電話形式など、テキスト以外の要素です。 「ロケール チェックリスト」を使用して、すべてのプロジェクトでこれらをスキャンします。
プレースホルダーと技術的完全性
ローカリゼーションにおける最も危険な技術的ミスは、プレースホルダーとタグの破損です。 「メッセージが {n} 件あります」という文の {n} を削除したり、間違って書いたり、トルコ語の構文に従って間違った場所に入れたりすると、ソフトウェアがクラッシュするか、「メッセージが {n} 件あります」と粗雑に表示されます。ルール:
- プレースホルダーを回転、削除、または書式設定しないでください。 {name}、%s、{{count}} は変わりません。
- トルコ語の構文はプレースホルダーを置き換えることができます。意味を維持しながら新しい場所に移動しますが、標識自体は破壊しないでください。
- 複数のルールは言語によって異なります。英語では「1 項目 / 2 項目」となりますが、トルコ語では数字の後に複数の接尾辞はありません (「2 項目」)。ローカリゼーション フレームワークはこれを個別に処理します。
ここで AI は 2 つの側面を持つツールです。文字列を迅速に変換しますが、誤ってプレースホルダーを反転したり失ったりする可能性があります。そのため、ローカライズにはプレースホルダー QA ラウンドが不可欠です。
注意: テキストの拡張はローカリゼーションの隠れた問題です。英語からトルコ語への翻訳テキストは、多くの場合 20 ～ 40% 長くなります。 「OK」は 2 文字で、対応する「OK」は 5 文字です。狭いボタンに収まらない翻訳はインターフェイスを壊します。可能であれば、実際のインターフェイスでターゲット テキストが適合するかどうかを確認してください。
AI を使用したローカリゼーション フローと文化適応
AI は、ローカリゼーションにおける次のタスクを高速化します。文字列の初期翻訳、一貫性チェック、長さの警告 (「この翻訳はオリジナルより 35% 長い」)、文化的適切性のスクリーニング (「この画像/例はターゲット文化で問題を引き起こすか?」)。しかし、文化的な決定は人間に属します。地元の専門家は、ジョーク、休日、例、色が対象の文化でどのように認識されるかを知っています。 AI は一般的な警告を発することができます。最終的な決定は、現地市場に精通した翻訳者によって行われます。
文化的適応の例: 支払い方法 (現地のカード)、名前の例 (現地の名前)、測定単位、法的義務 (KVKK/GDPR テキスト)、休日、住所の形式 (あなた/あなた)、色と記号の意味。
ミニケース3個
ケース 1 — プレースホルダー QA によってクラッシュが防止されました。モバイル アプリケーションの 1,200 文字列の翻訳において、AI は 18 か所で {count} プレースホルダーを「{number}」として翻訳しました。プレースホルダー QA ラウンドでこれらのことが判明しました。これが修正されていない場合、アプリケーションはこれらの画面でクラッシュする可能性があります。
ケース 2 — 長さによってインターフェースが壊れました。あるソフトウェアのメニューは英語でデザインされていました。トルコ語の翻訳が平均して 30% 長くなったため、3 つのメニュー項目が移動およびカットされました。もしチームが早い段階で長さの警告を受け取っていれば、短い代替案 (「設定」の代わりに必要に応じて省略形) を用意していたでしょう。ジョブは再実行され、プロセス長制御で更新されました。
ケース 3 — 文化への適応が売上を救った。ゲームのプロモーションでは、豚のフィギュアが付いた功績バッジがありました。ターゲット市場では、これは文化的に不適切でした。現地の翻訳者は、図が変更されていると警告しました。 AIが文章を翻訳していましたが、文化的リスクを指摘したのは現地の専門家でした。
コピー可能な 4 つのテンプレート
1) 文字列翻訳 (プレースホルダー保護):
次のソフトウェア文字列を [ターゲット言語] に翻訳します。ルール: {name}、%s、{{count}} などのプレースホルダーを決して翻訳、削除、または書式設定しないでください。そのままにしておきます (トルコ語の構文に従って移動できます)。 HTML/タグを保持します。インターフェースに合わせて簡潔に記述してください。形式: ソース → 翻訳.文字列: [...]
2) プレースホルダー/ラベル QA:
以下はソース文字列と翻訳された文字列です。プレースホルダーとタグの問題のみを報告します: 翻訳/削除/破損{...}、%s、{{...}}、<tag>。ソースにあるプレースホルダーの数と翻訳にあるプレースホルダーの数をリストし、一致しないものをリストします。出典: [...] |翻訳: [...]
3) 長さとインターフェースの警告:
次の UI 翻訳の長さを評価します。翻訳ごとに、ソースに応じて拡張率を指定し、狭いスペース (ボタン、メニュー) に収まらない可能性のあるものにマークを付けます。適合しないものについては、意味を維持する短い代替案を提案してください。ペア (ソース | 翻訳): [...]
4) 文化的適合性審査:
あなたの役割: [対象市場] ローカリゼーション コンサルタント。ターゲット文化で問題を引き起こす可能性のあるコンテンツ内の要素にフラグを立てます: 画像、例、名前、色、記号、ジョーク、日付/測定形式、法的テキスト。最終的な決定は私が行います。リスクを指摘し、代替案を提案します。内容: [...]
弱いプロンプト / 強いプロンプト
弱者: 「これらのアプリのテキストを翻訳してください。」 (プレースホルダー、長さ、インターフェースコンテキストなし。プレースホルダーは機械翻訳され、テキストは長くなります。)
Strong: 「これらのモバイル アプリケーション文字列をトルコ語に翻訳します。{user} と %d プレースホルダーはそのままにしておきます。これらのテキストは幅の狭いボタンに表示されます。可能であれば短くしてください。「設定」→「設定」、「プロファイル」→「プロファイル」。複数表現についてはトルコ語のルールに従ってください (数字の後に複数の接尾辞は付けません)。
違い: 強力なプロンプトでは、プレースホルダー、長さ、用語、および複数形の規則が与えられます。出力はインターフェイスに直接入力されることに近いでしょう。
ローカリゼーションの寸法表
サイズ
例
リスク
プレースホルダー/ラベル
{名前}、%s、<b>
ソフトウェアのクラッシュ
長さ
「OK」→「OK」(150%)
インターフェースのオーバーフロー
日付/番号/金額
3/4/26、$、1,000.50
虚偽の情報
複数ルール
2アイテム→2アイテム
悪い文法
文化的要素
イメージ、色、ユーモア
評判・売上
法的文章
KVKK/GDPR
法的リスク
よくある間違い
- プレースホルダーを反転/削除します。ソフトウェアがクラッシュしたり、生のテキストが表示されたりする原因になります。
- テキストの伸縮は考慮されていません。インターフェイスがオーバーフローし、要素が切り詰められます。
- 日付/通貨/測定形式は変換されません。 「8km」ではなく「5マイル」が残った。
- 地元の専門家に相談せずに文化的要素をパスする。評判と販売のリスク。
- 複数のルールを英語のロジックで翻訳します。 「2項目」など文法が悪い。
擬似ローカリゼーションと右から左へ記述する言語
ローカリゼーションの品質を決定する 2 つの技術的な問題があります。 1 つ目は擬似ローカリゼーションです。実際の翻訳の前に、偽の、しかし現実的な長さと特殊文字のテキスト (例: 「設定」→「[Ŝéttîngŝ~~]」) を使用して製品をテストします。これは、インターフェイスが長いテキストと特殊文字を処理できるかどうか、翻訳が開始される前に文字列が実際に抽出されているかどうかを示します。開発者と協力する翻訳者がこのテストを推奨すると、多くのインターフェイス エラーが発生する前に検出されます。
2 つ目は右から左へ書く (RTL) 言語です。アラビア語、ヘブライ語、ペルシア語などの言語は右から左へ書かれ、ローカリゼーションにはテキストだけでなくインターフェイス レイアウト全体 (メニューの位置、矢印、配置) をミラーリングする必要があります。 RTL 翻訳では、数字とラテン文字の用語が混乱を引き起こす可能性があります。この「双方向テキスト」の問題には特別な注意が必要です。 AI は RTL テキストを翻訳できますが、レイアウトのミラーリングと双方向フローの決定には技術的かつ文化的な専門知識が必要です。これら 2 つの問題は、ローカリゼーションが翻訳を超えたエンジニアリング文化的な作業であることを示しています。
要約すると
ローカリゼーションとは、言葉ではなく製品をターゲットの言語や文化に適応させることを意味します。翻訳が含まれますが、プレースホルダの完全性、テキストの長さ、日付/金額/メジャーの形式、複数規則、および文化的要素も含まれます。 AI は文字列の翻訳、長さ、文化的リスクのスクリーニングを加速します。ただし、QA ツアーはプレースホルダーを混乱させる可能性があり、文化的な決定は地元の市場を知っている専門家によって行われるため、不可欠です。ローカライゼーションを成功させるには、テキストを超えて細部にまで注意を払う必要があります。
アプリケーションタスク
15 ～ 20 個の文字列 (プレースホルダー {...} または %s と日付/金額の例を含む) からなるサンプル インターフェース テキストを考えてみましょう。 「文字列翻訳」パターンで翻訳し、「プレースホルダー QA」でプレースホルダーの整合性をチェックし、「長さ警告」でオーバーフローのリスクをチェックします。日付と金額の形式を対象のロケールに適合させ、文化的要素がある場合は「文化的適合性スキャン」を実行します。
チェックリスト
- [ ] プレースホルダーやラベルはそのままにしてQAで確認しました。
- [ ] テキストの伸びを制御し、狭い領域でのオーバーフローを防止しました。
- [ ] 日付、数値、通貨、測定単位をターゲットのロケールに合わせました。
- [ ] 複数の表現をターゲット言語の規則に従って翻訳しました。
- [ ] 地元の専門家の視点から文化的要素を評価しました。