Loading article…
IETF BCP 47 言語タグは、インターネット上の人間の言語を識別するために使用される標準化されたコードです。 [ 1 ]タグの構造は、インターネット技術タスクフォース(IETF) [ 1 ]によってベスト カレント プラクティス (BCP) 47で標準化されています。[ 1 ]サブタグは、IANA 言語サブタグ レジストリによって管理されています。[ 2 ] [ 3 ] [ 4 ]
国、地域、または文字体系（スクリプト）の言語のバリエーションを区別するために、IETF 言語タグは、ISO 639、ISO 15924、ISO 3166-1、UN M.49などの他の標準からのサブタグを組み合わせます。たとえば、このタグenは英語、es-419ラテンアメリカのスペイン語、ロマンシュ語rm-sursilv（スルシルヴァン語）、キリル文字で書かれたセルビア語sr-Cyrl、台湾で話されている繁体字の閩南語、香港で話されている繁体字の広東語、チューリッヒドイツ語を表します。nan-Hant-TWyue-Hant-HKgsw-u-sd-chzh
HTTP [ 5 ] : §8.5.1 HTML [ 6 ] XML [ 7 ]および PNG [ 8 ]などのコンピューティング標準で使用されています。
IETF言語タグは、1995年3月に発行されたHarald Tveit Alvestrand編集のRequest for comment 1766で初めて定義されました。 [ 9 ]これらのタグはISO 639の2文字言語コードとISO 3166の2文字国コードを使用し、3～8文字のバリアントまたはスクリプトのサブタグを含むタグ全体を登録することができました。
2001年1月、RFC 3066 [ 10 ]によりこれが更新され、ISO 639-2 3文字コードの使用が追加され、数字を含むサブタグが許可され、言語タグのマッチングに役立つようにHTTP/1.1の言語範囲の概念が採用されました。
仕様の次の改訂は、Addison Philips とMark Davisが編集した仕様の主要部分である RFC 4646 [ 11 ]と、マッチング動作を扱う RFC 4647 [ 12 ]の公開により、2006 年 9 月に行われました。RFC 4646 では、言語タグのより構造化された形式が導入され、ISO 15924 の 4 文字のスクリプト コードと UN M.49 の 3 桁の地理的地域コードの使用が追加され、古いタグのレジストリが新しいサブタグのレジストリに置き換えられました。新しい構造に準拠しない以前に定義された少数のタグは、RFC 3066 との互換性を維持するために、既得権として残されました。
仕様の現行バージョンであるRFC 5646は、2009年9月に公開されました。[ 13 ]この改訂の主な目的は、 ISO 639とBCP 47間の相互運用性を向上させるために、ISO 639-3および639-5の3文字コードを言語サブタグレジストリに組み込むことでした。[ 14 ]
各言語タグは、ハイフン（-）で区切られた1つ以上の「サブタグ」で構成されます。各サブタグは、基本的なラテン文字または数字のみで構成されます。
x-で始まる私的使用言語タグと、既存の言語タグ（i-で始まるものや、以前の言語タグレジストリに登録されていたものを含む）を除き、サブタグは次の順序で出現します。
サブタグは大文字と小文字を区別しませんが、仕様では言語サブタグレジストリと同じ大文字小文字を使用することを推奨しています。つまり、地域サブタグは大文字、スクリプトサブタグはタイトルケース、その他のサブタグはすべて小文字です。この大文字小文字の区別は、基となるISO規格の推奨事項に準拠しています。
オプションのスクリプトおよび地域サブタグは、言語タグに識別情報を追加しない場合は省略することが推奨されます。例えば、スペイン語はラテン文字で表記されることが一般的であるため、es-Latnよりもesが推奨されます。また、日本で使用される日本語は、他の地域で使用される日本語と大きく異ならないため、 ja-JPよりもjaが推奨されます。
すべての言語地域を有効な地域サブタグで表現できるわけではありません。主要言語の地域方言は、変種サブタグとして登録されます。例えば、カタルーニャ語のバレンシア方言を表す「valencia」変種サブタグは、言語サブタグ登録簿に接頭辞「ca」を付けて登録されています。この方言はほぼスペイン国内でのみ話されているため、地域サブタグ「ES」は通常省略できます。
さらに、ラテン文字などの伝統的な文字体系、あるいはそもそも文字体系そのものに言及しない文字タグも存在し、これらは通常Zで始まります。例えば、Zsyeは絵文字、Zmthは数式表記、Zxxxは未記述の文書、Zyyyは未定義の文字体系を指します。
IETF言語タグは、多くのアプリケーションでロケール識別子として使用されています。RFC 4647で説明されている戦略が適切でない場合、これらのアプリケーションはロケールを定義、エンコード、およびマッチングするための独自の戦略を確立する必要があるかもしれません。
IETF言語タグの使用、解釈、およびマッチングは、現在RFC 5646およびRFC 4647で定義されています。言語サブタグレジストリには、現在有効なすべての公開サブタグが一覧表示されます。プライベート使用のサブタグは、実装に依存し、それらを使用する第三者間の私的合意の対象となるため、レジストリには含まれません。これらの私的合意は、BCP 47の範囲外です。
以下は、よく使用される主要言語サブタグの一部です。このリストは主要言語サブタグのごく一部（2%未満）のみを表しています。詳細については、言語サブタグレジストリを直接参照してください。
サブタグの中にはISOまたはUNの中核規格から派生したものもありますが、言語タグの意味が時間とともに変化する可能性があるため、これらの規格に完全に準拠しているわけではありません。特に、ISO 639、ISO 15924、ISO 3166、またはUN M49によって割り当てられたコードから派生したサブタグは、対応する中核規格からコードが削除された場合でも、有効な（ただし非推奨の）サブタグとして残ります。規格が後日、削除されたコードに新しい意味を割り当てた場合でも、対応するサブタグは以前の意味を保持します。
この安定性はRFC 4646で導入された。
RFC 4646 では「拡張言語サブタグ」（ extlangと呼ばれることもある）の概念が定義されましたが、当時そのようなサブタグは登録されていませんでした。[ 16 ] [ 17 ]
RFC 5645 および RFC 5646 では、レジストリにまだ登録されていないすべての言語について、ISO 639-3コードに対応するプライマリ言語サブタグが追加されました。さらに、特定のマクロ言語に含まれる言語のコードが拡張言語サブタグとして登録されました。手話も、接頭辞sgnを付けて extlang として登録されました。これらの言語は、含まれる言語のサブタグのみ (中国語の場合はcmn ) または言語と extlang の組み合わせ ( zh-cmn ) のいずれかで表すことができます。ほとんどの場合、最初のオプションが推奨されます。2 番目のオプションは「extlang 形式」と呼ばれ、RFC 5646 で新たに導入されました。
RFC 4646 より前に登録され、現在「既存」または「冗長」と分類されているタグ全体（新しい構文に適合するかどうかによって分類される）は、対応する ISO 639-3 ベースの言語サブタグが存在する場合は、そちらを使用するよう推奨されます。例をいくつか挙げると、閩南語ではzh-min-nanよりもnanが推奨され、客家語ではi-hakやzh-hakkaよりもhakが推奨され、アメリカ手話ではsgn-USよりもaseが推奨されます。
Windows Vista以降のバージョンのMicrosoft WindowsはRFC 4646をサポートしています。[ 18 ]
ISO 639-5では、言語コレクションを、当初ISO 639-2でエンコードされていた方法とは異なる方法で、アルファベット3コードで定義しています（ISO 639-1に既に存在していたコード、すなわち、 ISO 639-1ではbh 、ISO 639-2ではbihとして包括的にコード化されていたビハール語も含まれます）。具体的には、ISO 639-5では、言語コレクションはすべて包括的に定義されるようになり、一部の言語コレクションが排他的に定義されていたのとは対照的です。これは、言語コレクションの範囲が以前よりも広くなり、場合によっては、ISO 639-2で既に個別にコード化されていた言語も包含する可能性があることを意味します。
例えば、ISO 639-2 のコードafa は以前は「アフロ・アジア語族（その他）」という名称に関連付けられており、アラビア語のように既に独自のコードを持つ言語は除外されていました。ISO 639-5 では、このグループは「アフロ・アジア語族」と名付けられ、そのような言語すべてが含まれています。ISO 639-2 は 2009 年に、包括的な ISO 639-5 の名称に合わせるために、排他的な名称を変更しました。[ 19 ]
これらのコレクションの古い（排他的な）定義に依存している可能性のある実装が壊れるのを避けるため、ISO 639-5 では、ISO 639-2 ですでにエンコードされていたすべてのコレクションに対してグループ化タイプ属性を定義しています（ISO 639-5 でのみ追加された新しいコレクションに対しては、このようなグループ化タイプは定義されていません）。
BCP 47では、言語コレクションのサブタグを識別するための「スコープ」プロパティが定義されています。しかし、特定のコレクションが包括的か排他的かを定義するものではなく、ISO 639-5のグループ化タイプ属性も使用していません。ただし、これらのサブタグの言語サブタグレジストリの説明フィールドは、ISO 639-5（包括的）名と一致しています。そのため、コレクションのプライマリ言語サブタグを含むBCP 47言語タグは、そのコレクションが包括的か排他的かについて曖昧になる可能性があります。
ISO 639-5では、これらの言語コレクションにどの言語が含まれるかを正確に定義していません。コレクションの包括的な定義を用いて、コレクションの階層的な分類のみが定義されています。そのため、RFC 5646では、ほとんどの用途において言語コレクションにサブタグを使用することを推奨していませんが、「複数言語」や「未定」など、意味がさらに曖昧なサブタグよりは依然として好ましいとしています。
対照的に、マクロ言語内における個々の言語の分類は、ISO 639-3と言語サブタグレジストリの両方で標準化されている。
スクリプトサブタグは、RFC 4646 の発行時に、 ISO 15924で定義されたコードリストから初めて言語サブタグレジストリに追加されました。これらは、プライマリ言語サブタグと拡張言語サブタグの後、地域サブタグやバリアントサブタグなどの他の種類のサブタグの前に、言語タグ内にエンコードされます。
主要言語のサブタグの中には、「Suppress-Script」というプロパティを持つものがあります。これは、その言語が別の文字体系で表記できる場合でも、通常は単一の文字体系がデフォルトで想定されるケースを示します。このような場合、マッチングの成功率を高めるために、文字体系のサブタグを省略することが望ましいです。ただし、必要に応じて、区別するために別の文字体系のサブタグを追加することもできます。例えば、イディッシュ語にはヘブライ語の文字体系のサブタグが想定されるため、ほとんどの場合、 yi-Hebrよりもyiが推奨されます。
別の例として、zh-Hans-SG はzh-Hansと同等とみなすことができます。なぜなら、地域コードはおそらく重要ではないからです。シンガポールで使用される中国語の表記は、中国語が表記される他の国々と同じ簡体字を使用しています。しかし、スクリプトのサブタグは重要であるため維持されています。
ISO 15924 には、UnicodeおよびISO/IEC 10646で統一されているいくつかの文字体系の変種 (例えば、中国語の簡体字と繁体字を表す Hans と Hant)のコードが含まれています。これらの文字体系の変種は、多くの場合、書誌学的な目的でエンコードされますが、言語学的な観点からは必ずしも重要ではありません (例えば、ラテン文字のフラクトゥール体とゲール語の変種を表すLatfとLatgの文字体系コードは、Unicode および ISO/IEC 10646 では通常ラテン文字でエンコードされています)。これらの変種は、言語タグにおいて、文字、発音記号、二重字/三重字をデフォルトの文字群として異なる方法で分析したり、文字の大文字小文字の規則に違いを持たせたりすることで、正書法上または意味上の違いを明らかにするのに役立つ場合があります。
2文字の地域サブタグは、ISO 3166-1で割り当てられた、または「例外的に予約された」コードに基づいています。ISO 3166保守機関が、以前別の国に割り当てられていたコードを再割り当てする場合、そのコードに対応する既存のBCP 47サブタグはその意味を維持し、UN M.49に基づく新しい地域サブタグが新しい国に登録されます。UN M.49は、南米などの地理的地域に対する数値地域サブタグのソースでもあります005。経済地域に対するUN M.49コードは使用できません。
地域サブタグは、特定の地域で使用されている言語の変種を指定するために使用されます。地域サブタグは、その変種が地域的な性質のものであり、関係する国を特定することで適切に表現できる場合に適しています。例えば、イギリス英語（en-GB）とアメリカ英語（en-US ）を区別する場合などです。簡体字と繁体字のように、違いが文字体系または文字体系の変種である場合は、地域サブタグではなく文字体系サブタグで表現する必要があります。この例では、zh-CN/zh-SG/zh-MYおよびzh-TW/zh-HK/zh-MOの代わりにzh-Hansおよびzh-Hant を使用する必要があります。
地域変種とみなせる言語に対して、明確な言語サブタグが存在する場合、言語と地域の組み合わせではなく、より具体的なサブタグを使用する方が望ましい場合が多い。例えば、ar-DZ（アルジェリアで使用されるアラビア語）は、 arq （アルジェリア口語アラビア語）と表現する方が適切かもしれない。
言語識別に関する意見の相違は、BCP 47 およびそれを支えるコア標準にも及ぶ可能性があります。例えば、パンジャブ語話者の中には、ISO 639-3 の [pan] "パンジャブ語" と [pnb] "西パンジャブ語" の区別は偽りである（つまり、両者は同じ言語である）と考える人もいます。また、アラビア文字のサブバリエーションはISO 15924 で個別にエンコードされるべきである（例えば、ラテン文字のフラクトゥール体やゲール体のように）と考え、BCP 47 はこれらの見解を反映するか、あるいはこれらの点に関してコア標準を覆すべきだと考える人もいます。
BCP 47 はこの種の判断をコア基準に委ねており、コア基準を覆したり、取って代わろうとはしていません。バリアント サブタグと (理論的には) プライマリー ランゲージ サブタグは個別に登録できますが、コア基準に矛盾するような方法では登録できません。[ 20 ]
拡張サブタグ（拡張言語サブタグと混同しないように）を使用すると、言語タグに追加情報を付加できます。この情報は必ずしも言語を識別するために用いられるものではありません。拡張サブタグの用途の一つとして、カレンダーや通貨などの地域情報をエンコードすることが挙げられます。
拡張サブタグは、ハイフンで区切られた複数の文字列で構成され、先頭は単一の文字（ x以外の文字）で始まります。この単一の文字はシングルトンと呼ばれます。各拡張は、それぞれ独自のIETF RFCで記述されており、その拡張のデータを管理する登録機関が特定されています。IANAはシングルトンの割り当てを担当しています。
2014年1月現在、2件の延長が認められている。
拡張機能Tを使用すると、言語タグに、タグ付けされたデータがどのように音訳、転写、またはその他の方法で変換されたかに関する情報を含めることができます。たとえば、en-t-jpタグは、元の日本語から翻訳された英語コンテンツに使用できます。追加のサブストリングは、翻訳が機械的に行われたか、または公開された標準に従って行われたかを示すことができます。
拡張機能Tは、2012年2月に公開された情報RFC 6497で説明されています。登録機関はUnicodeコンソーシアムです。[ 21 ]
拡張機能 U を使用すると、共通ロケールデータリポジトリ(CLDR)にあるさまざまなロケール属性を言語タグに埋め込むことができます。これらの属性は、必須の 2 文字のキーで構成されるキーワードを使用します。これには、国区分 ( sd、rg )、カレンダー ( ca、fw、hc ) およびタイムゾーン ( tz ) データ、照合順序 ( co )、通貨タイプ ( cu ) および形式 ( cf )、測定単位 ( ms、mu ) および数値システム ( nu )、改行 ( lb、lw、ss、dx )、絵文字表示 ( em ) が含まれ、必要に応じて、該当するハイフン付きタイプが続きます。
例としては以下のようなものがあります。
拡張機能 U は、2010 年 12 月に公開された情報 RFC 6067 で説明されています。登録機関はUnicode コンソーシアムです。UTS 35 として公開されているそのLDML仕様は、登録された属性とキーワードのドキュメントとして機能します。[ 22 ]