# 国際化入門

国際化
とは、世界中のユーザを対象としたコンピュータ・システムとアプリケーションを設計することです。ユーザはそれぞれ異なった言語を使用しており、自分が操作するシステムの機能やユーザ・インタフェースについて異なった要求をもっていることでしょう。その違いにもかかわらず、世界中のどこでもハードウェアを問わずに実行できるアプリケーションが実装されることが望まれています。 このような
アプリケーションは、国境を超えて相互運用することができ、多数のベンダから出荷されているさまざまなハードウェア構成の上で実行することができ、さらに、ローカルなユーザの必要を満たすようローカライズすることができなければなりません。このオープンな分散コンピューティング環境が、
共通でオープンなソフトウェア環境を推進する根拠となっています。この仕様の中で明確にしている国際化のための技術は、グローバルな市場に上記のような利便性をもたらすのです。

## 国際化の概要

さまざまな国の言語をサポートするために、ひとつの共通オープン・システム内に複数の環境が存在することがあります。このそれぞれの国の
環境は、ロケールとよばれ、言語、その文字とフォント、データの入力と書式に使用される慣習を考慮します。共通デスクトップ環境は完全に国際化に対応しているので、どのようなアプリケーションでもシステムにインストールされているロケールを使用して実行することができます。

ロケールは、ユーザの地理的地域の言語と文化的規約に従って、実行時のプログラムの動作を確定します。システム全体を通して、
ロケールは次の処理に影響を及ぼします。

- テキスト・データのエンコードと処理

- 言語の識別、および、リソース・ファイルとそのテキスト値のエンコード

- テキスト文字列の表示と配置

- クライアント間テキスト通信に使用されるテキストの相互変換

- 入力メソッド（生成されるコード・セット）の選択とテキスト・データの処理

- クライアント間テキスト通信のエンコードとデコード

- ビットマップ／アイコン・ファイル

- アクションとファイル・タイプ

- ユーザ・インタフェース定義（UID）ファイル

国際化対応アプリケーションは、ユーザのロケールや、そのロケールを表す必要のある文字や、ユーザが対話操作しようとする（日付や通貨のような）書式に依存するコードを一切含みません。デスクトップは、アプリケーションから言語や文化に依存する情報を切り離し、それをアプリケーションの外に保存することによってこれを達成しています。

図 1-1は、国際化を簡単にするためにアプリケーションの外におくべき種類の情報を示しています。

### アプリケーションの外におくべき情報

言語や文化に依存する情報をアプリケーションのソース・コードから切り離しておきます。そうすることによって、異なった国の市場に出すためにアプリケーションを書き直したり、再コンパイルしたりする必要がなくなり、外においた情報をローカルの言語や文化に適応するようローカライズするだけでよくなります。

国際化対応アプリケーションもまた、異なった母国語、ローカルな慣習、文字列のエンコードの要求に適合させることができます。操作を特定の母国語、ローカルな慣習、文字列のエンコードに適合させる処理は
ローカリゼーションと呼ばれます。

国際化の概要については、X/Open CAE Specification System Interface Definition, Issue 4, X/Open Company Ltd., 1992, ISBN: 1- 872630-46-4 を参照してください。

### 国際化の現状

独自の機能から、X/Openが発表する新しい標準機能セットまで、多くの種類の国際化が業界から提供されてきました。また、そのレベルも、単純なASCIIサポート、ラテン／ヨーロッパの言語のサポート、アジアの言語のマルチバイト・サポート、アラビア語／ヘブライ語の双方向サポートなどさまざまでした。

X/Openの仕様で定義されているインタフェース
では、次のような広範囲の言語と地域
をサポートすることができます。

`スクリプト` | 詳細
ラテン語 | アメリカ、東／西ヨーロッパ
ギリシャ語 | ギリシャ
トルコ語 | トルコ
東アジア | 日本語、韓国語、中国語
インド語派 | タイ語
双方向 | アラビア語とヘブライ語

さらに、
共通デスクトップ環境の目的は、これらの技術のローカリゼーション（メッセージやマニュアルの翻訳、その他ローカルな必要性への適応）が一貫性のある方法で行なわれ、その結果として、世界中のサポートされているユーザが、どこにいても、ベンダが異なっても、同じ共通のローカライズされた環境を得ることができるようにすることです。
エンド・ユーザと管理者には、一貫性のあるローカリゼーション機能によって、グローバルなソフトウェアをサポートする完成したアプリケーション環境が提供されます。

