GNOME アプリケーションの国際化

様々な i18n マクロを含むことになる新しいヘッダーファイルを作成します。 次のリストは追っていくのに適切な例です。

#ifndef __SLICE_INTL_H__
#define __SLICE_INTL_H__

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif /* HAVE_CONFIG_H */

#ifdef ENABLE_NLS
#include <libintl.h>
#define _(String) gettext(String)
#ifdef gettext_noop
#define N_(String) gettext_noop(String)
#else
#define N_(String) (String)
#endif
#else /* NLS is disabled */
#define _(String) (String)
#define N_(String) (String)
#define textdomain(String) (String)
#define gettext(String) (String)
#define dgettext(Domain,String) (String)
#define dcgettext(Domain,String,Type) (String)
#define bindtextdomain(Domain,Directory) (Domain) 
#define bind_textdomain_codeset(Domain,Codeset) (Codeset) 
#endif /* ENABLE_NLS */

#endif /* __SLICE_INTL_H__ */

当然 slice-i18n.h ではない何か別のファイル名にもできます。 しかし、ENABLE_NLS 変数名については後で 項3. 「パッケージのビルドインフラに i18n [の仕組み]を取り込み 」 で見るように特別な意味を持っているので変えるべきではありません。

もしアプリケーションが libgnome に依存しているなら、 slice-i18n.h (または他の名前のファイル)の代わりに <libgnome/gnome-i18n.h> を単純に include することで、独自の i18n サポートファイルを作成する必要はなくなります。 ここでは、メタファ的な"食物連鎖”のより低次のところで作業している開発者が便利なように、 上のファイルを読み込むこととします。

ライブラリ開発者は上記ファイルにいくつか変更を加える必要があるでしょう。 以下のセクションはなおも適用可能ですが、 項2.2.1.1. 「ライブラリについて特別に必要なこと」 まで飛ばすと必要な変更数行をみつけることができます。

これらの関数各々の目的についてはすぐに説明するつもりですが、 開発者から見て重要なのはまさに文字列を _() と N_() 呼出しでラップしようとしているということです。 これらの関数をソースコード内で用いるのなら、前述のヘッダーファイルがきちんと include されていることを確認する必要があります。 もちろん include しない場合の失敗は全く明らかなもので、 いくつかの関数が宣言されていないので単純にアプリケーションはビルドできなくなります。

実際に必要なコード変更を施す前に、 GNU gettext アプリケーションについてあまり詳しくない方のために、 大まかな状況について簡単に説明します。 ここでは、いくつかの詳細については省略して、主に GNOME に関連する部分について集中します。 もしすべての詳細について知りたいのなら gettext マニュアル ([gettext] を参照) が非常に参考になるでしょう。

インストールされている翻訳文字列のコレクションは、 別々の メッセージドメインに分けられています。 各々別々のアプリケーションまたはライブラリは、ほとんど常に異なるドメインを持ち、 ドメイン名は通常パッケージにまとめた後に決定されます。 与えられたドメインの文字列はインストール時に効率的なバイナリ形式 (各々のロカールについて一つのファイル) にコンパイルされ、 パッケージと一緒にインストールされます。 当然のことながら、プログラムがこれらファイルを必要なときにどこにあるか見付け出せるように指示する必要があります。

一つのアプリケーションがいつも一つのドメインだけからメッセージを取得しているわけではありません。 アプリケーション自身のメッセージはそれ自身のドメインからのものですが、 アプリケーションはまた、翻訳文字列を返す、または表示するライブラリ関数も呼出していて、 それら[メッセージ]はそのライブラリ固有のドメインからのものです。 そういうわけで[国際化の]仕組みは、(必ず一つだけ存在する) 現在アクティブなドメインを切り替えるために、C ライブラリ内に存在しています。

