*言語情報の記憶と伝達

[1] 言語情報は使用されている[[文字]]そのものやその並びからある程度の推定は出来ますが、
完全には不可能です。
ですから、何らかの形で[[メタ情報]]を保持できる環境では言語情報を内容とセットで扱うようにするのが普通になっています。

データの記憶や伝達は階層構造になっているのが現在では一般的です。
その様々な階層で言語情報を保持していることがあります。


-*-*-

[22] 普通、[[言語]]は何らかの[[言語符号]]の体系で記述します。[[言語符号]]も参照。

[40] [[言語符号]]を含める方法は各種の[[データ形式]]にそれぞれ決められていて、
いろいろな手法があります。

[FIG(short list)[ [21] [[言語情報]]の記述法
- [CODE[lang=""]]
- [CODE[Content-Language]]
- [[言語タグ付き文字列]]
- [[Unicode言語タグ]]
- [[PDFの言語エスケープシーケンス]]
- [[言語指定コード]]
-[[アプリリソース]]

]FIG]

** ファイル・システム

[2] 
[[言語情報]]を直接保存できる[[ファイル・システム]]は聞きませんが、
[[ファイル名]]の一部として運用上情報を保持していることがあります。

[EG[
[36] 例:
-[SAMP(file)[foo.ja.txt]]
-[SAMP(file)[bar.html.en]]
]EG]

[34] 
例えば [CITE[Apache]]
は、この[[接尾辞]]形式の言語情報を扱うことができます。
[[内容折衝]]や [CODE[Content-Language:]] [[ヘッダー]]に使います。

;; [35] しかし後続のサーバー、例えば [CITE[[[nginx]]]] はこれを踏襲していません。

** 識別子

[38] [[資源]]を[[識別]]する[[番地]]やその他の[[識別子]]に[[言語情報]]の欄が含まれることがあります。

[11] [[SGML]] の[[公的公開識別子]]の[[公開文言語]]の指定がこれに該当します。 

