言語情報の記憶と伝達

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

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

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

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

[21] 言語情報の記述法

ファイル・システム

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

[36] 例:

  • foo.ja.txt
  • bar.html.en

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

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

識別子

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

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

[37] 例: -//W3C//DTD HTML 4.01//EN

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

転送プロトコル

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

マーク付け言語

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

XML では、 xml:lang 属性を同様に利用できます。

木構造でこれらの属性を使うと、 言語が入り組んだ文にも適当に言語情報を与えることが出来ます。 例:

符号化文字集合

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

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

[6] 例: LANGUAGE TAGTAG jTAG aこんにちはLANGUAGE TAGCANCEL TAG

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

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

言語情報の指定の精度

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

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

すべて記述するべきとする意見の例:

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

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

[18] 特に関心のある部分だけ記述する: マーク付け言語の出発点に立ち戻って、 必要ならば記述するというのはどうでしょうか。 例えば、

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

言語情報の利用

[19] 言語情報の用途

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

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

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

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

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

重層的な言語情報の利用

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

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

言語の折衝

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

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

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

[23] 言語と地域の解決の概要 | Android デベロッパー | Android Developers, , https://developer.android.com/guide/topics/resources/multilingual-support

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

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

関連

利用者の言語

メモ