重要な最後の点は、翻訳された文字列は、 順々に回していくときに、 何らかの方法でエンコードされていなければならないということです。 中国語またはロシア語で使っているなら、英語圏のロカールで一般的な ASCII または ISO8859-1 エンコーディングは適切なものではありません。 デフォルトでは、gettext は与えられたロカール設定について最も自然なエンコーディングを知っていて、 適切なエンコーディングで文字列を返すでしょう。 しかし GNOME 全体ではすべての文字列は UTF-8 でエンコードされているので、 結局地域エンコーディングから UTF-8 に再度エンコードし直さなければなりません。 幸運なことに、C ライブラリにこのことを伝えることができて、 C ライブラリはロカール固有のエンコーディングに悩まされることはなく、 各々そして毎回の文字列の検索における多少の時間を節約することができます。

最後の三つの段落は次の三行のコードが何をするか非常に詳細に説明しているだけです。 これらのコードを、 可能な限り早くユーザーに可視な文字列の処理の準備をするために、 アプリケーションの main() 関数のすぐ最初に置きます。 もしクライアントアプリケーションが使うライブラリを書きたいのなら、 最初の二行をライブラリの初期化関数に入れておく必要があります。

bindtextdomain (GETTEXT_PACKAGE, SLICELOCALEDIR);
bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8");
textdomain (GETTEXT_PACKAGE);

ここで何が起きてるか説明すべきですね。 GETTEXT_PACKAGE 変数はビルドプロセスの間に (通常は configure.in または configure.ac) で定義され、このアプリケーションのメッセージドメイン名となります。 従ってこの値はプログラム名に設定できます。 SLICELOCALEDIR 変数 (この名前は普通はアプリケーション名に基づいていますが、 完全に任意であなたの判断にまかされています) はビルド時に定義され、 メッセージカタログを保持するディレクトリ階層のルートとなります。 [つまり]コンパイルされたメッセージカタログは SLICELOCALEDIR/locale/LC_MESSAGES/GETTEXT_PACKAGE.moとしてインストールされることになります。

それから上述のコードの断片はアプリケーションに次のように指示します。

この最後の項目はライブラリでは用をなさない (クライアントアプリケーションがほとんど常にアクティブドメインを制御します) ので、そうする必要はありません。 代りに、ライブラリは、その固有の文字列を取得する前にメッセージドメインを設定し、 その後で元に戻す必要があります (詳細についてはこの後で)。

ついでに、 最後のセクションでふれたような i18n ヘッダーファイルを使っているのなら、 i18n サポートを利用可能にするかどうかに関らず、 上述のコード断片はコンパイルされるということにふれておくべきでしょう。 前のセクションのヘッダーファイルのメリットがこれです。 一度設定したらあたかも残りのコードも i18n サポートが常に利用可能であるかのように処理できて、 もしサポートが存在していなくても単に空の操作としてビルドされます。

C または C++ ソースコードからそれらしいすべての文字列を探し出す最初の試みとして、 ソースコードディレクトリでコマンド xgettext -a -o my-strings --omit-header *.c *.h を実行します。

これによって、 ディレクトリのすべての .c そして .h ファイルを走査して、すべての文字列をファイル my-strings に出力します。 このファイルは翻訳時に翻訳者が作業するものにとてもよく似ていますが、 当面注目すべきは各々の行のフォーマットです。次のようになっているはずです。

#: slice-n-dice.c:36
msgid "Sharpening the knives and preparing for action."
msgstr ""

これはこの文字列がファイル slice-n-dice.c の行番号 36 にあることを示しています。 よって、もしこの文字列を翻訳するべきと判断したのなら、 このファイルを開いてその文字列を _( と ) で囲みます。つまり、例えばコード

popup_display ("Sharpening the knives and preparing for action.");

を次のように変更します。

popup_display (_("Sharpening the knives and preparing for action."));

マークアップの方法には一つだけ問題があります。 _() は関数呼出しなので、すべての状況で使えるわけではありません。 例えば、文字列をいくつか含む static 配列を初期化しているなら、 その初期化時に関数を呼出すことはできません。 次のようなコードについて考えてみます。

ShapeData shapes[] = {"circle", "square", "triangle", NULL};

このような場合文字列をマークアップするのには N_() を使うべきです。 このマクロは、結局のところ何かするわけでもありませんが、 gettext ツールは翻訳可能な文字列を探すのにコードを走査してこの種のマークアップをみつけたことを伝え、 これらの文字列を抽出します。上の例は次のようになります。

