レベル: 初級 Uche Ogbuji (uche@ogbuji.net), Principal Consultant, Fourthought, Inc.
2002年 9月 01日 国際化対応へのサポートはXMLの主要な長所の1つです。しかし残念ながら、内容をローカライズするためのメカニズムを用意しているXML形式は少な過ぎます。このヒントでは、ローカライズを考慮したXML形式の作成方法を説明します。
XMLの主要な長所の1つに、国際化対応へのサポートがあります。その中核の文字セットであるUnicodeは、ヨーロッパのISO-8859変種、日本のShift-JIS、中国のBIG-5など、地域毎によく使われているシステムをサポートするメカニズムを備えています。これは望ましいことです。アプリケーションを最初は地域に限られた視点で開発し、そのあとで国際的展開のために改造すると大変な費用が発生するからです。しかし国際化対応とは、各国文字のレパートリーをサポートするだけに止まるものではありません。情報を言語と国や地域の慣習の特定のきまりに合わせて調整できるように表せることも重要です。これがローカリゼーション と呼ばれるものです。
一般的なローカリゼーション
データ形式自体 (これはXMLが得意とするところですが) に関していえば、日付形式や姓名の順序といったローカリゼーションのいくつかの側面は、XMLの基本的な機能を使って対応が可能です。1つのアプローチは国際標準の形式を使うことです。このよい例が日付です。日付にはISO 8601標準を使用するのが最適です (参考文献を参照)。リスト1 に例が含まれています。
リスト1. 地域 (US) の日付とローカライズされた等価な日付
<?xml version="1.0" encoding="utf-8"?>
<products>
<!-- US-specific date -->
<product release-date="8/18/2002"/>
<!-- ISO-8601 date -->
<product release-date="2002-08-18"/>
</products>
|
ISO-8601の日付の利点の1つは、地域毎の日付の大半の形式と違って、一般的にほとんどのプログラム言語で単純文字列として比較できることです。たとえばほとんどのプログラミング・システムでは、実際の日付とは逆に、文字列 "8/19/2001" は "8/18/2002" よりも大きくなります。ISO-8601形式で等価の "2001-08-19" と "2002-08-18" を比較すると、文字列形式での比較と実際の日付での比較の対応が自然なものになります。ローカライズされたソフトウェアはISO-8601の日付をまず取り扱い、人間が使うフィールドを実際に表示する際には、該当するローカライズされた形式を用いることができます。(XSLT用のよく知られているEXSLT拡張ライブラリーも含めて) ほとんどのプログラム言語がこの変換を当然のようにサポートしています。
ローカリゼーションのもう1つのアプローチは、データを細かく構造化して、地域に合わせて再構成できるようにすることです。名前がそのよい例です。慣習によっては一般に姓が名よりも先になるところがあります (たとえば中国)。リスト2 は、地域のそのような慣習をサポートしやすくするために、データを構造化した例です。
リスト2. ローカリゼーションのために名前を構造化した形式の例
<?xml version="1.0" encoding="utf-8"?>
<signatories>
<!-- The direct approach. -->
<name>Mr. Uche Ogbuji</name>
<!-- Structure to support local conventions -->
<name>
<honorific>Mr.</honorific>
<given>Uche</given>
<family>Ogbuji</family>
</name>
</signatories>
|
直接的なアプローチ (direct approach) で、名前の各部分を慣習に基づいて推測しようとすると、しばしば危険です。名前の一部 (たとえば敬称) が省略されていたらどうなるでしょう ?そのとき姓と名がどういう順序になるのか、推測できますが ?2番目のアプローチを使うと、人間が使うために表示された名前の形式を、地域の慣習に従って再設定することができます。実際には、項目ごとに見込める選択に関して何らかの指示 (たとえば国籍) が与えられれば、姓名ベースで名前の順序を調整することができるでしょう。2番目のアプローチを使うと、いくらか複雑になってオーバーヘッドも大きくなるのは明らかですが、さまざまなレベルのマークアップ構造を選択して複数の慣習をサポートしようとすると、実用性と柔軟性は常にトレードオフの関係になります。
インライン変換
ローカリゼーションのもう1つの一般的な課題は、ラベル、メッセージ、記述などの翻訳を表すことです。XML 1.0は、要素の内容と属性値に使用する言語を指定できます。これを要素単位で設定することができます。リスト3 は、英語の要素とスペイン語の要素を並行して使っているXML文書の例です。
リスト3. ローカライズされた言語の形式の要素をもつXML文書
<?xml version="1.0" encoding="utf-8"?>
<menu>
<item id="A" xml:lang="en">Orange juice</item>
<item id="A" xml:lang="es">Jugo de naranja</item>
<item id="B" xml:lang="en">Toast</item>
<item id="B" xml:lang="es">Pan tostada</item>
</menu>
|
xml:lang 属性はRFC 1766で許可された任意の値をもつことができます。つまり、ここには言語の1次指定を表す値を使用します (英語の場合はen、スペイン語の場合はes など)。言語変種が一般的に使われている地域を追加して、言語をさらに限定することができます (たとえばアメリカ英語の場合はen-US、イギリス英語の場合はen-GB、メキシコ・スペイン語の場合はes-MX)。なお、ここでは名前空間を宣言する必要はありません。xml 名前空間は文書ごとに暗黙に定義されています。また言語の指定は、関係のある要素のすべての子と他の子孫すべての内容に作用するので注意してください。xml:lang 属性がXML仕様で特に触れられていても、実際のスキーマで規定しなければなりません。リスト4 に示すDTDの断片はその例です。
リスト4. xml:langをサポートするDTD
<!ATTLIST item xml:lang NMTOKEN #IMPLIED "en">
|
この宣言によってこの属性のサポートが追加され、この属性が省略された場合に備えてデフォルト値のen がセットアップされます。この例ではid 属性の宣言は省略しました。
まとめ
ローカリゼーションはこのスペースで紹介できたもの以外にたくさんあります。開発者にとってローカリゼーションは、厳重な規則の集合ということではなく、たいていは取り組む姿勢全体の問題です。「自分のコードとデータの中に自分の思い込みで取り入れた慣習に固定されていて、実際には地域によって変わるものはないか ?」ということをいつも自問自答する必要があります。情報にまつわる慣習をできるだけ知り、それをコードに組み込むことは、開発者にとって重要なスキルです。XMLには、使用法に慣れればそれを可能にする有力な基本ツールが揃っています。
参考文献
著者について  | 
| | Uche Ogbuji は、次世代の Web 技術を専門とするサービスの会社である、Uli, LLC の代表者です。Ogbuji 氏は XML、RDF、およびナレッジ管理アプリケーション用のオープン・ソース・プラットフォームである 4Suite の開発リーダーであり、Versa RDF 照会言語の開発リーダーでもあります。ナイジェリア出身のコンピューター・エンジニア兼ライターで、米国コロラド州ボールダー在住です。彼に関して詳しくは、彼のブログである Copia を見てください。 |
記事の評価
| 