### 国際化規格

多くの企業によって、追加要求や言語、特に東アジアのものが盛り込まれ、国際化対応アプリケーション・プログラム・インタフェースの機能が規格化されてきました。この作業は主として、Portable Operating System Interface for Computer Environments(POSIX)と
X/Open仕様に集約されてきました。最初のX/Open仕様はX/Open Portability Guide（XPG2）の第２版で発表され、Hewlett-PackardがリリースしたNative Language Support製品に基づいていました。最近発表されたX/Open国際化規格は、XPG4として参照されます。

デスクトップ内の各レイヤが、国際化に対応するために定義された適切な
標準インタフェースのセットを使用して、一貫性のあるローカライズされたインタフェースを確実にエンド・ユーザに提供することは重要なことです。ロケール、および、共通でオープンなロケール依存の機能セットの定義は、次の
仕様に基づいています。

- X Window System, The Complete Reference to Xlib, Xprotocol, ICCCM, XLFD - X Version, Release 5, Digital Press, 1992, ISBN 1-55558-088-2.

- ANSI/IEEE Standard Portable Operating System Interface for Computer Environments, IEEE.

- OSF™ Motif 1.2 Programmer' Reference, Revision 1.2, Open Software Foundation, Prentice Hall, 1992, ISBN 0-13-643115-1.

- X/Open CAE Specification Commands and Utilities, Issue 4, X/Open Company Ltd., 1992, ISBN 1-872630-48-0.

この環境において、ソフトウェア開発者は、可搬的で、（ベンダが異なっていても）分散システム間で相互運用でき、デスクトップの標準ロケールがサポートしている国籍の異なるユーザのさまざまな言語や文化的要求に応えることができる世界共通のアプリケーションを開発することができます。

### 共通国際化システム

>IPG.intro.mkr.5は、
国際化が、特定の単一ホスト・システム内で広がる様子を示しています。この目的は、アプリケーション（クライアント）が、下層のシステムがサポートしているロケールのセットに対応するよう構築されて、世界中に出荷されることです。標準インタフェースを使用することで、グローバルな市場に出しやすくなり、アプリケーション開発者が行なう必要があるローカリゼーション作業の量を最小限にすることができます。

#### 共通国際化システム

## ロケール

大部分の単一ディスプレイ・クライアントは、環境変数、通常は`$LANG`、または、`xnlLanguage`リソースの設定によって実行時に決定される単一のロケールで動作します。`LC_ALL`、`LC_CTYPE`、`LANG`などのロケール環境変数を使用して環境を制御することができます。

ロケールの`LC_CTYPE`カテゴリは、環境によって使用され、実行時に使用されるロケール固有の機能を識別します。ツールキットが読み込むフォントと入力メソッドは、`LC_CTYPE`カテゴリによって決定されます。

国際化対応のプログラムは`XtSetLanguageProc()`関数（デフォルトで`setlocale()`を呼び出す）を呼び出してユーザが希望するロケールを設定するものとされています。ロケールを設定するために`setlocale()`関数を呼び出すライブラリがないので、アプリケーションは、特定ロケールまたは実行時に読み込まれる値で`XtSetLanguageProc()`を呼び出す必要があります。アプリケーションが国際化対応であるのに`XtSetLanguageProc()`を使用しない場合は、次の優先順位をつけたソースのうちのひとつからロケール名を取得し、それを`setlocale()`関数に渡してください。

- コマンド行オプション

- リソース

- 空の文字列(“ ”)

空の文字列の場合は、`setlocale()`関数は、環境変数`$LC_*`と`$LANG`を使用してロケール設定を決定します。特に、setlocale(`LC_ALL`, “ ”)では、表1-1に示すロケール・カテゴリの順に、ロケールが確認され環境変数から取得されます。

## ロケール・カテゴリ

`カテゴリ` | `第１環境変数` | `第２環境変数` | `第３環境変数`
LC_CTYPE: | LC_ALL | LC_TYPE | LANG
LC_COLLATE: | LC_ALL | LC_COLLATE | LANG
LC_TIME: | LC_ALL | LC_TIME | LANG
LC_NUMERIC: | LC_ALL | LC_NUMERIC | LANG
LC_MONETARY: | LC_ALL | LC_MONETARY | LANG
LC_MESSAGES: | LC_ALL | LC_MESSAGES | LANG

