GNU gettext utilities: Overview

以下は、GNU gettextで処理されるファイル群の関連と、それらを処理するツールをまとめたダイアグラムです。以降の詳細な説明は、このダイアグラムを見ながら読み進めてください。これらのファイルやツールの相互作用への明確な理解は、プログラマー、翻訳者、メンテナーにとって確実に役に立つものです。

Original C Sources ───> Preparation ───> Marked C Sources ───╮
                                                             │
              ╭─────────<─── GNU gettext Library             │
╭─── make <───┤                                              │
│             ╰─────────<────────────────────┬───────────────╯
│                                            │
│   ╭─────<─── PACKAGE.pot <─── xgettext <───╯   ╭───<─── PO Compendium
│   │                                            │              ↑
│   │                                            ╰───╮          │
│   ╰───╮                                            ├───> PO editor ───╮
│       ├────> msgmerge ──────> LANG.po ────>────────╯                  │
│   ╭───╯                                                               │
│   │                                                                   │
│   ╰─────────────<───────────────╮                                     │
│                                 ├─── New LANG.po <────────────────────╯
│   ╭─── LANG.gmo <─── msgfmt <───╯
│   │
│   ╰───> install ───> /.../LANG/PACKAGE.mo ───╮
│                                              ├───> "Hello world!"
╰───────> install ───> /.../bin/PROGRAM ───────╯

プログラマーが自分のパッケージにGNU gettextを導入するときに最初に行うことは、Cソース中のどの文字列が翻訳可能で、どの文字列が翻訳不可かを識別することです。この退屈な作業は、emacsのPO modeを使用することにより多少は快適になりますが、Cソースを編集するのに、あなた自身が慣れ親しんだものを使用することもできます。その他に必要となる標準的な変更としては、翻訳用のライブラリーを正しく初期化することなどです。これらに関する詳細はSourcesを参照してください。

新しく記述するソフトウェアについては、ソフトウェアを記述するときにそのような文字列をマークできますし、そうするべきでしょう。このような文字列にたいするgettextのアプローチ方法としては、手始めに各ファイルの先頭または中心的なヘッダーファイルに、以下の行を追加するという、非常に簡単なものです:

#define _(String) (String)
#define N_(String) String
#define textdomain(Domain)
#define bindtextdomain(Package, Directory)

これで、インターナショナリゼーションのためのソースの準備ができました。後で実際にgettextを使う準備ができたら、これらを以下の定義で置き換えてください:

#include <libintl.h>
#define _(String) gettext (String)
#define gettext_noop(String) String
#define N_(String) gettext_noop (String)

libintl.aとlibintl.soにリンクする必要もあります。GNUシステムでは、gettextライブラリーの関数はGNU libcにすでに含まれているので、libintlにリンクする必要がないことに注意してください。

一度Cソースが変更されると、翻訳可能なすべての文字列を検索、抽出してPO templateファイルに出力するのに、xgettextが使用されます。このpackage.potファイルには、オリジナルのプログラムのすべての文字列が含まれています。これらの文字列は、その文字列がCソース中で使用されている場所へのポインターを持っており、すべての翻訳文字列は空文字列に初期化されています。.potのtという文字は、このファイルがテンプレート(Template)のPOファイルであり、まだ特定の言語用ではないことを示します。どのようにxgettextプログラムが呼び出されるかについては、xgettext Invocationを参照してください。もしあなたが本当に怠け者の場合、少し手間をかけてディストリビューション全体をセットアップするのに興味があるかもしれません(Maintainersを参照してください)。この方法では、xgettextコマンドをタイプするのを省略してmakeとタイプするだけで、自動的に適切なものを生成することができます。

最初はまだlang.poがないので、msgmergeのステップはとばして、単にpackage.potがlang.poとしてコピーされます。ここでlangは対象となる言語です。詳細については、Creatingを参照してください。

次はメッセージの最初の翻訳です。翻訳それ自身が全体として今だ人手に頼らねばならないものであり、その複雑さはこのマニュアルの取り扱う範囲を超えるものです。翻訳チームに連絡したり、チームの一員になって、同じネイティブ言語を作業対象とする他の人たちとあなたの翻訳を共有する方法等、いくつかのヒントについては、このマニュアルの他のチャプターで触れています(Translatorsを参照してください)。

POファイルlang.poに翻訳したメッセージを追加するときに、POファイル編集用のエディター(Editingを参照してください)を使用していない場合は、POファイルのフォーマットに合わせて作業したり、文字列を引用符で括る規則など(PO Filesを参照してください)について自分で気を遣わなければなりません。これは不可能な作業ではなく、実際に1995年頃には多くの人がPOファイルを取り扱っていた方法です。一方、POファイルエディターは、POファイルエディター自身の使い方を覚える必要はありますが、あなたにかわってエディターがPOファイルに関する詳細を取り扱ってくれます。

