Drupal Commerce(画像はDrupal Commerceのサポート主体のCentarroのもの)のドキュメントを読んでいたら、住所の扱いのところで、CLDRという言葉が出てきた。リンクをたどると、CLDR - Unicode Common Locale Data Repositoryにたどり着いた。あまり深く考えたことのある人は多くないと思うのだが、プログラムで住所を扱うのは実はかなり難しい。国によって郵便番号の体型も違うし、アメリカの州とか日本の都道府県とか、住所によって税の体系が違うケースがあり、商取引を考える時は「地域」を扱えるのが望ましい。さらに、郵便物等で宛先を記載する場合の順序も違う。DrupalのAddress moduleは、社名と氏名を要素として含んでいる。直感的には氏名と住所は別だと考えたくなるが、宛先では、例えば「合同会社ユビキタスライフスタイル研究所 萩原 高行 様」まで記述しないと届かない。日本国内で日本語で考えてしまうと、国際的には全く通用しないシステムになってしまう。その点、DrupalのAddress moduleはかなり良くできていて、日本を指定すると、都道府県のリストが出てくるなど日本の住所構造まで考慮されている。あらためてモジュールのページを確認すると、
- Country list with translations for over 200 locales, provided by CLDR
と書かれている。なんだかんだと言っても、今のITはアメリカ中心で考えられていて、アメリカの人は割と簡単にアメリカのやり方に従えと言ってしまうが実際には使えないことが少なくない。使えなければしょうがないので、例えば住所のデータ構造を拡張し、住所データから宛先を印刷するプログラムを拡張して、日本語の場合は、姓名順、英語の場合は、名姓順にしたりと工夫したりしてきた。やがてグローバル化が進み、同じシステムの中で、世界中の住所を扱う必要が出てきて、さらに、システム間連携が必要になった。生産者のシステムの住所データ構造と物流業者のシステムの住所データ構造、金融機関の住所データ構造が異なれば、大変面倒なので共通化のニーズが高まり、2003年12月に最初のリリースが出されている(wikipedia)。日付の表記も対象になり、"年"、"月"、"日"などの文字の扱いについても記述されている。
メインのXMLファイルは、言語ごとのファイルが作成されている。jaが日本語だ。言語の定義の一部を引用すると
<language type="en">英語</language>
<language type="en_AU">オーストラリア英語</language>
<language type="en_CA">カナダ英語</language>
<language type="en_GB">イギリス英語</language>
<language type="en_GB" alt="short">英語(英国)</language>
<language type="en_US">アメリカ英語</language>
<language type="en_US" alt="short">英語(米国)</language>
<language type="ja">日本語</language>
<language type="zh">中国語</language>
<language type="zh" alt="menu">中国語 (標準語)</language>
<language type="zh_Hans">簡体中国語</language>
<language type="zh_Hans" alt="long">標準中国語 (簡体字)</language>
<language type="zh_Hant">繁体中国語</language>
<language type="zh_Hant" alt="long">標準中国語 (繁体字)</language>
となっている。日本語では、日本語のことを日本語と記し、言語コードはjaとするという意味だ。英語や中国語はもうちょっと複雑だがイメージは掴めるだろう。enのファイルを見ると、
<language type="ja">Japanese</language>
となっている。英語では、日本語（言語コードja）のことをJapaneseと記すという意味だ。
さて、言語意外にもterritoriesというエントリーがある。なぜだかcountriesではない。その一部を見ると得心する。
<territory type="HK">中華人民共和国香港特別行政区</territory>
<territory type="HK" alt="short">香港</territory>
<territory type="JP">日本</territory>
<territory type="MK">北マケドニア</territory>
<territory type="PS">パレスチナ自治区</territory>
<territory type="PS" alt="short">パレスチナ</territory>
<territory type="TW">台湾</territory>
日本のような国では問題は生じないが、中国は台湾の存在を認めない。チベット語はboというコードを持っているが、チベットを表すterritory typeは存在しない。一方、マケドニアは北マケドニアに変わってもMKは変わらない。実は別のファイルには、
<subdivision type="cnhk" draft="contributed">香港</subdivision>
<subdivision type="cntw" draft="contributed">台湾省</subdivision>
<subdivision type="cnxz" draft="contributed">チベット自治区</subdivision>
<subdivision type="jp12" draft="contributed">千葉県</subdivision>
<subdivision type="jp13" draft="contributed">東京都</subdivision>
<subdivision type="jp14" draft="contributed">神奈川県</subdivision>
<subdivision type="ua43" draft="contributed">クリミア自治共和国</subdivision>
という記述がある。日本の都道府県と同じ扱いでチベット自治区がでてくる。香港と台湾は、territory typeにもsubdivisionにも出てくる。結構考えさせられる。IT的には、一度振ったコードはデータとして残るから、新規にコードを振ることを禁止するルールは設定しても、基本的に既存のコードを削ることはできない。だから、HKもTWもコードとしては消えないだろう。ちなみに、クリミア自治共和国のコードはua43。UAはウクライナのterritory typeのコードである。クリミア共和国は登録されていない。
ITはコード化しないと存在を記述できない。逆に言えば、国際社会が認めるか否かに関わらず区別して扱う必要があればコードは振り出さないといけない。現在はCLDRは議長がIBMから出ていて、副議長がGoogleから出ている。考えようによってはCLDRの方が国連や各国政府より強いと言えないことはない。
米中間の対立も気になるが、それ以外でもIT基盤は様々な国際問題と関わっていることを改めて考えさせられた。
脱線となるが、記述を見ていると結構面白い。例えば、calendar type "japanese"には、
<era type="0">大化</era>
<era type="1">白雉</era>
<era type="2">白鳳</era>
と書かれている。enでは出てこない。