ここから本文です

CMS Watch : 「分類法」を考えたローカリゼーション /どのような場合に、ローカライズとカテゴライズが必要になるのか？

2006年4月 1日 掲載

クリスチャン・ドナー

インターナショナリゼーション（きわめて業界チックな略語を使うならば、「Internationalization」の最初と最後の文字「I」と「N」を取って、その間の文字数「18」を使い、「I18N」と表記する）を一般的に定義するならば、アプリケーションのコードやデータにアブストラクションの層を導入することによって、ソフトウェアをよりローカライズしやすいものにする様々な方策、と言えるだろう。これらの方策を用いることによって、後で特定ロケールの要件に合わせて言語や通貨、日付、数字のフォーマットを変更する作業が楽になる。

一方、ローカリゼーション（同じく「L10N」）とは、翻訳テキストを作成したり、そのほかロケールに特有のものを作ることによって、ユーザが理解できるフォーマットで情報を提示するための、補助的な方策のことを指している。

今やほとんどのプログラミング言語やアプリケーションフォーマットには、この両方を達成するための機能がたくさん盛り込まれている。これらの技術は、すでに何年にもわたって使われてきた。このため我々は、「ローカリゼーション」と言うと、国際的なソフトウェアプロジェクトを成功させるために経なければならない、単なる機械的なステップと考えがちだ。

しかし残念ながら、これは、ウェブ CMS の導入においては、まったく当てはまらない考え方であり、ベンダーやプラットフォームを問わずそれが言える。その理由は、ロケール情報が分離されずに、全体的なコンテンツのカテゴライズ、すなわち「分類法（タクソノミー）」の一部になっていることにある。必要なのは、ローカライズをする前に、分類法に含まれているすべてのコンポーネントの相関関係を理解し、それに応じて情報の構造を設計することだ。以下のセクションでは、これらの関係や依存関係の事例を見てみることにしよう。

今日のI18N

フレームワークやプラットフォーム、さらに突き詰めるならば、個別の CMS 製品に一般に導入されている機能としてのインターナショナリゼーションは、2つのレベルの自由しか提供してくれない。それは、言語と国だ。

例えば、Java プラットフォームでは、国のコードと言語のコードを合体したロケールIDというものが定義されている。アメリカであれば、このロケールIDは「us_EN」となる。「us」は、ISO の標準規格639が定義する国名コードで、「EN」は、ISO 3166に基づく言語コードだ。この二重性は、国によってはいくつかの言語が話されているため、一国でも複数のロケールが存在するという正しい観察に基づいている。例えば、一般に、カナダのためにローカライズされたアプリケーションは、通貨はカナダドルで表示するが、言語はフランス語と英語の両方をサポートしなければならない。このため、Java のロケールとしては、「ca_EN」と「ca_FR」が存在することになる。

それならば、コンテンツアセットにロケールコードをくっつけてしまい、単純にそれで終わりとしてしまえないものなのか？　実際、それは可能かもしれない。しかし、可能だとしたら、それは最もシンプルな状況においてだけだろう。これが可能かどうかは、ローカリゼーションの分類法によって異なってくる。

翻訳者やローカリゼーションの専門家は、どんなローカリゼーションプロジェクトにとっても、欠かすことができない存在だ。なぜなら彼らは、コンテンツ自体の翻訳やローカリゼーションに対する経験を持っていて、その複雑さはほとんどの場合、十分に理解されていないからだ。しかし、彼らにもできないことがある。それは、ローカライズされたコンテンツを正しい地域の正しいユーザにとってアクセシブルにする、情報アーキテクチャを実現することだ。ローカリゼーションと情報アーキテクチャが交わるこの交差点において、国際企業はしばしば、まったくの「空白」に直面している。

グローバルな CMS を導入したことがない企業の多くは、自らの市場や言語、ユーザがどのように関係しあっているかについて、あまり考えをめぐらせた経験がない。また、プロジェクトチームは、これらの関係性をやすやすと定義できる人材を、持ち合わせていないかもしれない。これらの点を分析し、ドキュメント化し、理解するには、それなりの努力が必要だ。そしてこの努力こそが、プロジェクトの手始めとならなければならない。それ以外のことはすべて、この記事の残りの部分も含めて、この努力にかかわってくるからだ。

分類法（タクソノミー）