ShapeData shapes[] = {N_("circle"), N_("square"), N_("triangle"), NULL};

一度 N_() で文字列をマークアップしたら、 コード内でこれらの文字列が使われている箇所をすべて探し出し、 文字列を出現させるコードを _() で囲む必要があります。 これは _() がメッセージを検索し、翻訳する関数だからです。 上の例について続けると、 (i18n マークアップの後で) 次のようなコードを書けばいいでしょう。

for (i = 0; shapes[i] != NULL; ++i)
    show_shape_name (_(shapes[i]));

shapes[] からの文字列の取得は _() の呼出しを通して行なわれ、そうして show_shape_name() 関数は元の文字列ではなく、 翻訳された文字列を使っていることに注意して下さい。 static 文字列が実際に使われている場所を見落すことは珍しくないので、 (文字列を N_() で適切にマークアップしていても) コードマークアップのこの部分を正しく行うには、 おそらく少し用心しなければならないでしょう。

一度、先につくった my-strings ファイル内のすべての文字列についてくまなく調べてみて翻訳するべきかどうか決定したら、 そのファイルは削除できます。 このファイルは単に手順を先に進めるだめだけのものでした。 この段階で(いつものように)、 まだ i18n 部分が機能していなくても (ENABLE_NLS が未定義なので、すべての特別なマークアップは何もないのと同じになります) コードはなおも通常どおりビルド、動作できるはずです。 後で問題が起きるのを避けるためにビルド可能かどうかはテストしておくべきです。

#define _(String) gettext(String)

#define _(String) dgettext(GETTEXT_PACKAGE, String)

#define L_(x) gnome_app_helper_gettext (x)

const gchar *
gnome_app_helper_gettext (const gchar *str)
{
        char *s;

        s = gettext (str);
        if ( s == str )
                s = dgettext (GETTEXT_PACKAGE, str);

        return s;
}

desktop ファイルは GNOME ではパネルメニュー内のどのメニューの下にアプリケーションを表示するか決定するために使われています。 また desktop ファイルには、 どのようにしてアプリケーションを起動するか、どのアイコンを表示するかという情報と一緒に、 パネル上のアプリケーションのツールチップとして表示する説明文を含んでいます。

国際化の観点から .desktop のパーツで興味を引くところは Name と Comment フィールドです。 GNOME 2 ではこれら二つのフィールドだけが使われ、これらは desktop ファイル仕様の中で、 翻訳可能なものとして定義されています。

これらフィールドを翻訳可能なものとしてマークするには、 desktop ファイル slice-n-dice.desktop を slice-n-dice.desktop.in (.in 接尾辞は伝統的なものです) にコピーして、 Name と Comment タグの前に下線(_) を加えます。 マークアップの後ではファイルは次のようになります。

[Desktop Entry]
Encoding=UTF-8
_Name=Slice 'n' Dice
_Comment=Chop things up into shapes
Exec=slice-n-dice
Icon=slice-n-dice.png
Terminal=false
Type=Application
Categories=GNOME;Application;

一度 項3. 「パッケージのビルドインフラに i18n [の仕組み]を取り込み 」 セクションでの変更を施したら、 slice-n-dice.desktop.in だけを残して slice-n-dice.desktop は削除するべきです。 ビルドプロセスはこのテンプレートに翻訳を統合し、 すべての利用可能なロカールについての文字列を含む desktop ファイルを生成します。

要求に応じてコンポーネントをアクティブにする bonobo-activation-server が呼ぶアプリケーションは、 どのようにアクティブにするかを記述し、[自身についての]説明文を含む .server という拡張子を持つファイルを持っています。 そして、これらのファイルについても翻訳のために同様にマークアップする必要があります。

desktop ファイルと同じようにファイルの名前を GNOME_slice.server から GNOME_slice.server.in に変更します。 そしてファイルを開き、 type="string" 属性を持つ <oaf_attribute> タグを編集します。 これらのタグは value="..." 属性を持っているので、 これを _value="..." と変更します。 こうしてマークアップを終えたら次のような数行があるはずです。