ツールキットはすでに標準のコマンド行オプション（`-lang`）とリソース（`xnlLanguage`）を定義しています。また、リソースの値はサーバ`RESOURCE_MANAGER`で設定することもできますが、その場合はサーバに接続しているすべてのクライアントに影響する可能性があります。

## フォント、フォントセット、レンダー・テーブル

Xクライアントはすべて、フォントを使用してテキストを描画します。テキスト描画に使用される基本的なオブジェクトは`XFontStruct`で、これは描画するイメージを含むフォントを識別します。

デスクトップはXlibによって定義される`XFontStruct`データ構造体によってすでにフォントをサポートしていますが、フォント内の文字のエンコードは国際化対応アプリケーションに認識される必要があります。この情報を伝達するため、プログラムは、サーバのすべてのフォントはX Logical Font Description（XLFD）名によって識別されるものとみなします。XLFD名によって、ユーザは基本属性とcharset（フォント・グリフのエンコード）の両方を記述することができます。charsetという用語がフォント内のグリフのエンコードを示すのに使用されるのに対し、コード・セットという用語は、ロケール内の文字のエンコードを意味します。指定されたフォントのcharsetは、XLFD名のCharSetRegistryフィールドとCharSetEncodingフィールドで決定されます。テキストと記号はフォント内のコードによって定義された通りに描画されます。

フォント・セット（たとえば、Xlibによって定義されるデータ構造体`XFontSet`）は、ひとつ以上のフォントの集合で、指定されたロケール用に定義されたすべての文字の描画を可能にします。ロケールによってはコード・セットでエンコードされた文字の値がグリフ・インデックスと一致しないものもありますが、国際化対応アプリケーションは、このような場合もエンコードされたテキストを描画できなければなりません。さらに、ロケールのコード・セットとは異なるエンコードをもつフォントをひとつ以上使用しているロケールでのすべての文字を描画するために、複数のフォントが必要となる場合もあります。コード・セットもcharsetもロケールごとに異なるので、フォント・セットという概念を`XFontSet`として取り入れています。

フォントがXLFD名によって識別されるのに対し、フォント・セットはXLFD名のリストによって識別されます。リストはひとつ以上のXLFD名から構成されますが、基本属性だけが意味をもちます。必要なフォントのエンコードはロケールから決定されます。XLFDベース名リストで指定されるcharsetは無視されるので、ユーザが考慮する必要があるのはポイント・サイズ、スタイル、ウェイトなどの基本属性の指定のみです。フォント・セットはロケール依存で、ロケールのコード・セットでエンコードされているテキストを描画するのに使用されます。国際化対応アプリケーションはテキスト・データを描画するのにフォント構造体ではなくフォント・セットを使用すべきです。

レンダー・テーブルは、テキストがどのように描画されるかを指定するレンディションの集合です。レンダー・テーブルについては、この節でまとめています。

### Font Specification

フォント指定は、X Logical Font Description (XLFD)名、もしくは、XLFD名の別名のいずれかです。たとえば、14ポイント・フォントの有効なフォント指定は次のようなものです。

    -dt-application-medium-r-normal-serif-*-*-*-*-p-*-iso8859-1

OR

    -*-r-*-14-*iso8859-1

### フォント・セット指定

フォント・セット指定は、名前（XLFD名またはその別名）のリストで、ベース名リストと呼ばれることもあります。名前はすべてコンマで区切られ、コンマの前後の空白部分は無視されます。パターン・マッチング（ワイルドカード）文字を使って、XLFD名を短縮して指定することができます。

フォント・セット指定は、実行中のロケールによって決定されます。たとえば、ja_JP日本語ロケールは、日本語の文字すべてを表示するのに必要な３つのフォント（キャラクタ・セット）を定義します。次の例では、必要なゴシック・フォントのセットが識別されます。

- 完全なXFLD名リストの例:

      -dt-mincho-medium-r-normal--14-*-*-m-*-jisx0201.1976-0,-dt-mincho-medium-r-normal--28-*-*-*-m-*-jisx0208.1983-0:

