und

言語部分タグ (一次言語部分タグ)

[93] 言語タグの1つ目の部分タグ言語 (language) です。 言語タグ全体が言語を表す識別子ですが、言語部分タグは特に狭義の言語を表します。

[94] 例外として、1つ目の部分タグx である場合 (私用) と i である場合 (祖父) があります。 RFC 5646 2.2.1. (後述)
[271] 言語タグ全般については、「言語タグ」の項も参照してください。

仕様書

呼称

[108] 言語部分タグは、特に他と区別する必要がある場合は一次 (primary) 言語部分タグ RFC 5646 と呼ばれています。

[274] Unicode言語識別子Unicodeロケール識別子では基底言語符号 (base language code) unicode_language_subtag とも呼んでいます >>280

文脈

[7] IETF言語タグの先頭で必ず1個だけ使うことができます。

[8] ScriptLangTag の先頭で使うことができます。省略可能です。

[18] 地域部分タグとの組合せについては、 言語部分タグと地域部分タグの組合せを参照。

語彙

[95] 2文字のラテン文字である言語部分タグは、

... で定義、またはそれに基づき登録されたものを更に IANA に登録したものです。 RFC 4646 2.2.1., RFC 5646 2.2.1.

[96] 3文字のラテン文字である言語部分タグは、

... のいずれかにおいて定義、またはそれに基づき登録されたものを更に IANA に登録したものです。 RFC 4646 2.2.1., RFC 5646 2.2.1.

[101] ISO 639 で2文字の言語符号と3文字の言語符号の両方が定義されている場合、 2文字の方だけが IANA に登録され、言語タグで使ってもよいこととなっています。 既に3文字言語符号が定義されている言語に新たに2文字言語符号が定義されることがあると非互換性が生じてしまいますが、 ISO 639/RA-JAC はそのような2文字言語符号の追加は行わないと表明しています。 RFC 4646 2.2.1., RFC 5646 2.2.1.
[102] ISO 639-2/T (Terminology) 言語符号ISO 639-2/B (Bibliographic) 言語符号で2種類の3文字言語符号がある場合、 Terminology の方だけが IANA に登録され、言語タグで使ってもよいこととなっています。ただし現時点で2種類異なっている言語はすべて 2文字言語符号が定義されており、従って >>101 により3文字言語符号は使えません。 RFC 4646 2.2.1., RFC 5646 2.2.1.

[97] 4文字のラテン文字である言語部分タグは、将来の拡張のために予約されています。 RFC 4646 2.2.1., RFC 5646 2.2.1.

[98] 5文字から8文字のラテン文字である言語部分タグは、 IANA によって登録された言語です。 ただし、 IANA に登録しようする前に ISO 639 に従い登録しようと試みなければならない RFC 5646 2.2.1. (以前は試みるべきである RFC 4646 2.2.1.)、またその登録に失敗したものは IANA にも登録されそうにないだろう、とされています。 RFC 4646 2.2.1., RFC 5646 2.2.1.

[99] 自ら存在意義のない登録制度作って何がしたいんだろう・・・。

[100] 数字その他の文字や、9文字以上の部分タグを先頭に使うことは認められていません。 xi 以外の1文字の部分タグも認められていません。

mul

[216] mul (複数の言語) は、複数個の言語タグを指定できるなど他に方法がある時は使うべきではありませんRFC 3066 2.3, RFC 4646 4.1., RFC 5646 4.1.

[19] 「複数の言語」といってもいろいろな意味があり得ます。 mul

und

[217] und (未決定) は、 言語が必須である場合を除き使うべきではありませんRFC 3066 2.3, RFC 4646 4.1., RFC 5646 4.1.

[10] なぜ敢えてこれを SHOULD 要件という強い規定にしたのかは謎です。 普通はある言語だと指定したい要求があるから指定する、 それがなければわざわざ指定しないわけであって、 雉も鳴かずば撃たれまい、 この規定はあってもなくても良さそうなものです。 むしろこの規定のせいで、正当な理由で指定したいときにしづらくなっている感があります。 (SHOULD なので正当な理由があれば使ってもいいのですが...) 言語不詳だと指定したい気持ちがあるなら、 それは正当な理由ですから、気にせず und を使うべきです。