分類法（タクソノミー）は、概念的な構造を示し、クリーンなナビゲーション設計を向上するものとなる。CMS の価値は、コンテンツ分類法を導入することによって、飛躍的に高まる。分類法は、コンテンツのメタデータのドメインを定義し、メタデータのすべての次元（「側面」と呼ばれることもある）の有効な組み合わせを定義する。例えば、「業種」というのは、分類法でよく使われる次元のひとつだ。SIC の標準コードを用いて業種コードを定義することによって、コンテンツアセットの業種IDがどのような値になり得るかという幅を定義する。

「地理」もまた、ほとんどの分類法に登場する次元だ。地理的次元は、例えば、国コードとして導入できる。でも、ちょっと待てよ。国コードだって？　と思う人もいるかもしれない。さっき話したロケールIDはどうなるんだ？　ロケールIDには、すでに国コードが含まれていたじゃないか？　情報が競合する可能性はないのか？

コンテンツローカリゼーションの分類法

もちろん、その疑問は正しい。ここに問題がある。そろそろ、これを読んでいるみなさんも、いかに複雑かが分かり始めてきたところだろう。1つのコンテンツアセットのメタデータに、2つの異なる国コードが含まれていても、有効である場合がある。2つの国コードが、別々のものを意味し得るからだ。国コードがいくつ必要かを理解するには、独自のローカリゼーション分類法を開発しなければならない。たいていの場合は、以下のレファレンス分類法の部分集合となるだろう。

このレファレンス分類法では、すべてのコンテンツが、3つの地理的次元から十分に説明できる。

• どの地域から来ているコンテンツか。
• どの地域についてのコンテンツか。
• どの地域のためのコンテンツか。

これに加えて、言語を定義する4つ目のローカリゼーション次元がある。ここで言う次元は、どれも「地域」を指していて「国」ではないことに注意してほしい。

ここから先は、金融関係のリサーチを提供し、世界中の主な市場すべてで事業展開している架空の会社を例に話を進めていこう。この会社は、国際的なウェブサイトを持っていて、ビジターは、リストから興味のある地域を選ぶようになっている。

ドイツ語で書かれた記事が、フランクフルトのオフィスから発信され、ドイツの金融市場にとって重要なトピックを取り上げていて、ドイツ語サイトのビジターに対して表示されている、というのは容易に理解できる。4つの次元はすべて、「Germany （ドイツ）」や「German （ドイツ語）」に設定されている。しかし、この例では、以下に示したように、この記事が実際には英語で表示されているとしよう。これを認めているのは、この会社の分類法だ。

Java ベースの CMS ツールに搭載された標準的なローカリゼーション機能を使っていれば、このようなことは不可能だっただろう（アプリケーションやプラットフォームが、「de_EN」というロケールのためのリソースを定義していないためだ）。

図1　国際的なコンテンツの一般的な分類法

同様に、東京オフィスから発信された記事が、ヨーロッパの金融市場について論じていて、世界中の読者に向けられているという可能性もある。

「地域」に含まれるのは何か

最後に言及した例は、特にたくさんの要素が盛り込まれていたが、ここまで読んでくださった方なら、これが何を暗示しているか、もうお分かりだろう。まず、この記事は、「ヨーロッパ」という地域についてのものであって、1つの国についてではない。これが具体的に何を意味するのか？　それは、この記事を書いた人が、入力時の画面でヨーロッパ大陸を構成している国をすべてクリックしなければならない、ということであってはいけない。ローカリゼーションの分類法を作成する際に、自社の市場を考えるべきであって、地理的な国境を考える必要はない、ということなのだ。自社のコンテンツやユーザに即して、意味のある地域を定義しなければならない。

次に、この記事は、「世界中の読者」に向けられていて、これもやはり1つの国ではない。個々の地域市場を単に合計しただけでは語れない、グローバルな金融市場というものが実際に存在することに気づくと、「グローバル」が独立した地域でなければならないことが明らかになってくる。地域は、他の地域に含まれる可能性があるが、必ずしも含まれなければならないということではない。分類法の他の部分は、階層構造となる可能性がある。もしかすると、国レベルの情報があって、国が地域にまとめられるという構造が必要なのかもしれない。

高度なローカリゼーション分類法

さらに、コンテンツによっては、すべての市場で利用されるべきではないという要件があったり、コンテンツを発信する地域が、利用できる市場の部分集合に対してのみコンテンツを提出できるべきであるという要件があったりすると、分類法の設計には、次なるレベルが必要になる。もしかすると、この分類法には「製品」という次元が存在するかもしれない。そしてこの会社は、「リスクソリューション」という製品をアジア市場では提供していないが、世界のその他の市場では提供しているかもしれない（図2参照）。そうであれば、この選択は、アジアサイトのビジターに表示されるコンテンツを提出しようとする記事執筆者のタグ付け画面には、表示されてはならない。つまり、この段階では、多数の地域別分類法が必要ということになる。これを作るのは大変な作業だが、ビジネス要件がこのような地域ごとの違いを要請するのであれば、ほとんど避けて通ることはできないだろう。