- 単一XLFDパターン名の例:

      -dt-*-medium-*-24-*-m-*:

上記の２つの例は、ベース名リストに一致するフォントが存在する限り、日本語ロケールで使用することができます。

### ベース・フォント名リストの指定

ベース・フォント名リストは、ロケールが定義するフォント・セットに関連するベース・フォント名のリストです。ベース・フォント名は、それぞれコンマで区切られてリストを構成しており、可搬的なキャラクタ・セットからの文字と仮定されます。そうでない場合は、結果は不確定となります。区切りコンマのすぐ前後の空白部分は無視されます。

XLFDフォント名を使用することによって、国際的アプリケーションは、単一のロケールに依存しないベース・フォント名からさまざまなロケールに必要なフォントを取得することができます。単一のベース・フォント名は、該当するロケールが必要とするさまざまなcharsetでメンバがエンコードされたフォントのファミリを指定します。

XLFDベース・フォント名は、ロケールに必要なフォントのcharsetを明示的に指定することができます。このため、ユーザはロケールに必要なcharsetで使用するフォントを厳密に指定することができ、フォントの選択を完全に制御することができます。

ベース・フォント名がXLFD名でない場合は、フォントのフォント属性からXLFD名を取得しようと試みられます。

次のアルゴリズムは、フォント・セットでテキストを表示すのに用いるフォントを選択するために使用されます。

ロケールで必要な各charsetごとに、サーバに存在するフォントのセットを指定する次の場合のうちの最初にあてはまるものを求めて、ベース・フォント名リストが検索されます。

- 必要なcharset、または、必要なcharsetのスーパーセットをCharSetRegistryフィールドとCharSetEncodingに指定する最初のXLFD準拠ベース・フォント名。

- 必要なcharsetをサポートするよう再マップすることができるひとつ以上のcharsetを指定する、ひとつ以上のXLFD準拠ベース・フォント名から成る最初のセット。Xlibを実装していると、必要なcharsetからひとつ以上のその他のcharsetへのさまざまなマッピングを認識して、これらのcharsetのフォントを使用することができます。たとえば、ASCIIのチルドとバックスラッシュは、JIS Romanではオーバーバーと円記号に置換えられます。XlibはJIS Romanフォントが取得できない場合、ISO8859-1フォントを読み込んでこのキャラクタ・セットをサポートすることができます。

- 必要なcharset（XLFDフォント名のCharSetRegistryフィールドとCharSetEncodingフィールドに置き換わる）と結合された最初のXLFD準拠フォント名、または、XLFDフォント名を取得できる最初のXLFDでないフォント名。最初の手続きで、インプリメンテーションは、必要なcharsetのスーパーセットであるcharsetを使用することができます。

- ロケールに依存した方法で、charsetを連想させるテキストをサポートするひとつ以上のフォントにマップすることができる最初のフォント名。

たとえば、ロケールには次のcharsetが必要であると仮定します。

- ISO8859-1

- JISX0208.1983

- JISX0201.1976

- GB2312-1980.0

次の例のように、charsetを明示的に指定するベース・フォント名リストを提供し、特定のフォントが存在している場合は確実にそれを使用するようにすることができます。

    “-dt-mincho-Medium-R-Normal-*-*-*-*-*-M-*-JISX0208.1983-0,\
    -dt-mincho-Medium-R-Normal-*-*-*-*-*-M- \
    *-JISX0201.jisx0201\.1976-1,\
    -dt-song-Medium-R-Normal-*-*-*-*-*-M-*-GB2312-1980.0,\
    -*-default-Bold-R-Normal-*-*-*-*-M-*-ISO8859-1“

次の例のようにcharsetを省略したベース・フォント名リストを提供すると、必要な各コード・セット用のフォントを選択できます。

    “-dt-Fixed-Medium-R-Normal-*-*-*-*-*-M-*,\
    -dt-Fixed-Medium-R-Normal-*-*-*-*-*-M-*,\
    -dt-Fixed-Medium-R-Normal-*-*-*-*-*-M-*,\
    -*-Courier-Bold-R-Normal-*-*-*-*-M-*”

代わりの方法として、次の例のように、単一ベース・フォント名を提供すると、ある最小限のXLFD属性要求を満たす使用可能なすべてのフォントから選択することができます。

    “-*-*-*-R-Normal--*-*-*-*-*-M-*”