[EG[
[37] 例: [SAMP(SGML)[-//W3C//DTD HTML 4.01//EN]]
]EG]

[39] 
[[HTTP(S) URL]] の [[URL path]] に[[言語]]を含めることがあります (c.f. >>34) が、
[[規格]]上の定めがあるものではありませんから、あくまで[[サーバー]]管理者の裁量によるもので、
一般性はありません。


** 転送プロトコル

[3] [[MIME]] や [[HTTP]]
では、 [CODE[[[Content-Language:]]]]
欄で言語情報を伝達できます。

- [7] 例: [SAMP[Content-Language: ja,en]]
- [8] 例: [SAMP(MIME)[=?us-ascii*en?q?Hello!?=]]
- [9] >>8 は MIME の [[encoded-word]] の例。
- [10] MIME の[[引数]]の例: [SAMP(MIME)[filename*=us-ascii'en'foo.txt]]
- [12] [CODE(MIME)[[[Content-Features]]]] + [[特徴札]] てな方法もあるわな。
[[#comment]]

**マーク付け言語

[4] [[HTML]] では、ほとんどの[[要素型]]に存在する
[CODE(HTML)[[[lang]]]] 属性で言語情報を指定できます。

[[XML]] では、 [CODE(XML)[[[xml]]:[[lang]]]]
属性を同様に利用できます。

木構造でこれらの属性を使うと、
言語が入り組んだ文にも適当に言語情報を与えることが出来ます。
例:
-[SAMP(HTML)[<p xml:lang="ja">彼は、<q xml:lang="en">Hello!</q>といいました。</p>]]
-[SAMP(XML)[<Alt><p xml:lang="ja">こんにちは</p><p xml:lang="en">Hello</p></Alt>]]

- [14] ''HTMLの言語情報に関する覚え書き'' <http://www.asahi-net.or.jp/~wq6k-yn/lang.html> : 文字と言語の関係と、それを明示することについての優れた解説です。1998年という今となっては大昔に書かれた文章ですが、古さを感じさせません。この文章が取り上げている問題が未だにまったく解決されていないのがとても残念です。
[[#comment]]

** 符号化文字集合

[5] [[UCS]] の [[SPP]]
にある[[言語タグ][Unicode言語タグ]]を使って、
任意の[[文字列]]に[[言語情報]]を与えられます。

[33] 
しかし[[文字コード]]の層で言語情報を与えることには批判も多く
([[plain-text]] が plain でなくなる)、
現在では非推奨とされています。
実装もほとんどありません。

[EG[
[6] 例: [SAMP[[CODE(char)[LANGUAGE TAG]][CODE(char)[TAG j]][CODE(char)[TAG a]]こんにちは[CODE(char)[LANGUAGE TAG]][CODE(char)[CANCEL TAG]]]]
]EG]

[13] 何の情報もないときに、文字の種類によっては言語を推定することができる場合もあります。確率的なものになってしまいますし、基本[[ラテン文字]]なんてほとんど無情報だったりはしますが、利用者の少ない用字系なら役に立つ情報かもしれません。

[41] 
[[言語情報]]を組み込んだ[[文字コード]]:
[[TRONコード]],
[[skf内部コード]]


* 言語情報の指定の精度

[15]
特に[[文書]]を[[マーク付け]]する際に問題となるのは、
どの程度の精度で[[自然言語]]に関する情報を付与するべきであるかです。
例えば[[日本語]]で書かれた[[文章]]の中に[[英語]]で書かれた[[引用文]]が含まれている場合にそれを明示する必要があるのか、
[[英語]]で書かれた部分が1単語だけの場合はどうするべきなのか、
ということが問題になります。

[16] '''すべての言語情報を明示するべきという意見''':
もちろん、可能であればすべての[[自然言語]]情報を記述できれば、
それに越したことはありません。それによって[[機械翻訳]]をしたり、
[[利用者]]に[[辞書]]を提供する時の参考にしたり、
[[ハイフン付け]]や[[照合]]など言語によって異なる習慣を正しく処理したりできます。

すべて記述するべきとする意見の例:
- [CITE@en[HTML Techniques for WCAG 2.0]]
<http://www.w3.org/TR/2005/WD-WCAG20-HTML-TECHS-20050630/#lang-att_change>

しかし、これは、大部分がある言語で書かれていて、
一部分だけ異なる言語で書かれているのであれば容易に実現できますが、
[[日本語]]で書かれた[[英語]]版ソフトウェアの使用方法の解説のように、
言語の混じり具合が高いと言語情報の記述だけで一苦労です。

[17]
更に、言語情報を細かく記述することは、必然的に使用する言語についての
(たぶん必要以上に) 詳細な考察を要求することにもなります。
[[日本語]]のように異言語の語彙を採り入れやすい言語では重大な問題で、
文章を書きながら使用する単語が異言語の語彙なのか、
[[外来語]] (すでに[[日本語]]と課した異言語由来の語) 
なのか、とわざわざ考えなければなりません。
その判断基準はともすれば論争の種ともなりかねません。
[WEAK[(異言語の単語を片仮名表記したらもう日本語でしょうか? まさか。では[Q[[[カステラ]]]]は日本語ではありませんか? その境界は一体どこにあるのでしょう?)]]
実際のところこのような境界例を[Q[正確]]に記述したところで、
応用上有意義かというとそうでもなさそうです。

[18] '''特に関心のある部分だけ記述する''':
[[マーク付け言語]]の出発点に立ち戻って、
[Q[必要ならば記述する]]というのはどうでしょうか。
例えば、
- [[文書]]全体の言語情報があると[[文書]]全体のレンダリングや[[内容折衝]]の役に立ちそうだから記述する
- 定義する言葉や略語は索引や辞書絡みで役に立ちそうだから記述する
- [[引用文]]も[ABBR[(ry]]

程度の基準を決めておけば、現実に実行可能で、しかも有益そうです。



* 言語情報の利用

[FIG(short list)[ [19] [[言語情報]]の用途
- [[グリフの選択]]
- [[内容折衝]]
- [[自然言語処理]]の辞書やアルゴリズムの選択
- [[文字コードの判定]]
- [[ロケール]]

]FIG]


* 言語情報によるレンダリングの変化

[30] 
同じとされる[[文字]]でも[[言語]]によって違った形で使われていることがあります。
従って[[文字のレンダリング]]の過程には[[言語情報によるフォント選択]]、
[[言語情報によるグリフ選択]]が必要となります。
また、[[文字列]]には[[言語情報]]が必要となります。

[31] 
[[言語]]によって変化するのは主として[[グリフの選択]] (によって選ばれる[[グリフ]])
ですが、それだけに留まりません。[[グリフ]]と連動して[[メトリクス][OpenTypeの座標]]も変化させる必要が出てくることが多いですし、
[[合字]]化の有無、
[[縦書き]]表示と[[横書き]]表示で[[グリフ]]を変化させるか否か、
[[傍線]]、[[傍点]]、[[ルビ]]の位置、
その他周辺の諸事項にも[[言語情報]]の影響が及びます。


[SEE[ [[言語情報によるフォント選択]], [[言語情報によるグリフ選択]] ]]

[EG[
[20]  
[[Unicode言語タグ]]をフォント選択に使えることとされていました。
]EG]

* 重層的な言語情報の利用

[28] 
[[HTML]] や [[XML]] では[[要素構造]]の任意の位置に[[言語情報]]
([CODE[lang=""]], [CODE[xml:lang=""]])
を与えることができます。
[[木構造]]に応じて解釈されます。
[SEE[ [[lang=""]] ]]

[29] 
[[HTTP]] 等には [CODE[Content-Language:]] 
[[ヘッダー]]で[[プロトコル]]レベルで[[言語情報]]を与えることができ、
転送されるデータでも [[HTML]] の [CODE[lang=""]] 等、
[[言語情報]]を与えることができます。
[SEE[ [[Content-Language:]], [[lang=""]] ]]
[[HTML]] は両方が指定された場合の処理方法を定めていますが、
プロトコルの組み合わせによっては明確な規定がないこともあります。

* 言語の折衝

[24] [[HTTP]] の [CODE[Accept-Language]] のように[[言語]] (や[[ロケール]])
の[[希望を記述][能力の記述]]し[[折衝][内容折衝]]する仕組みはいろいろとあるのですが、
多くの[[プロトコル]]は希望をどう解決するべきかを実装に委ねています。

[25] 
[[言語]] (や[[ロケール]]) はその記述自体がどうしても[[言語タグ]]のような複雑な構造になるので、
希望する[[言語]]の一覧と提供できる[[言語]]の一覧から最良の[[一致]]を選ぶ一般化された実装は案外難しいものです。

[26] [[言語範囲]], [CODE[Accept-Language]], [[言語タグの一致]], [[利用者の言語]]も参照。

[23] [CITE@ja[言語と地域の解決の概要 | Android デベロッパー | [[Android]] Developers]], [TIME[2022-09-02T09:24:09.000Z]], [TIME[2022-09-03T08:46:11.165Z]] <https://developer.android.com/guide/topics/resources/multilingual-support>

* 言語情報と一致 (検索) の関係

@@

[32] 失敗事案: [[言語タグ付き文字列]]


* 関連


[SEE[ [[利用者の言語]] ]]

*メモ