/
948.txt
190 lines (137 loc) · 8.66 KB
/
948.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
*言語情報の記憶と伝達
[1] 言語情報は使用されている[[文字]]そのものやその並びからある程度の推定は出来ますが、
完全には不可能です。
ですから、何らかの形で[[メタ情報]]を保持できる環境では言語情報を内容とセットで扱うようにするのが普通になっています。
データの記憶や伝達は階層構造になっているのが現在では一般的です。
その様々な階層で言語情報を保持していることがあります。
[[#comment]]
** ファイル・システム
[2] 言語情報を直接保存できる[[ファイル・システム]]は聞きませんが、
[[ファイル名]]の一部として運用上情報を保持していることがあります。
例:
-[SAMP(file)[foo.ja.txt]]
-[SAMP(file)[bar.html.en]]
例えば [[Apache]]
は、この[[接尾辞]]形式の言語情報を扱うことができます。
- [11] [[SGML]] の[[公的公開識別子]]の[[公開文言語]]の指定もこの分類に近いでしょう。 例: [SAMP(SGML)[-//W3C//DTD HTML 4.01//EN]]
[[#comment]]
** 転送プロトコル
[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]]
にある[[言語タグ]]を使って、
任意の文字列に言語情報を与えられます。
しかし[[文字コード]]の層で言語情報を与えることには批判も多く
([[plain-text]] が plain でなくなる)、
現在では非推奨とされています。
実装もほとんどありません。
- [6] 例: [SAMP[[CODE(char)[LANGUAGE TAG]][CODE(char)[TAG j]][CODE(char)[TAG a]]こんにちは[CODE(char)[LANGUAGE TAG]][CODE(char)[CANCEL TAG]]]]
- [13] 何の情報もないときに、文字の種類によっては言語を推定することができる場合もあります。確率的なものになってしまいますし、基本[[ラテン文字]]なんてほとんど無情報だったりはしますが、利用者の少ない用字系なら役に立つ情報かもしれません。
[[#comment]]
* 言語情報の指定の精度
[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]]
程度の基準を決めておけば、現実に実行可能で、しかも有益そうです。
* 言語情報の記述
[22] [[言語符号]]も参照。
[FIG(short list)[ [21] [[言語情報]]の記述法
- [CODE[lang=""]]
- [CODE[Content-Language]]
- [[言語タグ付き文字列]]
- [[Unicode言語タグ]]
- [[PDFの言語エスケープシーケンス]]
- [[言語指定コード]]
-[[アプリリソース]]
]FIG]
* 言語情報の利用
[FIG(short list)[ [10] [[言語情報]]の用途
- [[グリフの選択]]
- [[内容折衝]]
- [[自然言語処理]]の辞書やアルゴリズムの選択
]FIG]
* 言語情報によるレンダリングの変化
[FIG(short list)[ [19] [[文字のレンダリング]]と[[言語]]
- [[CJK統合漢字]]
- [[結合文字]]
- [[ドイツ文字]]
- [[句読点]]
- [[・・・]]
- [[EAW]]
- [[用字系タグ]]
- [[言語系タグ]]
- [[中華フォント問題]]
]FIG]
[HISTORY[
[20]
[[Unicode言語タグ]]をフォント選択に使えることとされていました。
[27]
歴史的には [[ISO/IEC 2022]] [[図形文字集合]]の違い、
[[TRONコード]]の面の違い、
[[Windowsコードページ]]の違いや [[ESC:]]、
[[IANA charset]]
といったものが[[言語]]に応じた[[グリフ]]の選択に活用されていました。
]HISTORY]
* 言語の折衝
[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>
*メモ