### レンダー・テーブル

レンダー・テーブルはレンディション
と呼ばれるひとつ以上のエントリから構成されています。各レンディションは、コンパウンド・ストリングを描画する際に使用される名前でタグを付けられています。国際化対応アプリケーションでは、レンディションとレンダー・テーブルはリソース・ファイルで指定し、さまざまなロケールの異なった必要性からアプリケーション・バイナリを独立させておくべきです。レンディションとレンダー・テーブルについて詳しくは、Motfプログラマーズ・ガイドを参照してください。

## テキスト描画

デスクトップは、シンプル・テキスト、コンパウンド・ストリング、いくつかのウィジェットなど、ローカライズされたテキストを描画するためのさまざまな関数を提供します。これらの中には、XlibやMotifライブラリの関数も含まれています。

## 入力メソッド

共通デスクトップ環境は、Motif Toolkitを使用している国際化対応アプリケーションに対してローカライズされた入力を実行する機能を提供します。特に、`XmText[Field]`ウィジェットは、各ロケールが提供する入力メソッドとインタフェースをとることができるようになります。さらに、`dtterm`クライアントが、入力メソッドを使用することが可能になります。入力メソッドについて詳しくはMotifプログラマーズ・ガイドを参照してください。

デフォルトでは、Motif ツールキットを使用するそれぞれの国際化対応クライアントは、ユーザが指定するロケールに関連付けられた入力メソッドを使用します。`XmNinputMethod`リソースをロケール・モディファイアの入力メソッド部として提供し、ユーザが代替の入力メソッドを指定できるようにします。

入力メソッドのユーザ・インタフェースは、いくつかの要素から構成されています。これらの領域の必要性は使用されている入力メソッドに依存しており、通常は、複雑な入力処理とダイアログを要求する入力メソッドによって必要とされます。これらの領域については、図 1-3を参照してください。

### VendorShellウィジェットと補助の例（日本語）

`VendorShell`は、`XmNinputPolicy`リソース
を含んでいます。これは、その子ウィジェットが入力コンテキストを共用するか否かを指定します。たとえば、ルート・ウィンドウ入力メソッド・スタイルを使用している場合、入力コンテキストはいくつかのウィジェットで共用され、off-the-spot入力メソッド・スタイルである間は、入力コンテキストはひとつ以上のウィジェットの間で共用されるはずです。しかし、over-the-spot入力メソッド・スタイルでは、入力コンテキストはほば確実に単一のウィジェットに属します。`XmNinputPolicy`がとりうる値は、 各ウィジェットに新しい入力コンテキストを提供する`XmPER_WIDGET`と、共通のシェルの子ウィジェットに単一の入力コンテキストを共用させる`XmPER_SHELL`です。

### 前編集領域

前編集領域は、前編集中の文字列を表示するのに使用されます。入力メソッドは前編集モードとして、OffTheSpot、OnTheSpot（デフォルト）、OverTheSpot、Root、Noneをサポートしています。

確定済みの文字列を再変換することはできません。文字列は前編集領域からユーザが文字を入力している位置に移動します。

#### OffTheSpot

入力メソッドを使用してOffTheSpotモードで前編集する場合は、前編集の位置は通常、IPG.intro.mkr.13に示されるように、アプリケーション・ウィンドウ内、ステータス領域の右側にあります。日本語入力メソッドを例として示します。

##### VendorShellウィジェットでのOffTheSpot前編集の例（日本語）

入力メソッドを使用して前編集している場合、前編集中の文字列は使用している入力メソッドに依存する形式で強調表示されます。

OffTheSpotモードを使用するためには、`VendorShell`ウィジェットの`XmNpreeditType`リソースを、`XtSetValues()`関数、もしくは、リソース・ファイルのいずれかで設定してください。`XmNpreeditType`リソースは、`TopLevelShell`、`ApplicationShell`、または、`DialogShell`ウィジェットのリソースとして設定することもできます。この３つのウィジェットはすべて、`VendorShell`ウィジェット・クラスのサブクラスです。

#### OverTheSpot