<oaf_attribute name="name" type="string" _value="Slicing factory"/>
<oaf_attribute name="description" type="string"
               _value="Factory for slicing and dicing"/>

いくつか (本当のところほとんど) のプロジェクトでは、 コンポーネントが最終的にどこにインストールされるのかといった、 configure スクリプトによって置き換えられるいくつかの変数がサーバーファイルの中に含まれているので、 サーバーファイルは既にテンプレートになっているでしょう。 よってそのファイルは既に GNOME_slice.server.in という名前になっているでしょう。 この場合は単にさらに .in 拡張子を追加した GNOME_slice.server.in.in ファイルを作成します。 intltool アプリケーションは configure が置き換えてしまう前に実行されることに注意して下さい。 そして 項3. 「パッケージのビルドインフラに i18n [の仕組み]を取り込み 」 ではただ GNOME_slice.server.in.in は intltool によって GNOME_slice.server.in に変換されるということだけ覚えておいて下さい。

ユーザーインターフェースを構築するのに Glade を使っているのなら、 glade ファイル内の文字列を翻訳できるものとわかるようにするのにマークアップする必要は特にありません。 次のセクションで設定する予定の intltool アプリケーションは、 glade 形式のファイルのどの部分 (ウィジェットラベル、メッセージ、アクセシビリティ文字列など) が翻訳可能であるか知っていて、自動的にそれらを抽出します。

唯一つだけ、Glade を使っているときには、 オプションボックスの LibGlade タブの中の 翻訳可能な文字列を保存する を設定しないようにしておく必要があります。 代りに Glade が自動的にマークアップ文字列を含むファイルを生成します。

もしアプリケーションが任意の形式の XML ファイルを伴うのなら、 同様にそれらのファイルの一部を翻訳のためにマークアップすることができます。 前と同じように slice.xml を slice.xml.in と名前を変更します。 それからファイル全体を通して翻訳するべき要素を下線でマークします。 例えば、

<type level="safe">
   <shape>blunt triangle</shape>
   <description>Creates a triangle without sharp corners.</description>
</type>

を次のようにマークアップします。

<type level="safe">
   <shape>blunt triangle</shape>
   <_description>Creates a triangle without sharp corners.</_description>
</type>

<description> タグを翻訳のためにどのようにマークアップしているかわかるでしょう。 また閉タグも同様に変更され、 (おそらく元々の同じ DTD には従っていないけれども) そのファイルがなおも well-formed XML となっていることにも注意して下さい。

Gconf が使う schema ファイルにはキーの長短[様々な]説明が含まれていることがあり、 これらの文字列は明らかに翻訳の候補となります。 また schema ファイル中のキーも、 より適切なものにローカライズするべきという意味で、翻訳可能なデフォルト値を持ち得ます。 例えば、金融[関係の]アプリケーションは C ロカールで Stock Exchange キーのデフォルト値として "New York" を持っているかもしれませんが、 de [ドイツ] ロカールではこのキーのデフォルト値は "Frankfurt" である方がよいはずです。

schema ファイルから引き出す適切なキーを持つための方法は、 それらを <locale> 要素でくるみ、 オリジナルファイルのロカールを C と指定することです。 上述の金融アプリケーションの場合例えば次のようになります (いくつかの行は冗長なので省略しています)。

<schema>
   <key>/schemas/apps/finance/preferences/current_market</key>
   ...
   <locale name="C">
      <default>New York</default>
      <short>Current stock exchange</short>
      <long>This key holds the name of the stock exchange that
      we are currently querying. It can have any string value 
      that corresponds to a world market.</long>
   </locale>
</schema>

<locale name="C"> 要素内の説明文やデフォルト値を持たないキーは翻訳されません。 普通は長短[様々な]説明文についてはすべて翻訳したいと思うでしょうが、 デフォルト値についてはほんのたまにそうしたいと思うだけでしょう。

残念ながら今のところ (gtk-doc によって生成されるような) ユーザーまたは API ドキュメントを翻訳者のために一貫した形式に変換するための簡単な方法はありません。 基本的にユーザードキュメントはソースドキュメントを通じて手作業で翻訳しなければなりません。 API ドキュメントは今のところ国際化をサポートしていません。