翻訳・ローカリゼーション用語集
ウェブサイトを翻訳したり製品を国際化したりする際に出会う用語を、わかりやすい言葉で解説します。各項目では概念と、それが実務上なぜ重要なのかを説明します。
i18n（国際化）
コードを変更せずにさまざまな言語や地域に対応できるよう、ソフトウェアを設計する取り組みです。「internationalization」の「i」と「n」の間にある18文字にちなんだ略語です。適切に国際化されたアプリは、ユーザーに表示するすべてのテキストを外部化し、日付や数値をロケールのルールに従って整形し、テキストの方向や長さに関する固定的な前提を避けます。
参照: React の i18n アプローチ →l10n（ローカリゼーション）
テキストの翻訳、日付・数値形式の調整、現地通貨への切り替え、必要に応じたRTLレイアウト対応など、製品を特定のロケールに実際に適応させるプロセスです。「10」は「localization」の「l」と「n」の間にある10文字を表します。i18nがエンジニアリングの土台だとすれば、l10nはその上に構築されるコンテンツと文化の仕事です。
参照: ローカリゼーションコストガイド →Locale（ロケール）
fr-FR（フランスで話されるフランス語）や fr-CA（カナダで話されるフランス語）のような、言語と地域コードの組み合わせです。同じ言語でも地域によって語彙、綴り、通貨、日付形式、さらには句読点の慣習まで大きく異なることがあるため、ロケールは重要です。形式は IETF BCP 47 標準（言語-地域）に従います。
参照: 多言語 SEO ガイド →hreflang
各ロケールのユーザーにどの言語版のページを表示すべきかを検索エンジンに伝える HTML のリンク属性です。<link rel="alternate" hreflang="fr" href="https://example.com/fr/page"> のように記述します。hreflang がないと、検索エンジンが誤った言語版を表示したり、すべてのバージョンを1つに統合してしまい、多言語 SEO が損なわれることがあります。国際サイトにとって最も重要な技術要件の1つです。
参照: hreflang 実装ガイド →RTL（右から左）
アラビア語、ヘブライ語、ペルシア語、ウルドゥー語で使われるテキスト方向です。RTL レイアウトではページ全体が反転します — テキストは右揃えになり、マージンとパディングが鏡映しになり、flex の方向が逆転し、戻るボタンやパンくずリストなどの UI 要素も左右が入れ替わります。RTL を正しくサポートするには、物理的なプロパティではなく CSS の論理プロパティ（margin-left ではなく margin-inline-start）が必要です。
参照: RTL 実装ガイド →翻訳メモリ（TM）
過去に翻訳された文のペアを保存するデータベースです。以前翻訳されたテキストの断片が完全一致または近い形で再び現れると、TM は既存の翻訳を提案します。これにより製品全体で一貫性が保たれ、同じ文が2か所で異なる形に翻訳されるのを防ぎ、一致したセグメントは再翻訳が不要になるためコストと時間も削減できます。
参照: Lingvit の機能 →機械翻訳（MT）
人間ではなくソフトウェアによって自動的に行われる翻訳です。出力品質はプロバイダー、言語ペア、分野、原文によって異なるため、重要な製品情報、法的文書、商取引に関するコピーは公開前に確認する必要があります。
参照: ウェブサイトの翻訳方法 →ニューラル機械翻訳（NMT）
深層学習ニューラルネットワークを用いて言語をモデル化する機械翻訳の一種です。NMT は文全体の文脈を理解することで、単語ごとに翻訳する従来の統計的手法を大幅に上回る性能を発揮します。流暢さ、慣用表現、曖昧さの処理に優れており、現在の本番翻訳システムの標準となっています。
参照: 翻訳アプローチの比較 →CAT ツール（コンピュータ支援翻訳）
翻訳メモリ、用語集、プロジェクト管理を1つのインターフェースにまとめ、人間の翻訳者がより速く作業できるよう支援するソフトウェアです。翻訳者は原文と自分の翻訳を並べて確認し、TM からの提案を受け取ります。代表的な CAT ツールには OmegaT（オープンソース）、SDL Trados、Phrase などがあります。CAT ツールは人間の判断を置き換えるのではなく、補完するものです。
参照: 翻訳ツールの比較 →用語集（ローカリゼーションにおける）
用語とその承認済み翻訳をまとめたリストです。用語集は、ブランド名、製品名、法律用語、専門用語が一貫して翻訳される — あるいは意図的に翻訳されないまま残される — ことを保証します。用語集がないと、翻訳者や MT エンジンによって同じ用語が製品内で5通りに翻訳されてしまうこともあります。
参照: Lingvit の用語集機能 →ソース言語（原文言語）
翻訳対象となるコンテンツの元の言語です。ほとんどの国際製品では、英語優先の開発がグローバルソフトウェアの既定であるため、ソース言語は英語になります。ソース言語は正本のバージョンであり、すべての翻訳はそこから派生し、コンテンツが更新されるとそこに戻ります。
参照: 対応言語一覧 →ターゲット言語（対象言語）
コンテンツの翻訳先となる言語です。通常、1つのローカリゼーションプロジェクトには1つのソース言語と複数のターゲット言語があります。ターゲット言語の選定は、ユーザーが話す言語、製品が成長している地域、現地語コンテンツに関する規制や対応要件がある地域など、市場データに基づいて行われます。
参照: 対応言語一覧 →文字列（String）
ソフトウェアのローカリゼーションにおいて、文字列とはボタンのラベル、エラーメッセージ、ツールチップ、ナビゲーション項目、フォームのプレースホルダー、ページタイトルなど、ユーザーに表示されるあらゆるテキストのことです。ローカリゼーションのワークフローは、コードから文字列を抽出し、翻訳に送り、翻訳済みのバージョンを再挿入します。文字列管理は i18n の中心的な課題であり、製品の変更に合わせて翻訳を同期し続けることが求められます。
参照: ドキュメント →疑似ローカリゼーション
実際の翻訳が始まる前に、原文の文字を視覚的に似たアクセント付きまたは拡張された文字に置き換えるテストの手法です。例えば「Hello」は「Ĥéļļö Ŵörļd」のようになり、英語としては読めるものの視覚的には異なります。これにより、実際の翻訳を待たずに、テキストの拡張、フォント対応の不足、要素幅の固定などが原因の UI レイアウトのバグを発見できます。
参照: i18n ライブラリが適する場面 →MutationObserver
DOM の変更を監視し、ノードが追加・削除・変更されるたびにコールバックを発火するブラウザ API です。翻訳ウィジェットは MutationObserver を使い、初期読み込み後にページへ挿入されたテキストを検出・翻訳します。これは、シングルページアプリや JavaScript によって動的に読み込まれるあらゆるコンテンツにとって不可欠です。これがなければ、ウィジェットは最初の HTML のみを翻訳し、それ以降のコンテンツをすべて見逃してしまいます。
参照: React・SPA 連携ガイド →FIGS
フランス語、イタリア語、ドイツ語、スペイン語という西欧の4大言語の略称です。FIGS は、ローカリゼーション業界において、多くのグローバルソフトウェア製品が英語の次に対象とする最初の拡張言語セットを指す略語です。GDP の高い4つの大規模市場をカバーし、ラテン文字や同程度のテキスト拡張率など、共通する言語基盤を十分に備えているため、まとめて取り組みやすいとされています。
参照: 対応言語一覧 →関連ガイド
あわせて読む
- 対応言語一覧（30以上） — RTL 言語を含む、Lingvit が対応するロケールをご覧いただけます。
- ウェブサイトの翻訳方法 — 上記の用語の多くを実践に活かす、実用的なステップバイステップガイドです。