OverTheSpotモードでは、前編集領域の位置はユーザが文字を入力しようとしている位置（たとえば、現在フォーカスがある`Text`ウィジェットの挿入カーソルの位置）に設定されます。前編集領域の文字はカーソルのある位置にオーバーレイ・ウィンドウとして表示され、使用している入力メソッドに依存した形式で強調表示されます。

OverTheSpotモードでは、ひとつの前編集領域が複数行から構成されることがあります。前編集領域は常にメイン・ウィンドウ領域内にあり、どの方向にもはみだすことはできません。

前編集中の文字列は`Text`ウィジェットのテキストの一部分であるかのように表示されますが、前編集が終了するまではクライアントに渡されて下層の編集画面に表示されることはありません。IPG.intro.mkr.14の図を参照してください。

OverTheSpotモードを明示的に使用するためには、 `VendorShell`の`XmNpreeditType`リソースを`XtSetValues()`関数、もしくは、リソースファイルのいずれかで設定してください。`XmNpreeditType` リソースは、`TopLevelShell`、 `ApplicationShell`、または、 `DialogShell`ウィジェットのリソースとして設定することができます。この３つのウィジェットは `VendorShell`ウィジェット・クラスのサブクラスです。

##### VendorShellウィジェットでのOverTheSpot前編集の例（日本語）

#### OnTheSpot（デフォルト）

OnTheSpotモードでは、前編集文字列はテキスト・ウィジェット・ウィンドウに表示されます。前編集文字列はテキスト・ウィジェット値の一部分とみなされ、その完全性はテキスト・ウィジェットのVerifyコールバック（Verifyコールバックは`verifyPreedit`リソースによって制御され、デフォルトは`False`です。）によって保証されます。テキスト・ウィジェットのVerifyコールバックが前編集バッファから何も受け入れない時、前編集文字列は確定されます。（前編集文字列を確定させるユーザ・アクションについては、Motifプログラマーズ・ガイドを参照してください。）

入力メソッドを使用して前編集を行っている場合、前編集中の文字列は使用中の入力メソッドに依存する方法で強調表示されます。

OnTheSpotモードを使用するためには、 `VendorShell`ウィジェットの`XmNpreeditType`リソースを、`XtSetValues()`関数、もしくは、リソース・ファイルで設定してください。`XmNpreeditType`リソースを `TopLevelShell`、 `ApplicationShell`、または、 `DialogShell`ウィジェットのリソースとして設定することもできます。この３つのウィジェットはすべて`VendorShell`ウィジェット・クラスのサブクラスです。

#### Root

Rootモードでは、前編集領域とステータス領域はクライアントのウィンドウとは別になっています。Rootモードの動作はOffTheSpotと類似しています。IPG.intro.mkr.15の図を参照してください。

##### VendorShellウィジェットでのRoot前編集の例（日本語）

### ステータス領域

ステータス領域は、ユーザに入力メソッドの入力状態やキーボードの状態を知らせます。OverTheSpotスタイルおよびOffTheSpotスタイルでは、ステータス領域はVendorShellウィンドウの左下端に位置しています。

- Rootスタイルでは、ステータス領域はクライアント・ウィンドウの外に位置しています。

- 前編集スタイルがOffTheSpotモードの場合は、前編集領域はステータス領域の右側に表示されます。

`VendorShell`ウィジェットはジオメトリ管理を提供しており、ステータス領域をVendorShellウィンドウの下隅に再配置することができます。

### 補助領域

補助領域はユーザが前編集を行う場合に役立ちます。補助領域は特定の入力メソッドに依存して作成されます。IPG.intro.mkr.11の日本語入力メソッドは次の型の補助領域を作成します。

- 全候補

- JISコード

- 変換方法の切り替え

  - 先読み連文節

  - 一括連文節

  - 単文節

  - 複合語

### フォーカス領域

フォーカス領域は、現在フォーカスがある`VendorShell`ウィジェット・サブツリーの下にある子孫ウィジェットのいずれかひとつです。既存のウィジェットを使用しているならば、Motifアプリケーション・プログラマはフォーカス領域を気にする必要はありません。重要なのは、一度にひとつのウィジェットだけしか入力メソッドを処理することができないということです。入力メソッドの処理は、現在フォーカスがあるウィンドウ（ウィジェット）に移動します。

### Layout Direction

