ローカライゼーション用語集は意思決定の集合である

用語集はしばしば、小さな二言語辞書のように扱われます。つまり、1つの原文用語の横に1つの承認済み訳語が並ぶものです。

これは有用な出発点ですが、そもそもなぜローカライゼーションチームに用語集が必要なのかという理由を見落としています。製品用語は、単独の語彙であることはめったにありません。そこには、ブランド、インターフェース、法務、市場に関する意思決定が反映されています。

最良の用語集は、それらの意思決定を、人間にもAIモデルにも一貫して適用できるほど明確に記録します。

用語には文脈が必要

同じ原文の語でも、製品全体で異なる役割を果たすことがあります。

"Workspace" は、インターフェースではブランド化された機能名であるかもしれませんし、ヘルプ記事では一般的な説明であるかもしれませんし、顧客事例では物理的な場所を指すかもしれません。対象言語での1つの訳語だけでは、すべての用法に当てはまりません。

各用語集エントリには、その用語を識別できるだけの十分な文脈を含めるべきです。

• 製品内での意味
• そのルールが適用されるコンテンツタイプまたはフィールド
• 承認済みの対象言語の用語
• 完全な文での例
• 既知の例外
• 大文字表記や複数形の変更が可能かどうか

文脈によって、推奨語は強制力のある編集ルールになります。

「翻訳しない」も実際の翻訳判断である

製品名、プラン名、APIパラメータ、商標は、しばしば変更せずに維持する必要があります。そうした用語も用語集に含めるべきです。

用語を保護対象として明示するほうが、すべての翻訳者やモデルがそれを認識すると想定するより安全です。その指示では、周囲の文法がその用語を活用させてよいか、また特定の文字体系では音訳が許可されるかどうかも説明すべきです。

指針のない未翻訳語は、それでも不自然な文を生む可能性があります。

巨大な用語リストより狭く明確なルールを優先する

用語集は、明白なエントリや価値の低いエントリで埋まるほど使いにくくなります。

優先すべきなのは、特徴的で、曖昧で、顧客向けで、法的にセンシティブで、または頻繁に不一致が起きる用語です。一般的な言葉は、製品がそれを特別な意味で使っていない限り、通常はルールを必要としません。

小さい用語集のほうがレビューしやすく、モデルのコンテキストにも収めやすく、矛盾する指示を含みにくくなります。

レビュー時に用語集を適用する

用語情報をモデルに渡すことは、ワークフローの半分にすぎません。

レビューでは、提案された訳が必須用語に違反している場合、保護されたトークンを変更している場合、または承認済みの語を誤った文脈で使っている場合に、それを指摘できるべきです。レビュー担当者は、別の文書を検索するのではなく、下書きの横に関連する用語集エントリを確認できるべきです。

すべての不一致を自動修正すべきではありません。文法や文脈によっては例外が正当化されることがあります。システムはルールを見える形にし、レビュー担当者がその例外が有効である理由を記録できるようにすべきです。

修正を用語集の改善に生かす

レビューで繰り返し行われる修正は、有用なシグナルです。

レビュー担当者が同じ語句を何度も置き換えているなら、用語集に用語が欠けている可能性があります。既存ルールが頻繁に上書きされているなら、そのエントリは広すぎるか不明確なのかもしれません。用語関連の修正をまとめた簡単なレポートは、ローカライゼーション責任者が最も効果の大きいルールを改善する助けになります。

用語集への変更はバージョン管理されるべきです。翻訳リクエストは、どのルールを使用したかを記憶しておく必要があります。そうすれば、古い下書きが理解でき、必要に応じて新しいガイダンスのもとで再生成できます。

用語とトーンを分ける

用語集が答えるのは「どの用語か？」です。ブランドガイダンスが答えるのは「どのような響きにすべきか？」です。

どちらも重要ですが、これらを1つの長いプロンプトにまとめると、それぞれの保守が難しくなります。用語情報は構造化し、ロケールごとに管理してください。トーン、読者層、ライティング原則はプロジェクト指示に保持してください。そして翻訳リクエストには、優先順位を明確にしたうえで両方を提供してください。

まとめ

ローカライゼーション用語集は、単なる単語の羅列ではありません。これは、製品言語に関する意思決定を簡潔に記録したものです。

重要な用語には文脈を与え、保護語を含め、リストは意図的に保ち、レビュー中にルールを可視化し、繰り返される修正から学びましょう。用語集が生きた編集インフラとして扱われると、一貫性は次のリリースをたまたまレビューする人に依存しなくなります.