x0

拡張 t (言語タグ)

[12] 言語タグ拡張t」は、翻訳転写など変形の方法を記述するものです。

目次

  1. 仕様書
  2. 構文
  3. 変換元の言語タグ
  4. 追加情報欄
  5. m0
  6. i0
  7. k0
  8. t0
  9. s0
  10. d0
  11. h0
    1. h1
  12. x0
  13. 適合性
  14. 拡張と安定性
  15. 歴史
  16. 関連

仕様書#

構文#

[21] t 拡張は、それを表す t という部分タグの後に、 言語タグをつなげたものです。言語タグは変換元の言語を表しますが、省略できます。 は変換についての追加情報を表し、任意の個数記述できます。ただし言語タグを省略した場合は、 最低1つはが必要です。 >>5

[46] 大文字小文字は区別しませんが、 小文字正準形です >>5

変換元の言語タグ#

[13] 変換元として t 拡張内に埋め込まれる言語タグは、正規かつ妥当かつ正準形なければなりません。 また、拡張私用は含んではなりません>>5 なおここで「正規」とは、 irregular でなく regular一致することをいいます。

[14] これらの制限により、1文字の部分タグ (i, x, u など) が含まれることはありません。1文字の部分タグ拡張私用の区切りとして使われるので、 t 拡張内に含めることは原理上できません。更に、 RFC 3066 までに IANA に登録され、 RFC 4646 以後の正規言語タグの構文に合致しないタグや、 未登録のタグや正準形でないタグは使えないことになります。この辺りは少し厳し目ですね。なお、 大文字小文字の違いは正準形か否かとは独立しているので、問題となりません。

[15] 用字系だけを指定したい時は、言語部分タグとして und を使います >>5

追加情報欄#

[18] 変換についての追加情報を任意の個数、「 (field) 」として含めることができます。 欄は先頭の部分タグとしてラテン文字数字の2文字を使って表します。 この先頭の部分タグ欄分離子 (field separator) といいます。 >>5

[20] ラテン文字の後に数字が来る2文字の部分タグは、拡張私用を除き言語タグの他の部分で使われることがないので、変換元の言語タグの指定と明確に区別できます。

[22]は、欄分離子のあと、3-8文字のラテン文字数字で構成する部分タグが1つ以上必要です。 >>5 それらの部分タグの意味はの種類により異なります。

[19] 例えば und-Cyrl-t-und-latn-m0-ungegn-2007UNGEGN の2007年版の転写法を用いてラテン文字から変換したキリル文字を表します。

[23] 同じ欄分離子を1つの言語タグで複数回使ってはなりません同士の順序には意味はありませんが、アルファベット順整列したものを正準形とします。 >>5

[24] アルファベット順というのは、 ASCII 順ということでいいのでしょうか。
[26] の一覧

[27] の定義は LDML で規定されることになっていますが、実際には XML ファイルの構文が定義されているだけで、 その意味は XML ファイル中に簡単に説明されているだけです。

u 拡張はもっと詳しい説明があります。

[28] t 拡張の定義は http://unicode.org/repos/cldr/trunk/common/bcp47/transform.xml に含まれると説明されていますが、実際にはごとに別のファイルに含まれています。

m0#

[29] m0 は変換方式を表します >>5, >>35

[30] このは最初に定義されたもので、 RFC 6497 にも説明があります。 RFC は他の場所の定義を要約したような体になっていますが、実際には RFC が最も詳しい説明のようです・・・。

[31] このに属する部分タグ数字だけで構成するものは、日付を表すことになっています。 その場合、他の部分タグなければならず、最後の部分タグなければならず、 4桁でを表すか、6桁で年月を表すか、8桁で年月日を表すかのいずれかでなければならず、 できるだけ短くするべきです。この日付自体、必要な時だけ使うべきです>>5

[32] この日付の表現が XML ファイルに定義されなくても使っても良いものなのかどうかは明確ではありません。 勝手に使っても良いとは書いてありませんが、現時点では RFC で例示されているものも含め、 XML ファイルには日付付きの値は登録されていません。

[33] 例えば und-Hebr-t-und-latn-m0-ungegn-1977UNGEGN の1977年版転写法によりラテン文字ヘブライ文字にしたものを表します。

i0#

[36] i0 IME を表します >>37

k0#

[38] k0 鍵盤を表します >>39

t0#

[40] t0 機械翻訳を表します >>40

s0#

[47] s0 欄は、 アクセント処理、適切な引用符の選択、 十六進数表記といったような種々の変形(元)を表します。 「Transform source for non-languages/scripts.」と説明されています。

d0#

[47] d0 欄は、 正規化case foldingアクセント処理、適切な引用符の選択、 十六進数表記といったような種々の変形(先)を表します。 「Transform destination for non-languages/scripts.」と説明されています。

h0#

[48] 「Language mixed into hybrid language tag」を表すと説明されています。

[49] 値は妥当な言語タグでなければなりません。

[50] es-t-h0-enSpanglish を表すとされています。

h1#

[51] 「Language mixed into hybrid translation source」を表すと説明されています。

[52] 値は妥当な言語タグでなければなりません。

[53] 「-t- subtag」 (t 直後) も妥当な言語タグでなければなりません。

[54] es-t-hi-h1-enHinglish から翻訳された Spanish を表すとされています。

x0#

[42] x0 私用です >>43

[44] 構文的に適切な任意の部分タグの列を使うことができます >>43。すなわち、 3-8文字の英数字の部分タグを任意個指定できます。

適合性#

[45] t 拡張の構文やその他の要件は RFC にいくつもありますが、 BCP 47 のいう「拡張妥当性」には明確に言及されていません。例えば未登録のを使うと拡張非妥当となるのかは不明瞭です。

拡張と安定性#

[25] 新たなや値の定義は Unicode CLDR 技術委員会の手続きにより LDML に追加することで行われるとされています。 >>5

[34] 構文や意味を変更する場合には RFC が必要なものの、そのような安定性を損なう変更は Unicode Consortium の方針に反するとされています。 >>5

歴史#

[58] 開発初期には拡張 s と拡張 t でわけて記述する案もありました。 >>57

[3] 付けで IANA に登録されています >>4

#

[8] >>7 より:

  • "zh-t-i0-pinyin", to indicate Chinese text generated with a pinyin input method
  • "en-t-k0-dvorak", to identify a Dvorak keyboard for English
  • "it-t-k0-osx-extended", to request an extended Mac keyboard for Italian

私用のタグの例:

  • "ru-t-en-x0-mobile", to indicate a translation from English to Russian for use on a mobile device, or
  • "ja-t-de-m0-und-x0-medical", to identify a machine translation from German to Japanese with a specialized dictionary for medical terms.

[16] >>5 より:

関連#

[17] マーク付け言語などで変換の前後の言語タグをそれぞれ記述できるときには t 拡張は使う必要はありません >>5