配置方向は、ウィジェットの子、ウィジェット・コンポーネント、テキスト（`VendorShell`リソース、`XmNlayoutDirection`によって制御される）などのビジュアル要素を表示するために使用する方向を示します。一般的にこの方向は、人々が特定の言語を読み書きする時に使用する方向と一致します。英語、フランス語、ドイツ語、スウェーデン語などの言語は左から右に読み書きされます。したがって、ユーザがこれらの言語で作業し、コンピュータのキーボードから文字を入力する場合、入力文字は先に入力した文字の右側に表示されます。このユーザは、別のビジュアル要素も左から右へ配置されることを期待するでしょう。たとえば、メニュー・バーにおいて、プルダウン・メニュー・ボタンは左から右へ配置されるので、シンプルなメニュー・バーは、「ファイル」プルダウン・メニュー・ボタンをメニュー・バーの左上端に配置し、「ヘルプ」プルダウン・メニュー・ボタンを右上端に配置します。

アラビア語やヘブライ語などの言語は、右から左へ読み書きされます。これらの言語のテキストを画面上に正確に表示するためには、ユーザが入力する連続する各々の文字は先に入力した文字の左に表示されなければなりません。ビジュアル要素の配置に関して上記の例を用いると、ユーザはメニュー・バーがメニュー・プルダウン・ボタンを右から左へ配置することを期待します。その結果は通常、「ファイル」メニュー・プルダウン・ボタンを右上端に、「ヘルプ」メニュー・プルダウン・ボタンを左上端に配置することになります。配置方向について詳しくは、Motifプログラマーズ・ガイドを参照してください。

### 縦書き

いくつかのアジアの言語では、テキストは縦方向に描画されます。`VendorShell`リソース`XmNlayoutDirection`が `XmTOP_TO_BOTTOM`に設定されている場合に、縦書き機能が可能となります。この機能は、テキストを縦方向に描画することにくわえて、テキスト・ウィジェットをユーザに合った方法に適合させます。たとえば、ワード・ラップが「する」になっている場合、テキストはあるカラムの下から次のカラムの上へ折返します。縦書きについて詳しくは、Motifプログラマーズ・ガイドを参照してください。

## クライアント間通信規約（ICCC）

クライアント間通信規約（ICCC）は、クライアント間でテキストを渡すのに使用される仕組みを定義しています。システムは複数のコード・セットをサポートできるため、異なったコード・セットを使用している２つのアプリケーションが互いに通信を行うことが可能です。ICCCは２つのクライアント間でデータを渡す方法について、これらのクライアントがどのように同意するかを定義しています。２つのクライアントがもつキャラクタ・セットに互換性がない場合（たとえば、ラテン１と日本語（JIS）のように）、文字が転送される時にデータの一部が失われる可能性があります。
`
`

しかし、２つのクライアントが、異なったコード・セットをもっていても、それが互換性のあるキャラクタ・セットである場合は、ICCCはこの２つのクライアント間でデータを失うことなく情報を渡すことを可能とします。２つのクライアントのコード・セットが一致しない場合は、`COMPOUND_TEXT`アトムを使用して、コンパウンド・テキストのエンコードが使用されます。通信中のデータが可搬的な文字（7ビット、ASCIIなど）やISO8859-1コード・セットしか含んでいない場合は、そのデータは`XA_STRING`アトムによって、変換されずにそのまま通信されます。

タイトル名とアイコン名は、可搬的でない文字が使用されている場合は、`COMPOUND_TEXT`アトムを使用してウィンドウ・マネージャに通信される必要があります。そうでない場合は、`XA_STRING`アトムを使用することができます。

たとえばMotifは、テキストのデータを転送するのに、次のMotifのアトムを使用します。

- `_MOTIF_COMPOUND_STRING`は、データを XmString形式で転送します。

- `_MOTIF_RENDER_TABLE`レンダー・テーブルの値をSTRING型として転送します。

詳しくは、Motifウィジェット・ライターズ・ガイドを参照してください。

その他のエンコードは、ウィンドウ・マネージャのロケールに変換する程度に制限されています。ウィンドウ・マネージャは単一ロケールで実行され、実行中のロケールのコード・セットに変換できるタイトル名とアイコン名しかサポートしません。

Motifライブラリとすべてのデスクトップ・クライアントはこの規約に従わなければなりません。