[1] 言語情報は使用されている文字そのものやその並びからある程度の推定は出来ますが、 完全には不可能です。 ですから、何らかの形でメタ情報を保持できる環境では言語情報を内容とセットで扱うようにするのが普通になっています。
データの記憶や伝達は階層構造になっているのが現在では一般的です。 その様々な階層で言語情報を保持していることがあります。
[2] 言語情報を直接保存できるファイル・システムは聞きませんが、 ファイル名の一部として運用上情報を保持していることがあります。 例:
[3] MIME や HTTP
では、 Content-Language:
欄で言語情報を伝達できます。
Content-Features
+ 特徴札 てな方法もあるわな。
[4] HTML では、ほとんどの要素型に存在する
lang
属性で言語情報を指定できます。
XML では、 xml:lang
属性を同様に利用できます。
木構造でこれらの属性を使うと、 言語が入り組んだ文にも適当に言語情報を与えることが出来ます。 例:
[5] UCS の SPP にある言語タグを使って、 任意の文字列に言語情報を与えられます。
しかし文字コードの層で言語情報を与えることには批判も多く (plain-text が plain でなくなる)、 現在では非推奨とされています。 実装もほとんどありません。
LANGUAGE TAG
TAG j
TAG a
こんにちはLANGUAGE TAG
CANCEL TAG
[15] 特に文書をマーク付けする際に問題となるのは、 どの程度の精度で自然言語に関する情報を付与するべきであるかです。 例えば日本語で書かれた文章の中に英語で書かれた引用文が含まれている場合にそれを明示する必要があるのか、 英語で書かれた部分が1単語だけの場合はどうするべきなのか、 ということが問題になります。
[16] すべての言語情報を明示するべきという意見: もちろん、可能であればすべての自然言語情報を記述できれば、 それに越したことはありません。それによって機械翻訳をしたり、 利用者に辞書を提供する時の参考にしたり、 ハイフン付けや照合など言語によって異なる習慣を正しく処理したりできます。
すべて記述するべきとする意見の例:
しかし、これは、大部分がある言語で書かれていて、 一部分だけ異なる言語で書かれているのであれば容易に実現できますが、 日本語で書かれた英語版ソフトウェアの使用方法の解説のように、 言語の混じり具合が高いと言語情報の記述だけで一苦労です。
[17]
更に、言語情報を細かく記述することは、必然的に使用する言語についての
(たぶん必要以上に) 詳細な考察を要求することにもなります。
日本語のように異言語の語彙を採り入れやすい言語では重大な問題で、
文章を書きながら使用する単語が異言語の語彙なのか、
外来語 (すでに日本語と課した異言語由来の語)
なのか、とわざわざ考えなければなりません。
その判断基準はともすれば論争の種ともなりかねません。
(異言語の単語を片仮名表記したらもう日本語でしょうか? まさか。ではカステラ
は日本語ではありませんか? その境界は一体どこにあるのでしょう?)
実際のところこのような境界例を正確
に記述したところで、
応用上有意義かというとそうでもなさそうです。
[18] 特に関心のある部分だけ記述する:
マーク付け言語の出発点に立ち戻って、
必要ならば記述する
というのはどうでしょうか。
例えば、
程度の基準を決めておけば、現実に実行可能で、しかも有益そうです。
[20] Unicode言語タグをフォント選択に使えることとされていました。
[27] 歴史的には ISO/IEC 2022 図形文字集合の違い、 TRONコードの面の違い、 Windowsコードページの違いや ESC:、 IANA charset といったものが言語に応じたグリフの選択に活用されていました。
[24] HTTP の Accept-Language
のように言語 (やロケール)
の希望を記述し折衝する仕組みはいろいろとあるのですが、
多くのプロトコルは希望をどう解決するべきかを実装に委ねています。
[25] 言語 (やロケール) はその記述自体がどうしても言語タグのような複雑な構造になるので、 希望する言語の一覧と提供できる言語の一覧から最良の一致を選ぶ一般化された実装は案外難しいものです。
[26] 言語範囲, Accept-Language
も参照。
[23] 言語と地域の解決の概要 | Android デベロッパー | Android Developers, , https://developer.android.com/guide/topics/resources/multilingual-support