[11] わざわざ「日本語を en とするべきではない」と規定するようなもので、 おかしなことは言っていないのですが、言っていること自体がなんだかおかしなことです。

[287] RFC 6497 は、言語を特に問題とせず、用字系についてのみ記述したいとき、 言語部分タグund を使うとしています。

[288] 例えば und-Latn-t-und-cyrlキリル文字からラテン文字転写されたものを表します。

[6] weekOfPreference 要素locales 属性では、 ロケール固有の指定がない場合に適用される既定値を記述するときに、 und が使われます。

[9] Movie Atoms, , https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-SW16

RFC 4646 (BCP 47) 言語タグを採用。

適当な値がなければ und を使えるとしています。

[218] HTMLlang 属性XMLxml:lang 属性では空文字列により言語情報無しを表すことができます。
[12] ScriptLangTag言語部分タグを明示したくないとき省略できます。

[29] [malar_braille] BCP 47 tag modified, ramesh-k, , https://github.com/keymanapp/keyboards/commit/d429c808315b27ec520604a37dc546d17d619654

[30] >>29点字入力鍵盤。元は und-Brai で表していたものを、 思いつく言語タグ + Brai の羅列に置き換えた。本当にこれでええんか?

mis

[221] mis (未符号化) は、言語はわかっているものの言語符号が無いことを表していますが、 言語タグでは使うべきではありませんund私用部分タグを使うべきです。 RFC 5646 4.1.

[222]言語タグの安定性を損なう」ことが理由 RFC 5646 4.1. とされていますが、情報交換の有用性を鑑みると und は不適切なんじゃないでしょうか・・・。私用を使うのがよいですね・・・。

[3] フィクション言語などはこの言語符号が適当に思われます。

[4] フィクションであっても言語学的に詳細な設定があるものは、 言語符号が割り当てられている (または将来的に割り当てられる) 可能性があります。 しかしそこまで凝っていない、断片的に利用例がある程度の言語の方が圧倒的に多数です。 そのような言語には、言語タグが必要だとしても私用言語タグを都度作成するほどのものとも思えません (もちろん需要があれば都度作成しても良いとは思いますが)。

[28] 人工言語参照。

zxx

[219] 歌詞の無い音楽や非言語的な音声、計算機言語などの自然言語に属さないものについては、 zxx (非言語的、非適用可能) 言語部分タグを使うことができます。

[5] しかし実用上はプログラミング言語英語など元になった言語として扱う方が便利なこともあるかもしれません。

[20] 地図作成 - 地図作成 - HERE Developer, , https://jp.developer.here.com/documentation/geojson-map-components-cartography/data_spec_guide/common/globals.html#languagebcp47

[21] >>20私用部分タグと組み合わせた zxx-x-iat を使っています。

root

[273] 言語タグの変種である Unicode言語識別子Unicodeロケール識別子は、 言語部分タグに相当する部分で特別な値 root を使っています。

[1] 言語タグ自体では root は認められていません。

私用

[276] >>96 には ISO 639-2 による私用qaa ... qtz も含まれています RFC 4646 2.2.1., RFC 5646 2.2.1.

[277] Unicode言語識別子Unicodeロケール識別子はそのうちの qfz ... qtz について意味を定義しないので他の応用が使っても問題ないとしています >>279。逆に言えばそれ以外の私用符号は (現在は未定義ですが) 将来的に特別な意味で使われる可能性があります。

[2] いずれにせよ、私用の値は相互運用性の問題の元ですから、 使うべきではありません。


[14] ConLang Code Registry (CLCR) では人工言語用の言語符号を私用3文字符号に割り当てています。 >>13

[15] ISO に正式な符号が割り当てられたことで取り下げ (withdraw) されたものもあります。

[16] long code (長符号) として示されたものは IETF言語タグ (言語部分タグ art + 私用部分タグ) のように見えますが、何の説明もありません。