図2　ローカルな分類法

自分なりの分類法の定義

自分のウェブサイトに合わせた分類法を策定するには、ここまでに説明した一般的なアプローチから始めて、独自のニーズに合わせて絞り込んでいくのがいいだろう。コンテンツを発信した地域を知っておく必要はあるだろうか？　もしもなければ、発信地域の次元は省略できる。ウェブサイトで使われている「地域」という概念が、主に読者ターゲットを指定するためであって、コンテンツをどのようにローカライズするかにはあまり関係していない、ということはないだろうか？　別の言い方をすると、ウェブサイトのビジターが地域を選ぶと、それによってどのコンテンツが表示されるかが決まってくるのか（どのようにコンテンツが表示されるかではなく）？　もしそうならば、3つの次元のうち最後の2つは、1つに統合できるかもしれない。はたまた、ビジネスの形態に、その他の分類法の次元に影響する地域的な要因が含まれているだろうか？　地域別の製品分類法を作成する必要もあるかもしれない。

導入にあたっての注意点

複数の次元を備えた分類法は、複雑で視覚化するのが難しく、ましてや実際の導入となると、きわめて困難になることもある。図3は、3つの次元を持ったシンプルな分類法を示している。地理的条件、製品、言語だ。そして、それぞれの次元には、3つの異なる値が入る可能性がある。この例でハイライトされた立方体は、「Equity Research （株式調査）」について「English （英語）」で書かれた「Global （グローバル）」なコンテンツを示している。現実の状況では、分類法のすべての立方体が定義できないことも多いだろう。しかも、企業の分類法には、3つよりも多くの次元が含まれるかもしれない。

図3　複数の次元を持った分類法

このように、分類法の各次元の間に複雑な依存関係があり、それぞれの次元に当てはまる値も多数に上る可能性があることから、コンテンツを効果的に管理できるグローバルな CMS のユーザインタフェースを構築する作業は、非常に困難になる可能性がある。例えば、2つの地域に当てはまる記事が、そのうち1つの地域でのみ提供されている製品について言及していることがあるかもしれない。このような場合、この記事を提出するユーザに対して、無効な製品と地域の組み合わせでラベル付けすることを認めるべきかどうか？　また、多数ある値のなかから、複数の値をどのように選ばせるか？

こうしたケースでは、複数選択ができるドロップダウンリストは、おそらく理想的なソリューションではないだろう。にもかかわらず、ほとんどの CMS 製品は、そのまま使っているかぎり、せいぜいドロップダウンリストしか選択肢がないことも多い。有効なメタデータ値の組み合わせだけを提示して、本当の意味で複数対複数の関連付けを伴った分類法メタデータをリレーショナルデータベースや XML レポジトリに書き込んでくれる、インテリジェントなユーザインタフェースが必要なのであれば、メタデータメンテナンスのアプリケーションを構築して、それを CMS の管理インタフェースと統合する必要があるだろう。

まとめ

ローカリゼーション分類法を作成する作業は、CMS 導入プロジェクト全体において重大な部分を占める可能性がある。特に、各地のオフィスがローカルな分類法の管理権を握り、ローカルな顧客に最も適したやり方でコンテンツを提供したいと考える場合は、そうなるだろう。すでに紹介したように、アプリケーションの単純なローカリゼーションに適用される概念は、複雑な国際的コンテンツのローカリゼーションにとっては、十分ではない。正しく実践するには、相当な量の分析と、それに伴う値段を覚悟する必要がある。

クリスチャン・ドナーは、マサチューセッツ州ウォータータウンにある Molecular でシニア・テクニカル・アーキテクトとして働いている。担当業務は、コンテンツマネジメントおよびビジネスインテリジェンス分野のソリューションを、顧客と一緒に策定し、構築すること。Molecular は、1994年に設立された技術コンサルティング会社で、インターネットベースのソリューションの設計と構築を手がけている。

この記事の原文「When you need to localize and categorize」は、2006年3月13日、「cmswatch.com」に掲載された。

トラックバック

このページのトラックバックURL
http://www.designit.jp/mt/mt-tb.cgi/382