既に何らかの翻訳がCompendium POファイルに保存されている場合、翻訳者はPOモードを使って翻訳されていないエントリーをCompendiumから初期化したり、翻訳を選択してCompendiumに保存したり更新することができます(Compendiumを参照してください)。Compendiumファイルは、翻訳チームのメンバー間で共有するように意図されたものです。

プログラムやプログラムのパッケージは、ユーザーがバグ報告や改良のための提案をして、メンテナーが様々な方法でプログラムを変更して対応するという、動的な性質を持ちます。パッケージがすでにインターナショナライズされているという事実により、メンテナーがパッケージに文字列を追加したり、すでに翻訳された文字列を変更することをためらうようにさせるべきではありません。彼らは、彼ら自身がスムーズに作業できるようにベストを尽くすだけです。メンテナーはすでに負荷の掛かった双肩に、翻訳に関する心配事を背負いこまなないようにしてください。そして翻訳者はプログラミングの心配事からは自由でいるようにしてください。

メンテナーが心配すべきなのは、文字列が翻訳されるべきときに翻訳可能であるように文字列をマークすることであり、文字列がいつ翻訳されるかについては、適切な時がくれば翻訳されるものだと割り切るべきです。xgettextは、時間をかけて進化してきたpackage.potを再び構築し、その結果、翻訳を含んだlang.poは徐々に古くなっていきます。

翻訳者(そしてメンテナー)にとって重要なのは、パッケージの翻訳はパッケージが誕生した時に1度行えばよいというものではなく、パッケージの生涯において繰り替えされる継続的なプロセスだと理解することです。あるパッケージにたいして最初の翻訳を行った後、時々手入れをすることが必要です。なぜなら翻訳が必要な新しい未翻訳の文字列が出現することにより、翻訳された文字列があちこちで古くなっていくからです。

msgmergeプログラムは、すでに存在するlang.poファイルを、xgettextで最新の C ソースから抽出された、より新しいpackage.potテンプレートファイルと比較して更新するという目的を持っています。更新の処理はプログラムの変更により変更された、Cソース中の文字列の位置にたいする参照を調整します。同様に、msgmergeはすでに翻訳されているがプログラムのソースに存在しなくなった、古い翻訳のコメントアウトも行います(Obsolete Entriesを参照してください)。そして最後に新しい文字列を未翻訳の文字列として、結果であるPOファイルに挿入します(Untranslated Entriesを参照してください)。msgmergeが実際に何を行うかについては、msgmerge Invocationを参照してください。

目的に至る経路と手段が何であれ、翻訳のためのすべての文字列を提供する更新されたlang.poがゴールなのです。

POファイルが変動し流動する一時的なものであるという性質は、翻訳というゲームでの不可欠な部分であり、よく理解して受け入れる必要があります。翻訳プロジェクトに参加する人はこの性質に苦労し、他の翻訳プロジェクトのメンバーに苦労をかけることもあるのです! 特にメンテナーは、たとえ最近は更新されていないディストリビューションでも、翻訳チームに早く仕事を終えるようにプレッシャーを与えず、リラックスして利用可能でオフィシャルなすべてのPOファイルをディストリビューションに含めましょう。プレッシャーを与えるのはむしろ、特定の言語を話すコミュニティーのユーザーなので、メンテナー自身も安心して翻訳ファイルの妥当性を考慮するべきです。一方翻訳者は、パッケージがオフィシャルのディストリビューションに向けた事前テストを行っているときに、自分が担当するPOファイルを合理的に更新する事を試みる必要があります。

1度POファイルが完成して信頼できる物になると、POファイルはmsgfmtプログラムによって、パッケージのプログラムが実行時に必要な時はいつでも効率的に翻訳を取得できるよう、マシン向けのフォーマットに変換されます(MO Filesを参照してください)。msgfmtプログラムのすべての実行モードについては、msgfmt Invocationを参照してください。

最後に、変更およびマークされたCソースがコンパイルされて、GNU gettextライブラリーとリンクされます。これは通常、プロジェクトのための適切なMakefileと共に、makeコマンドを実行することにより行われ、結果としてユーザーが見つけることのできる場所に実行可能ファイルがインストールされます。MOファイル自身も適切にインストールされる必要があります。これで適切な環境変数(Setting the POSIX Localeを参照してください)をセットすると、プログラムを実行すればいつでも自分で自動的にローカライズするようになります。

このマニュアルの残りの部分では、上述の様々なステップを掘り下げて説明することを目的とします。

1.5 GNU gettextの概要

1.5 GNU `gettext`の概要