[17] 似たような別プロジェクトとして、CLAコードがあります。

マクロ言語

[281] Unicode言語識別子Unicodeロケール識別子は互換性のためにいくつかのマクロ言語について、 その全体を指す本来の意味ではなく、代表的な言語を表すことと解釈するとしています >>279。 例えば、 zh中文全体を指すものですが、特に cmn (官話) のことを意味するものとみなしています >>279

[282] このような対応付けの一覧表は XML のデータで提供されています。

その他の値

[40] XSL-FO では言語タグの登場場面である xml:lang 属性値inherit が指定できます。 (XML 的にそんなのありかよ? と思いますが) この値は xml:lang 属性既定値 #IMPLIED を明示した形になります。 >>308

[309] これは XMLIETF言語タグも認めていない、 XSL-FO だけの独自仕様です.

[310] 用字系符号には Zinh という値がありますが、 言語タグでは使うべきではないとされていますし、 言語タグ全体ではなく用字系にだけしか指定できないものです。 inherit に相当するものはIETF言語タグの体系には存在していません。
  • [47] 一部の DOM HTML 実装は、 lang 属性の値で、 HTML の lang 属性に値が明示されていない時には unknown を返すらしいです。

[22] 綜語 / 宇田川浩行 / デライト, 希哲社, https://dlt.kitetu.com/?fg=KNo.F85E/45E0

情報処理では ISO の言語コード・国名コードを独自に拡張し「syn_KTK(三文字),「sy_KT(二文字)を用いる。これにより,同じ情報を一般的な日本語(ja_JP)と,実験的な綜語で訳し分ける事などが可能になる。


[23] デジタルシネマ 名前付け規則 / 付録1ab: 言語コード一覧表 (日本語訳) – シネマテクノロジー, , https://cinematechnology.jp/dcnc/dcnc-appendix-1ab-language-codes

言語コードは ISO 639-1, 639-2, 639-3 に準拠します。

特例として、 “LAS” はラテンアメリカ系スペイン語を表しますが、ISO 639-3 の定義ではラマ語(トーゴで話される言語)を表します。映画配給業界の慣習で “LAS” はラテンアメリカ系スペイン語として既に広く使用されているため、この名前付け規則ではラテンアメリカ系スペイン語として使い続けることにしました。

音声言語名または字幕言語名が記載されていない場合、名前付け規則の言語コードにはXXを使用します。

このコードはContentTitleText要素内でのみ使用します。

Language要素が存在しない場合、音声または字幕言語が存在しないことを意味します。

[24] >>23 この名前付け規則言語コードはその他にも Q から始まる私用符号や、 4字の独自の符号を定めています。それ以外でもいくつか非標準のものが混じってそうな。


[31] skf内部コードやプログラム内部で使われる言語は、 ISO 639-1 の英字2字符号 (大文字) にいくつか追加したものです。 >>32, >>35

  • [34] 0x00 は、 「言語は未規定、または言語を指定していない」です。 >>35
  • [33] NU は、「言語ニュートラル」です。 >>32
  • [36] @N は、「Unicode であり、言語中立である」です。 >>35
  • [37] @U は、 「Unicode でない」です。「言語中立かどうかとは無関係」 です。 >>35
  • [38] EM は、「ヨーロッパ系の混在言語」です。 >>35
  • [39] US は、「米英語」です。 >>35

歴史

[127] 言語部分タグRFC 1766 以来ずっと最初の部分タグとして存在しています。

[269] RFC 1766 は2文字言語符号を使ってもよいとしていました。 RFC 1766 2.

[261] RFC 3066 は2文字言語符号、3文字言語符号を使ってもよいとしていました。 RFC 3066 2.2.

[270] RFC 1766RFC 3066 はその他には私用xIANA 登録用の i を認めており、それ以外はすべて使用禁止とされていました。 RFC 3066 2.2.

[289] RFC 7033 - WebFinger ( ( 版)) https://tools.ietf.org/html/rfc7033#section-4.4.4.4