GNU gettext tools, version 0.19.8.1

Native Language Support Library and Tools

Edition 0.19.8.1, 25 March 2016

GNU gettext utilities

This manual documents the GNU gettext tools and the GNU libintl library, version 0.19.8.1.

 — The Detailed Node Listing —



Introduction

The User’s View

Setting the Locale through Environment Variables

Preparing Program Sources

Making the PO Template File

Creating a New PO File

Updating Existing PO Files

Editing PO Files

Emacs’s PO File Editor

Using Translation Compendia

Manipulating PO Files

Highlighting parts of PO files

Producing Binary MO Files

The Programmer’s View

About catgets

About gettext

Temporary Notes for the Programmers Chapter

The Translator’s View

Organization

National Teams

The Maintainer’s View

Files You Must Create or Alter

Autoconf macros for use in configure.ac

Integrating with Version Control Systems

Other Programming Languages

The Translator’s View

Individual Programming Languages

sh - Shell Script

Perl

Internationalizable Data

Concluding Remarks

Language Codes

Licenses

1 イントロダクション

このチャプターでは、GNU gettextが作られた目的と、フリーの翻訳プロジェクトについて説明します。それから、ネイティブ言語サポート(NLS: Native Language Support)にまつわる広義の概念をいくつか説明します。また国や文化の差異を他の側面から考慮した際に、翻訳したメッセージをプログラムに適用することが、どのような位置づけになるかを説明します。さらに翻訳に使用されるファイルを説明し、最初の翻訳において様々なツールがそれらのファイルをどのように生成、相互作用するのか、そして通常のメンテナンスサイクルにおいてどのように処理されるかについて説明します。

このマニュアルでは、プログラマーやメンテナーを指すときには彼という言葉を使用します。そして翻訳者を指すときは彼女、翻訳されたプログラムをインストールする人やエンドユーザーのことを指すときは彼らという言葉を使用します。これの目的はドキュメントを明解にするのが唯一の目的であり、決して各々の役割が男性、もしくは女性に適しているという意味ではまったくありません。あなたが想像するように、GNU gettextは性別、人種、宗教、国籍に関わらず、コンピュータを使用する人にとって有用なものなのです!

提案や訂正は下記にメールしてください:

Internet address:
    bug-gnu-gettext@gnu.org

メールのメッセージに、マニュアルのバージョン番号と更新日付を記入してください。

1.1 GNU gettextの目的

プログラムは通常、英語でドキュメントされており、実行時にユーザーと相互作用する場合にも英語が使用されます。これはGNUソフトウェアに限らず、多くのフリーソフトウェアにも当てはまる話です。開発者やメンテナー、すべての国々のユーザー同士でコミュニケーションする場合、共通の言語を使用するほうが便利です。一方、ほとんどの人は英語より自分の母国語を好み、日々の仕事にも可能な限り母国語を使用しています。単純に言うと、ほとんどの人は英語より母国語がコンピューターのスクリーンに表示されるのを愛するのです。

しかし多くの人にとって、これは時間をかけて考える価値がないと片付けてしまう夢かもしれません。彼らは結局、この夢を実現できる自信がないのです。しかし希望を失わずに、組織を作った人たちもいます。この翻訳プロジェクトは、これらの希望を作業可能な形に形式化して、私たちのすべてが真の多言語機能を兼ね揃えたプログラムと呼べるものを手にするチャンスなのです。

GNU gettextは、他の多くのステップを構築する資産であり、翻訳プロジェクトにとって重要なステップです。このパッケージは、プログラマー、翻訳者、そしてユーザーにたいして、統合されたツールとドキュメントを提供します。特に GNU gettextユーティリティーは、他のパッケージに多言語化されたメッセージを生成するためのフレームワークを提供するツール群です。このツールには以下のものが含まれます:

• メッセージカタログをサポートするために、プログラムをどのように記述すべきかの規則。
• メッセージカタログのディレクトリーやファイル名の命名方式。
• 翻訳されたメッセージの取得をサポートする実行時ライブラリー。
• 翻訳可能なメッセージや、既に翻訳されたメッセージを取り扱うための、スタンドアローンプログラム群。
• 翻訳可能なメッセージが含まれたファイルの解析、生成をサポートするライブラリー。
• これらのセットを準備して最新の状態に保つための、Emacs¹用のスペシャルモード。

GNU gettextは、プログラムのソースを国際化する際の影響を最小化し、その影響を可能な限り小さく保つようにデザインされています。プログラムソースを見たときに、その影響が軽微、または少なくとも軽微に見えることにより、国際化が成功する可能性が高くなります。

翻訳プロジェクトは、翻訳プロジェクトの構造や手法を記述する手段としても、GNU gettextディストリビューションを使用しています。これは、この文書がGNU gettextの技術面に限定して適切に記述された文書であることを超えるものであることを意味します。そうすることにより、翻訳者は翻訳作業を適切に行うために知る必要のあるすべてのことを、可能な限り単一の場所で見つけることができます。この補足的な文書により、プログラマーさらに好奇心のあるユーザーは、GNU gettextが翻訳プロジェクト以外の場所とどのように関連しているかを理解し、大きな絵を垣間見ることができます。

1.2 i18n、l10n、などなど

プログラムによるネイティブ言語サポートを議論する際に、2つの長い単語が出現します。これらの単語には正確な意味づけがあり、このドキュメントでも使用する単語なので、ここで説明しておきましょう。使用される2つの長い単語とは、インターナショナリゼーション(internationalization)とローカリゼーション(localization)です。これらの単語を何度も何度も書くうちに、多くの人たちがi18nやl10nと記述するようになりました。この表現は単語の最初と最後の文字と、それらの文字の間にある文字数によって、それぞれの単語を略記したものです。しかしこのマニュアルではわかりやすくするために、略記を用いずに正式な単語を使用することにします。

インターナショナリゼーション(国際化)とは、プログラムやパッケージに含まれるプログラムのセットが多言語を認識しサポートする操作のことを指します。インターナショナリゼーションとは、英語の文字列でしかプログラムがを呼び出せないとか、英語以外の特定の言語の持つ習慣に縛られるといったことなく、同じ操作を一般的な方法で結びつけさせるための汎化のプロセスです。プログラムの開発者は、彼のプログラムをインターナショナライズするために様々なテクニックを使うことでしょう。それらのいくつかは標準化されています。そのうちの1つが GNU gettextなのです。プログラマーの視点を参照してください。

ローカリゼーション(地域化)とは、それを行うことによりすでにインターナショナライズされた一連のプログラムが必要とするすべての情報を受けとることができ、任意のネイティブ言語や文化的な習慣に従った方法による入出力に適応させることができるような操作のことを意味します。ローカリゼーションとは、一般的なメソッドを実装済みのインターナショナライズされたプログラムを特定の方法で使用する、特化のプロセスです。プログラミング環境はプログラマーにたいして、実行時に設定できるいくつかの機能を提供します。翻訳対象の単位として同じネイティブ言語同士をまとめた、任意の国がもつ特定の文化的な習慣の形式的な説明を、その言語や国のlocaleと呼びます。ローカライズされたプログラムを使用するユーザーは、プログラムを実行する前にプログラムがどのlocaleを使用するべきかを、特定の環境変数に設定します。

実際にはlocaleメッセージのサポートとは、特定のlocaleを形成する文化的なデータの単一のコンポーネントのことです。インターナショナライズされたソフトウェアを開発するプログラマーを支援するために、特定のlocale に保存されたデータにアクセスできるルーチンと関数を提供するライブラリーがあります。誰かが特定のlocaleを参照する場合には、特定のlocaleに保存されているデータを参照することになります。同様に、プログラマーが “locale ルーチンへのアクセス” を参照するということは、すべてのlocale情報にアクセスできる完全なルーチンの一式を参照するのと同じです。

ネイティブ言語サポート(Native Language Support、または単にNLS)という表現は、インターナショナリゼーションとローカリゼーションの両方により、プログラムが多言語と相互作用できる動作や機能の全体を指すときに使用します。一言で言うと、インターナショナリゼーションとはローカリゼーションを可能にする操作とも言えます。

大まかに言うと、多言語によるメッセージを処理する場合、インターナショナリゼーションはプログラマーによって処理され、ローカリゼーションは翻訳者によって処理されるとも言えます。

1.3 ネイティブ言語サポートの側面

完全な多言語ディストリビューションを配付するためには、出力メッセージの翻訳以外に多くの事柄があります。

• 現在の GNU gettextが提供するのは、Cプログラムが出力するメッセージを翻訳するための完全なツールセットです。しかしperlスクリプトとシェルスクリプトも同様に翻訳される必要があります。現在これらを翻訳するための方法があったとしても、本来あるべき形での統合はされていません。
• autoconfやbisonのような一部のプログラムは、他のプログラム(またはスクリプト)を生成することができます。たとえプログラムを生成するプログラムがインターナショナライズされていても、生成されたプログラムは独自にインターナショナリゼーションする必要がありますが、これらの間接的に行われるインターナショナリゼーションは生成プログラムで自動化できるはずです。しかし実際は生成するプログラムと生成されるプログラムは、それぞれ独自にインターナショナライズされるのが極めて一般的です。
• 数は多くありませんが、プログラム自体に含まれた文字列とは別に、翻訳が必要となるテキストのテーブルを含むプログラムもあります。例えばRFC 1345は、recodeプログラムが実行時に文字を再構築するための、文字に対応する説明的な英語名を提供します。これらの説明的な名前はRFCから機械的に取り出されるため、RFC自体を事前に翻訳する必要があります。
• 大抵のプログラムにはオプションを指定することができますが、多くの場合は英語を読める人にたいして説明的なものが使用されています。このようプログラムのオプションについても、翻訳されたバージョンを提供することを考慮する必要があります。
• 多くのプログラムは、本質的には翻訳可能な何かを、読み込み、解釈、コンパイルしたり、そのようなキーワードや識別子のテキストを含む入力ファイルによって何かを行ったり、応答を返したりします。例えばgccに識別子の文字を区別できるようにさせたり、‘rm -i’が‘y’や‘n’ではない、翻訳された応答をユーザーから受け取れるようにしたいと思うかもしれません。最終的にプログラムのほとんどの出力が他言語によるものだったとしても、入力の構文やオプションに指定できる値などを、ローカライズ可能かそうでないかを決定したいと思うかもしれません。
• パッケージに付随するマニュアル、及びディストリビューションのドキュメントファイルも同様に、翻訳される可能性があります。マニュアルの翻訳と、それ以降のアップデートは、一般的にはそれ自体が主要な作業です。

すでに述べたように、翻訳とはlocaleの1つの側面に過ぎません。インターナショナリゼーションの他の側面にはシステムのサービスがあり、これは GNU libcにより処理されます。国々の文化的な慣習を定義するための多くの属性があります。これらの属性には、国々のネイティブ言語に即した日付や、時刻書式と数値表記、通貨記号などが含まれます。これらの地域的なルールは、その国のlocaleと呼ばれます。localeとは、その国のネイティブな属性をサポートするために必要となる知識を表します。

国ごとの差異にしたがってlocaleを記述しなければならない、主要な領域がいくつかあります。以下のリストは、localeに関連したその他のタスクの適切なコンテキストにおいて、多言語メッセージを配置する手助けになるでしょう。詳細については GNU libcのマニュアルを参照してください。

文字とコードセット

米国や世界中の、英語を話す地域で最も一般的に使用されるコードセットは、ASCIIコードセットです。しかしこのコードセットには、様々なlocaleで必要とされる文字が含まれていません。8ビット ISO 8859-1コードセットは主要なヨーロッパの言語で処理する必要がある特殊文字をほとんど持っているにもかかわらず、主要なヨーロッパの通貨を処理することができない等、多くの場合はISO 8859-1を選択するだけでは十分ではないのです。したがってそれぞれのlocaleは、使用するコードセットの選択と、そしてそのコードセットに対処するための適切な文字列処理ルーチンが必要になります。

通貨

通貨記号は国ごとに異なり、それぞれの通貨記号の使用する位置も異なります。それぞれのlocaleにたいするネイティブモードで、ソフトウェアはそれを意識させずに通貨の数字を表示できる必要があります。

日付

日付の書式はlocaleごとに異なります。例えば1994年のクリスマスは、米国では12/25/94と記述し、オーストラリアでは25/12/94、それ以外の国ではISO 8601の日付書式を使用する、といった具合です。

1日の中で使用される時刻も、hh:mm、hh.mm、などのように記述されます。あるlocaleでは時刻はAM/PMではなく、24時間制で指定する必要があります。しかも夏時間の補正は国ごとに大きく異なります。

数値

数値の表記はlocaleごとに異なります。以下はそれぞれのlocaleに対応する、正しい数値表記の例です:

12,345.67       English
12.345,67       German
 12345,67       French
1,2345.67       Asia

メートル法とポンドヤード法のように異なる単位系を使用したり、それらの変種で数値表記する方法を採用しているプログラムもあります。

メッセージ

localeによる言語サポートにおいて、最も明確な領域です。GNU gettextは、localeでのメッセージのサポートという領域において、ソフトウェアがユーザーとコミュニケーションするときに使用する言語を、開発者とユーザーが簡単に変更する手段を提供します。

これらの文化的な慣習の領域は、localeカテゴリー(locale categories)と呼ばれます。この用語は、localeの側面(locale aspects)やlocale機能のカテゴリー(locale feature categories)といった用語よりも劣っているのが残念です。なぜならそれぞれの“localeカテゴリー”は、ローカリゼーションが要求される、ある領域やタスクについて記述するからです。そのような領域や特定の文化にたいして、文化的な慣習を説明する具体的なデータもlocaleカテゴリーと呼ばれます。この意味では、localeとは、コードセットを定義するlocaleカテゴリー、数値の書式を定義するlocaleカテゴリー、翻訳されたメッセージを定義するlocaleカテゴリー、などのように、いくつかのlocaleカテゴリーから構成されているといえます。

メッセージ処理以外のlocaleコンポーネントは、標準ISO CとPOSIX:2001標準(SUSV3 specificationとも呼ばれる)です。GNU libcはこれを完全に実装しており、その他の現代的なシステムも、欠けているコンポーネントにたいする、必要最小限のより実用的なサポートを提供しています。

1.4 翻訳を伝達するファイル

.poファイルのPOはPortable Objectの頭文字であり、.moファイルのMOはMachine Objectの頭文字です。このパラダイムはPOファイルのフォーマットと同様に、Uniforumで開発されたNLS標準にもとづき、SunのSolarisシステムで実装されたものです。

POファイルは人間が読んだり編集することを意図しており、あるパッケージの特定のターゲット言語のための、翻訳可能なオリジナル文字列の集まりです。1つの言語にたいして、1つのPOファイルが割り当てられます。パッケージが複数の言語をサポートする場合、サポートする言語ごとにPOファイルを持ち、パッケージごとにパッケージがサポートする言語ごとのPOファイルを持っています。これらのPOファイルはxgettextプログラムによって作成され、アップデートや更新はmsgmergeプログラムによって行われます。xgettextプログラムはCファイルからマークされたメッセージを抽出し、空の翻訳文字列で初期化されたPOファイルを作成します。msgmergeプログラムは、リリースの間に変更されたソースファイルにたいして、不要なエントリーのコメント化や新しい文字列の初期化、および参照するソース行を更新したりします。この種のファイルは配布物中にの.potという拡張子のファイルとして含まれ、書式はPOファイルと同じです。

MOファイルは、プログラムが読み込むことを意図した、バイナリーのフォーマットのファイルです。ネイティブ言語サポートの一部として、MOファイルを作成したり処理することのできる既存のシステムもいくつかありますが、MOファイルのフォーマットがシステムごとに異なっているため可搬性がありません。また、これらのシステムが提供する既存のツールは、GNU gettextのすべての機能をサポートしていません。そのためGNU gettextは、MOファイルに独自のフォーマットを使用しています。拡張子.gmoが実際のMOファイルで、これらのファイルはGNUのフォーマットを使用しています。

1.5 GNU gettextの概要

以下は、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ソースを編集するのに、あなた自身が慣れ親しんだものを使用することもできます。その他に必要となる標準的な変更としては、翻訳用のライブラリーを正しく初期化することなどです。これらに関する詳細はプログラムソースの準備を参照してください。

新しく記述するソフトウェアについては、ソフトウェアを記述するときにそのような文字列をマークできますし、そうするべきでしょう。このような文字列にたいする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プログラムの呼び出しを参照してください。もしあなたが本当に怠け者の場合、少し手間をかけてディストリビューション全体をセットアップするのに興味があるかもしれません(メンテナーの視点を参照してください)。この方法では、xgettextコマンドをタイプするのを省略してmakeとタイプするだけで、自動的に適切なものを生成することができます。

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

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

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

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

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

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

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

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

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

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

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

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

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

2 ユーザーの視点

最近では、ユーザーがコンピューターにログインしたときには通常、プログラムがネイティブ言語でメッセージを表示するのを目にすることができます – 少なくともフリーソフトウェアやGNUプロジェクトに関わる人が少ないHindiやFilipinoなどの言語ではない、FrenchやGermanなどの言語による活発なフリーソフトウェアコミュニティーのユーザーは目にすることができるでしょう。

これはどのような仕組みで動くのでしょう? ユーザーはどのようにして、プログラムで使用する言語にたいして影響を与えることができるのでしょうか? このチャプターではこれらの疑問にお答えします。

2.1 オペレーティングシステムのインストール

デフォルトで使用する言語は、すでにオペレーティングシステムのインストールの時点で決定されている場合があります。オペレーティングシステムがインストールされるときは通常、インストーラーがインストール中に使用する言語とは別に、インストールされるシステムで使用する言語を尋ねます。言語を1度しか尋ねないOSインストーラーもあります。

これにより、すべてのユーザーにたいする、システム全体でのデフォルト言語が決定されます。追加の言語としてデフォルト言語以外のローカリゼーションを指定できるインストーラーもあります。たとえばKDE(K Desktop Environment)のローカリゼーションやOpenOffice.orgは、言語ごとにインストールできるパッケージが個別にバンドルされています。

これはマシンの使用目的を考える、よい機会です。個人的に使用するマシンの場合、追加のローカリゼーションはおそらく必要ありません。国際的なつながりをもつ組織や企業で使用するマシンの場合、ゲストユーザーのことも考えられます。海外から1週間程度の予定でゲストを迎える場合、彼のお好みのlocaleは何でしょうか? そのコストがディスクスペースを少し余分に消費するだけならば、あらかじめ追加のローカリゼーションをインストールする価値があるかもしれません。

システム全体のデフォルト言語は、新しいアカウントを作成するときのlocale設定で使用されます。しかしユーザーは同じマシンの他のユーザーとは異なる、自分自身のlocale設定を持つことができます。次のセクションで説明するようにユーザーは通常、最初のログイン後に自分のlocaleを指定することができます。

2.2 GUIプログラムを使用したlocaleのセッティング

すぐに利用可能なプログラムは、“デスクトップ環境”とも呼ばれるユーザーのデスクトップで、それにはウィンドウマネージャーやウェブブラウザー、それにテキストエディターなどが含まれます。一般的なデスクトップとしてはKDE、GNOME、Xfceなどがあります。

デスクトップ環境のGUIプログラムで使用されるlocaleは、“control center”、“language settings”、“country settings”などと呼ばれる設定画面で指定できます。

デスクトップ環境に属さない個別のGUIプログラムは、設定パネルや環境変数を通じて、自身のlocaleを持つことができます。

環境変数を通じてlocaleを指定できるプログラムには、デスクトップのlocaleとは異なるlocaleを指定できるものもあります。これはプログラムをメニューやファイルシステムから起動するかわりに、コマンドラインから環境変数を指定した後にプログラムを起動するということです。環境変数の設定については、次のセクション(環境変数を通じたlocaleのセッティング)で説明します。ただしKDEのあるバージョンでは、localeをLANGやLC_ALLではなくKDE_LANGで設定します。

2.3 環境変数を通じたlocaleのセッティング

もっとも単純なケースは、あなたの言語がこのパッケージにしたがってインストールされている場合で、環境変数LANGに適切な‘ll_CC’の組み合わせを指定するだけです。たとえばあなたがGermanyに住んでいてGermanを話すとしましょう。この場合はシェルプロンプトで単に、‘setenv LANG de_DE’(cshの場合)、‘export LANG=de_DE’(shの場合)、‘export LANG=de_DE’(bashの場合)と実行します。1度これを.loginや.profileに記述しておけば、毎回適用することができます。

2.3.1 locale名

localeの名前は通常、‘ll_CC’という形式で表されます。ここで‘ll’はISO 639による2文字の言語コード、‘CC’はISO 3166による国コードを記述します。たとえば国がGermany、言語がGermanの場合、llはde、CCはDEとなります。言語コードと国コードについては、付表Language Codesと付表Country Codesを参照してください。

国コードも指定するのは冗長だと思うかもしれません。しかし、実際にいくつかの言語は国ごとに方言をもつものがあります。たとえば、‘de_AT’はAustria、‘pt_BR’はBrazilで使用されます。国コードはこの様な方言を区別するのに役立つのです。

多くのlocale名は‘ll_CC.encoding’という拡張形式で文字のエンコーディングを指定できます。これは多くのユーザーが2000年から2005年にかけてUTF-8に移行したためです。たとえば現在のglibcシステムのGerman localeは‘de_DE.UTF-8’です。‘de_DE’という古いlocale名は、2000年時点で使用されていたISO-8859-1(ユーロ通貨記号を持たない)が格納された文字列を参照するのに現在も使用されます。

‘ll_CC’のかわりに、‘ll_CC.@variant’を使うlocale名もあります。‘@variant’により、言語(ll)と国(CC)では提供できないような特性を示すことができます。これにより特定の通貨単位を示すことができます。たとえばglibcシステムでは‘de_DE@euro’は、2002年以前の通貨記号で使用されていた‘de_DE’ではなく、ユーロ通貨を使用するlocaleを示します。また、言語の方言や筆記に使用される方法(たとえば‘sr_RS@latin’は、‘sr_RS’によりSerbianをCyrillicで筆記するのに、Latin筆記を使用することを示す)、正書法(orthography rule)を使用するか、などを示すことができます。

その他のシステムでは、単に‘ll’と指定したりする等、このスキームの様々なバリエーションが使用されています。あなたの言語でサポートされているlocaleの一覧は、‘locale -a | grep '^ll'’を実行して取得することができます。

‘C’と呼ばれる特別なlocaleもあります。これはすべてのlocaleを無効にするときに使用します。このlocaleでは、すべてのプログラムがPOSIX標準で指定された英語のメッセージと、指定されていない不特定の文字(たいていはUS-ASCIIですが、オペレーティングシステムによってはISO-8859-1やUTF-8のときもあります)を使用します。

2.3.2 localeの環境変数

localeは複数のlocaleカテゴリー(locale categories)から構成されています(ネイティブ言語サポートの側面を参照してください)。プログラムがlocaleに依存する値を参照する場合は、以下の環境変数を優先度順に参照します:

1. LANGUAGE
2. LC_ALL
3. LC_xxxは、xxxに対応するlocaleカテゴリーです: LC_CTYPE, LC_NUMERIC, LC_TIME, LC_COLLATE, LC_MONETARY, LC_MESSAGES, ...
4. LANG

変数に空の値がセットされている場合は、無視されます。

LANGはlocaleを指定するときに通常使われる環境変数で、通常はユーザーもこの変数にlocaleを設定します(他の変数がシステムにより設定されていなければ、/etc/profileまたはそれに類する初期化ファイルで設定します)。

LC_CTYPE、LC_NUMERIC、LC_TIME、LC_COLLATE、LC_MONETARY、LC_MESSAGES等は、対応するlocaleのカテゴリーでLANGの設定をオーバーライドするときに使用されます。たとえば、あなたがSpainに住むSwedishのユーザーで、プログラムに数値や日付についてはSpanishの規則で表示し、メッセージだけをSwedishで表示させたいと仮定します。その場合にはlocaledefプログラムで、‘sv_ES’または‘sv_ES.UTF-8’という名前のlocaleを作成する必要があります。しかし、単にLANG変数にes_ES.UTF-8を設定し、LC_MESSAGES変数にsv_SE.UTF-8という、オペレーティングシステムに事前にインストールされている2つのlocaleを設定することで、同じ効果を得ることができます。

LC_ALLは、これらのすべてをオーバーライドするための変数です。これは通常、特定のプログラムを実行するスクリプトで使用されます。たとえばGNU autoconfにより生成されたLC_ALLスクリプトは、configurationのテストがlocaleに依存した方法で行われないように、LC_ALLを使用します。

残念ながらいくつかのシステムでは、/etc/profile等の初期化ファイルでLC_ALLが設定されています。したがってLANGを設定する場合、ユーザーはまずこの設定を解除し、必要なら他のLC_xxxも解除しなければなりません。

LANGUAGE変数については、つぎのセクションで説明します。

2.3.3 言語の優先リストを指定する

すべてのプログラムが、すべての言語に翻訳されている訳ではありません。翻訳されたメッセージが存在しない場合、デフォルトでは英語のメッセージが表示されます。あなたが他の言語を理解できる場合は、言語の優先順位のリストを設定することができます。これはLANGUAGEと呼ばれる環境変数で行います。GNU gettextはメッセージを処理するために、LC_ALLやLANGに加え、LANGUAGEによる設定を提供します。しかし他のシステムライブラリーで必要となるため、LANG(またはLC_ALL)によるプライマリー言語の設定は、依然として必要です。たとえば、あるSwedishのユーザーは、Swedishの翻訳が存在しないとき、EnglishよりもGermanに翻訳されたものが読みたいとします。そのような場合は、LANGの値は‘sv_SE’のまま、LANGUAGEの値を‘sv:de’に設定します。

Norwegianのユーザーのためのアドバイス: Norwegian言語(bokmål)は最近(2003年)、‘no’から‘nb’に変更されました。移行期間中、いくつかのこの言語のメッセージカタログは、‘nb’と、古い‘no’にインストールされるので、Norwegianユーザーは新旧どちらの翻訳も使用できるように、LANGUAGEを‘nb:no’に設定することをお勧めします。

他の環境変数とは異なり、LANGUAGE環境変数では、‘ll_CC’を‘ll’と省略することにより、その言語で主に使用される方言であることを示します。この事情により、たとえば‘de’は‘de_DE’(Germanyで話されるGermany)、‘pt’は‘pt_PT’(Portugalで話されるPortuguese)と同義です。

注意: LANGUAGE変数は、localeが‘C’に設定されている場合は無視されます。つまり、最初にローカリゼーションを利用可能にする時に、LANGUAGE変数で言語の優先順位リストを使用する前に、まずLANG(またはLC_ALL) を‘C’以外に設定する必要があります。

2.4 特定のプログラムにたいして翻訳をインストールする

GNU gettextを使用するすべてのパッケージが、各言語にたいして同様のサポートを提供している訳ではなく、翻訳は時間をかけて個々に追加されます。パッケージをインストールした後は通常、オペレーティングシステムか個々のパッケージに同梱された翻訳を使用することになります。しかし新しいローカリゼーションを直接インストールすることもできます。これを行うには、ローカリゼーションの各ファイルがファイルシステム上でどのように保存されているかを理解する必要があります。

翻訳プロジェクトに参加しているプログラムは、http://translationproject.org/team/index.htmlで見つけることができます。この情報のスナップショットは、GNU gettextに同梱されているABOUT-NLSで確認することもできます。

KDEプロジェクトのプログラムを探す場合の出発点: http://i18n.kde.org/

GNOMEプロジェクトのプログラムを探す場合の出発点: http://www.gnome.org/i18n/

他のプログラムに関しては、プログラムのソースコードパッケージにll.poのようなファイルが含まれているかどうかでチェックすることができます(po/というディレクトリーに保存されているときもあります)。各ll.poには、llで略記された言語の翻訳されたメッセージが含まれています。

3 POファイルのフォーマット

GNU gettextツールセットは、プログラマーや翻訳者が翻訳のためのファイルを生成、更新、使用する手助けをし、それらのPOファイルは主としてテキスト形式で編集可能なファイルです。このチャプターでは、POファイルのフォーマットについて説明します。

POファイルは多くのエントリーから成り立っており、それぞれのエントリーには翻訳される前の原文の文字列と、それに対応する翻訳された文字列との関連が保持されています。あるPOファイルに含まれるすべてのエントリーは通常、ひとつのプロジェクトに関連し、翻訳されたすべての文字列もひとつの言語を対象に翻訳されたものです。一般的なPOファイルのエントリーは、以下のような構造を持ちます:

white-space
#  translator-comments
#. extracted-comments
#: reference…
#, flag…
#| msgid previous-untranslated-string
msgid untranslated-string
msgstr translated-string

翻訳者は、POファイルの一般的な構造を十分に理解する必要があります。emacsのPOモードを使用すれば、フォーマットの詳細に関する最小限の知識を理解するだけで、あとはPOモードが彼女にかわって面倒を見てくれます。

以下は簡単なエントリの例です：

#: lib/error.c:116
msgid "Unknown system error"
msgstr "Error desconegut del sistema"

エントリーは任意の個数の空白文字から開始することができます。GNU gettextツールで生成された場合、エントリーとエントリーの間には通常、1つの空行があります。#の文字で始まる行はすべてコメント行として扱われます。コメントには2種類のコメントがあります。1つ目はtranslator comments(翻訳者コメント)で、#の直後にいくつかの空白文字があり、これらのコメントは翻訳者により保守、保守されます。2つ目のコメントはautomatic comments(自動コメント)で、これらのコメントはGNU gettextツールにより自動的に挿入、保守されるもので、#の直後に空白文字以外の文字があります。#.で始まるコメントはプログラマーによる翻訳者に向けたコメントを含んでいます。これらのコメントはxgettextプログラムによりプログラムのソースから抽出(extract)されるため、extracted comments(抽出コメント)と呼ばれます。#:で始まるコメントには、プログラムのソースコードへの参照(references)が含まれます。#,で始まるコメントにはフラグ(flags)が含まれています。これらのフラグについては以下で説明します。#|で始まるコメントには、以前のバージョンの翻訳済みメッセージに対応する翻訳前の文字列(previous untranslated string)が含まれています。

すべてのコメントは、オプションです。

空白文字とコメントの後には、2つの文字列を表すための文字列があります。最初の文字列は翻訳前の文字列で、これらの文字列のオリジナルはプログラムのソース中に出現する文字列です。その次の文字列は、この翻訳前の文字列に対応する翻訳後の文字列です。オリジナルの文字列はmsgidというキーワードで識別され、翻訳はmsgstrというキーワードで識別されます。これらの翻訳前と翻訳後の2つの文字列は、POファイル中で"区切りや\エスケープにより、様々な方法で引用されていますが、文字列の引用などについてはPOモードが彼女にかわり面倒をすべて見てくれるので、翻訳者はそれらの正確な引用形式に注意を払う必要がなくなります。

msgidの文字列も自動生成されたコメントと同様、GNU gettextの他のツールにより生成、管理されるので、POモードは翻訳者がそれらを変更するような操作を提供しません。それらの文字列にたいして彼女にできることは、単にそれを削除することだけで、しかもエントリー全体を削除できるだけです。一方、msgstrの文字列については、実際に翻訳者が編集するための翻訳者コメントなので、POモードは彼女の必要に応じて、完全な制御を提供します。

#,で始まるコメントは、一般的なコメントとは違いプログラムにより完全に無視されるものではないという点で、特別なコメントです。カンマで区切られたflagのリストは、ユーザーのためにより良い診断メッセージを提供するために、msgfmtプログラムにより使用されます。現時点では2つの形式のflagが定義されています:

fuzzy

このフラグはmsgmergeプログラムにより生成されるか、翻訳者自身により挿入され、msgstrの文字列が、(もはや)正しい翻訳ではないことを示します。翻訳をさらに修正する必要があるか、そのまま適用できるかは、翻訳者だけが判断できます。翻訳を完成したら、彼女はfuzzy属性を取り除きます。msgmergeは、あいまい検索(fuzzy search)によりmsgidとmsgstrエントリーを結びつけた場合のみ、このフラグを挿入します。fuzzyエントリーを参照してください。

c-format

no-c-format

これらは人間によって追加されるフラグではなく、xgettextプログラムだけが挿入するフラグです。ここで提案しているようなPOファイルを自動生成するシステムでは、ユーザーが変更を行っても、xgettextプログラムが新しいテンプレートファイルを生成するたびに、変更は上書きされてしまいます。

c-formatフラグは、翻訳前の文字列と翻訳された文字列が、C形式の文字列であることを示します。no-c-formatフラグは逆に、文字列が一見して(‘%’ディレクティブによる)C形式の文字列に見えても、C形式ではないことを示します。

文字列にc-formatフラグが設定されていると、msgfmtプログラムは、翻訳にたいして妥当性チェックのテストを追加で行います。msgfmtプログラムの呼び出し、およびキーワードの前の特別なコメントとCフォーマット文字列を参照してください。

objc-format

no-objc-format

Objective Cの場合も同様です。Objective Cフォーマット文字列を参照してください。

sh-format

no-sh-format

shellの場合も同様です。Shellフォーマット文字列を参照してください。

python-format

no-python-format

Pythonの場合も同様です。Pythonフォーマット文字列を参照してください。

python-brace-format

no-python-brace-format

Python braceの場合も同様です。Pythonフォーマット文字列を参照してください。

lisp-format

no-lisp-format

Lispの場合も同様です。Lispフォーマット文字列を参照してください。

elisp-format

no-elisp-format

Emacs Lispの場合も同様です。Emacs Lispフォーマット文字列を参照してください。

librep-format

no-librep-format

librepの場合も同様です。librepフォーマット文字列を参照してください。

scheme-format

no-scheme-format

Schemeの場合も同様です。Schemeフォーマット文字列を参照してください。

smalltalk-format

no-smalltalk-format

Smalltalkの場合も同様です。Smalltalkフォーマット文字列を参照してください。

java-format

no-java-format

Javaの場合も同様です。Javaフォーマット文字列を参照してください。

csharp-format

no-csharp-format

C#の場合も同様です。C#フォーマット文字列を参照してください。

awk-format

no-awk-format

awkの場合も同様です。awkフォーマット文字列を参照してください。

object-pascal-format

no-object-pascal-format

Object Pascalの場合も同様です。Object Pascalフォーマット文字列を参照してください。

ycp-format

no-ycp-format

YCPの場合も同様です。YCPフォーマット文字列を参照してください。

tcl-format

no-tcl-format

Tclの場合も同様です。Tclフォーマット文字列を参照してください。

perl-format

no-perl-format

Perlの場合も同様です。Perlフォーマット文字列を参照してください。

perl-brace-format

no-perl-brace-format

Perl braceの場合も同様です。Perlフォーマット文字列を参照してください。

php-format

no-php-format

PHPの場合も同様です。PHPフォーマット文字列を参照してください。

gcc-internal-format

no-gcc-internal-format

GCCソースの場合も同様です。GCC internalフォーマット文字列を参照してください。

gfc-internal-format

no-gfc-internal-format

GNU Fortranコンパイラーのソースの場合も同様です。GFC internalフォーマット文字列を参照してください。

qt-format

no-qt-format

Qtの場合も同様です。Qtフォーマット文字列を参照してください。

qt-plural-format

no-qt-plural-format

Qt plural形式の場合も同様です。Qtフォーマット文字列を参照してください。

kde-format

no-kde-format

KDEの場合も同様です。KDEフォーマット文字列を参照してください。

boost-format

no-boost-format

Boostの場合も同様です。Boostフォーマット文字列を参照してください。

lua-format

no-lua-format

Luaの場合も同様です。Luaフォーマット文字列を参照してください。

javascript-format

no-javascript-format

JavaScriptの場合も同様です。Java Scriptフォーマット文字列を参照してください。

以下のように、context specifier(コンテキスト指定子)をともなうエントリーも使用することができます:

white-space
#  translator-comments
#. extracted-comments
#: reference…
#, flag…
#| msgctxt previous-context
#| msgid previous-untranslated-string
msgctxt context
msgid untranslated-string
msgstr translated-string

コンテキスト(context)は、同じuntranslated-stringのあいまいさをなくすために提供されます。これによりPOファイルの中で、異なるcontextで、同じuntranslated-stringを複数もつことが可能になります。contextに空の文字列を指定するのと、msgctxtの行を指定しないのは、同じではないことに注意してください。

他にも、複数形式(plural form)を含む翻訳のために使用されるエントリーがあります。

white-space
#  translator-comments
#. extracted-comments
#: reference…
#, flag…
#| msgid previous-untranslated-string-singular
#| msgid_plural previous-untranslated-string-plural
msgid untranslated-string-singular
msgid_plural untranslated-string-plural
msgstr[0] translated-string-case-0
...
msgstr[N] translated-string-case-n

以下はエントリーの例です:

#: src/msgcmp.c:338 src/po-lex.c:699
#, c-format
msgid "found %d fatal error"
msgid_plural "found %d fatal errors"
msgstr[0] "s'ha trobat %d error fatal"
msgstr[1] "s'han trobat %d errors fatals"

msgidの前に、前述したmsgctxtコンテキストを指定することもできます。

ここで追加のフラグを使用できます:

range:

このフラグは正の数値範囲をともない、range: minimum-value..maximum-valueという書式で使用します。この範囲には、メッセージが受けとることができる数値を指定します。たとえばある言語では、事前に値が0から10だとわかっていれば、よりよい翻訳を生成できます。

previous-untranslated-stringは、msgmergeがメッセージをfuzzyとしてマークするとき同時にオプションとして挿入されます。これは開発者が、untranslated-stringにたいしてどのような変更を行ったかを、翻訳者が知る助けになります。

これは、POファイルの最後のエントリーに続けて、何らかの行(通常は空白文字やコメント)があるときに発生します。これらの行は、どのエントリーの一部でもなく、POファイルがツールにより処理されるときに捨てられるか、POファイルエディターの動作を妨げるときもあります。

このチャプターの残りの部分は、POファイルの正確な書式にたいしてよいアイデアを持つ人は興味があるかもしれませんが、POファイルエディターを使用する場合はスキップして構いません。しかし、POファイルを手で変更したい場合は、注意して読む必要があります。

空のuntranslated-stringは、メタ情報が含まれたヘッダーエントリー(ヘッダーエントリーを入力するを参照してください)のために予約されています。このヘッダーエントリーはファイルの最初のエントリーにすべきです。空のuntranslated-stringは、この目的のために予約されているので、他の場所で使用することはできません。

untranslated-stringとtranslated-stringはCの文法に従い、それには文字列の括り方やバックスラッシュによるエスケープシーケンスも含まれます。複数行のメッセージを記述するときは、エスケープされた改行文字を使用せずに、改行する行末の最後の文字で引用符を閉じて、POファイルの次の行で再び引用を開始します:

msgid ""
"Here is an example of how one might continue a very long string\n"
"for the common case the string represents multi-line output.\n"

この例の最初の行には、‘for’のfという文字の上に‘Here’のHを揃えるために、空の文字列が使用されています。また、キーワードmsgidの後ろには3つの文字列があり、それらの文字列は連結して使用されます。空の文字列と連結することにより文字列全体は変更されませんが、msgidの行に連結される文字列を、複数行の表示を維持しつつ左揃え表示して、配置を明確にさせるための方法です。空の文字列は省略できますがその場合、msgidの後ろに記述する最初の行は‘Here’で開始しなければなりません²。それぞれの文字列の括りの終端を改行(‘\n’)の直後にしている理由は、そうしても支障がないからというだけで、任意の文字の後で括りを終端して構いません。

文字列の括りの内側にある、行末を示す‘\n’は文字列の一部で、文字列の括りの外側の改行はPOファイル自身の行末を示し、文字列に影響を与えない点に注意してください。

文字列の外側では、空白文字とコメントを自由に使うことができます。行頭の‘#’から、その行の行末までがコメントとなります。翻訳者が記入するコメントは‘#’の後ろに空白文字をいくつか記述する必要があります。‘#’の後ろに空白文字がない場合、それは特定のGNUツールで生成・管理されるコメントとみなされ、POファイルがmsgmergeで処理されるとき、予期せず削除される可能性があります。

4 プログラムソースの準備

プログラマーのために、Cのソースコードの変更を3つにカテゴリーに分けます。1番目は、ローカリゼーション関数にメッセージ翻訳を必要とするすべてのモジュールを教えることです。2番目は、プログラムの初期化(通常はmain関数の内部)で、GNU gettextの操作を的確にトリガーすることです。3番目に、翻訳が必要なプログラム内のすべての文字列定数を識別・調整・マークする必要があります。

4.1 gettext宣言のインポート

GNU gettextが必要とするすべてのファイルが利用可能で、Makefileファイルも調整済み(メンテナーの視点を参照してください)だとすると、翻訳対象の文字列を含むCモジュールには以下の行を含める必要があります:

#include <libintl.h>

翻訳可能なCの書式指定文字列(他のCモジュールで文字列が定義されている場合も含まれます)を引数として呼び出される、printf()/fprintf()/...を含むCモジュールにも以下の行を含める必要があります:

#include <libintl.h>

4.2 gettext処理のトリガー

すべてのプログラムで、以下で示すようなlocaleデータの初期化の類が必要となります:

int
main (int argc, char *argv[])
{
  …
  setlocale (LC_ALL, "");
  bindtextdomain (PACKAGE, LOCALEDIR);
  textdomain (PACKAGE);
  …
}

PACKAGEとLOCALEDIRは、config.hかMakefileで提供される必要があります。詳細については、gettextやGNU helloのソースを眺めてみるとよいでしょう。

この場合、LC_ALLの使用は適切ではないでしょう。LC_ALLLC_ALLにはすべてのlocaleカテゴリー、特にLC_CTYPEが含まれます。この後者のカテゴリーは、プログラムのためにctype.hで定義されている、isalnum関数などで処理する文字列クラスを決定することに責任をもっており、入力される文字列の言語によってはうまく動作しません。たとえばソースコードでç(c-cedilla文字)が使用されている場合、このプログラムはFranceでは問題ありませんがU.S.では動作しません。

LC_ALLというlocaleカテゴリーに他のlocaleが使用された場合、scanf関数による数字の解析に問題が生じるシステムもあります。標準では、このような場合は"C"というlocaleとして知られる追加の書式が認識されるでしょう。しかし"C"というlocaleの書式では、数値を受け付けないシステムもあるようです。状況によっては数値の表示が"C"というlocaleなのか、それともlocalのフォーマットかにより認識できないこともあります。これは千単位の桁区切り文字を使用するときに発生します。いくつかのlocale定義ではnational conventionに従い、桁区切り文字として'.'を使用しますが、この文字は"C"というlocaleでは小数点として使用されます。

これらの理由により、上記のコードのLC_ALLの行は、setlocaleによる行に分けることが必要な場合もあります。

{
  …
  setlocale (LC_CTYPE, "");
  setlocale (LC_MESSAGES, "");
  …
}

POSIX互換のすべてのシステムでは、LC_CTYPE、LC_MESSAGES、LC_COLLATE、LC_MONETARY、LC_NUMERICおよびLC_TIMEが利用できます。ISO C準拠のみのシステムも存在し、それらのシステムにはLC_MESSAGESがありませんが、これらの不足にたいする代替は GNU gettextの<libintl.h>と、GNU gnulibの<locale.h>で定義されています。

LC_CTYPEを変更すると、<ctype.h>という標準ヘッダーファイルで定義されている関数、および<string.h>と<stdlib.h>という標準ヘッダーファイルで定義されているいくつかの関数が影響をうけることに注意してください。これが望ましくない場合(例えばコンパイラーのパーサー)、GNU gnulibのソースディストリビューションにある‘c-ctype’、‘c-strcase’、‘c-strcasestr’、‘c-strtod’、‘c-strtold’モジュールの、C localeでハードコーディングされている代替の関数を使用することができます。

環境に依存したlocaleとC localeを切り替えて使用することもできますが、この方法はsetlocaleの呼び出しが高価であること、広大なプログラムのソース中でlocaleを切り替える場所を決定するのが退屈であること、localeの切り替えがスレッドセーフではないこと等の理由により、通常は行われません。

4.3 翻訳可能な文字列の準備

文字列が翻訳可能とマークされる前に、調整が必要なこともあります。翻訳可能な文字列の準備は、その文字列をマーク(次のセクションで説明)する前に行います。文字列を準備する際に留意すべきは以下の点です。

• Englishスタイルとして正常であること。
• センテンス全体が含まれていること。
• パラグラフで分割されていること。
• 文字列を連結するのではなく、書式文字列を使用すること。
• 特殊なマークアップや制御文字を使用しないこと。

上記のガイドラインにたいする例を、いくつか見てみましょう。

翻訳可能な文字列は、正しいEnglishスタイルである必要があります。言語特有のスラングや省略語が使用されている場合、翻訳者がメッセージを理解できずに不適切な翻訳を作成してしまうことがあります。

"%s: is parameter\n"

このメッセージはほとんど翻訳不可能です。表示されるアイテムはa parameter(任意のparameter)なのでしょうか、the parameter(特定のparameter)なのでしょうか?

"No match"

メッセージに含まれるあいまいさにより、メッセージが理解できなくなっています。プログラムはファイルに何かをセットしようとしているのでしょうか? "The given object does not match the template(与えられたオブジェクトがテンプレートにマッチしない)"なのでしょうか、それとも "The template does not fit for any of the objects(そのテンプレートは任意のオブジェクトに適合しない)"なのでしょうか?

どちらのケースも、メッセージに単語を追加することにより、翻訳者とEnglishを話すユーザーの両方を助けることができます。

翻訳可能な文字列は、センテンス全体を含む必要があります。単独の動詞や形容詞を、すべてのメッセージに代替できるように翻訳するのは不可能な場合があります。

printf ("File %s is %s protected", filename, rw ? "write" : "read");

ほとんどの翻訳者はソースを見ないので、"File %s is %s protected"という、それだけでは理解できない文字列しか目にしません。これを以下のように変更します。

printf (rw ? "File %s is write protected" : "File %s is read protected",
        filename);

この方法なら翻訳者はメッセージを理解するだけでなく、適切な文法の組み立て方を見つけることが出きます。たとえばFrenchの翻訳者なら"write protected"を"protected against writing"のように翻訳するでしょう。

多くの言語では、センテンスの他の場所にある性別や数(単数形/複数形)によって、あるセンテンスの単語が変わることがあるという理由からも、センテンス全体を含めることが重要になります。Englishより強い単語間の相互関係を持つ言語もあります。たとえEnglishではうまく動作しても、多くの言語では半分に分割した2つのセンテンスを翻訳者に翻訳してもらってから、2つの翻訳を機械的に結合しても、満足な翻訳とはなりません。これが翻訳者がセンテンス全体を処理する必要がある理由です。

センテンスが1つの行に対応しない場合もあります。これは以下のように、printfステートメントを使って2つの出力により、1つのセンテンスを出力しているような場合です。

printf ("Locale charset \"%s\" is different from\n", lcharset);
printf ("input file charset \"%s\".\n", fcharset);

翻訳者は2つのセンテンスを翻訳する必要があるでしょうが、POTファイル内には2つのセンテンスが分割された1つのセンテンスだと、彼女に教える情報はありません。2つのprintfステートメントを1つにする必要があります。そうすれば翻訳者がセンテンスを一括して処理できるので、翻訳をどの位置で改行すべきか決められるようなります。

printf ("Locale charset \"%s\" is different from\n\
input file charset \"%s\".\n", lcharset, fcharset);

では以下のような隣接した2つのセンテンスの場合はどうなるでしょうか:

puts ("Apollo 13 scenario: Stack overflow handling failed.");
puts ("On the next stack overflow we will crash!!!");

上記の2つのセンテンスは、1つにまとめる必要があるでしょうか? このような場合、2つのセンテンスが互いに関連していて、一緒にしたほうが翻訳者が理解・翻訳しやすくなるようなら、マージすることをお勧めします。一方、2つのメッセージのうち1つが定型的なもので、他の場所でも使用されるようなメッセージの場合は、マージしないほうが翻訳者にとって有益です(同じメッセージが複数の箇所に出現する場合、xgettextがそれらをまとめるので、翻訳者は1度だけそのメッセージを翻訳すればよくなります)。

翻訳可能な文字列は、単一のパラグラフ(段落)に制限すべきです。1つのメッセージの長さは、10行以内にしましょう。その理由は、翻訳可能な文字列が変更されたとき、翻訳者は翻訳済み文字列全体を更新しなければならないからです。たとえ1つの単語を変更しただけでも、(現在の翻訳ツールでは)翻訳者にはそれがわからないので、彼女はメッセージ全体を校正しなければならなくなってしまいます。

多くのGNUプログラムは、‘--help’オプションにより複数画面にまたがる出力を生成します。そのようなメッセージを、1つが5行から10行のメッセージに分割するのは、翻訳者にたいする礼儀です。ドキュメント化するオプションを、入力オプションと出力オプション、情報を出力するオプションのようにグループ分けしてもよいでしょう。グループ分けすることにより、オプションを探すすべてのユーザーを助けることができます。

ハードコーディングされた文字列の結合により、English文字列を生成することがあります:

strcpy (s, "Replace ");
strcat (s, object1);
strcat (s, " with ");
strcat (s, object2);
strcat (s, "?");

翻訳者にセンテンス全体を表示するためという理由だけではなく、object1とobject2の順番が入れ替わるような言語もあるので、これは以下のような書式文字列を使用するように変更する必要があります:

sprintf (s, "Replace %s with %s?", object1, object2);

似たようなケースとして、コンパイル時の文字列結合があります。ISO C 99のインクルードファイルである<inttypes.h>には、printfで整数型‘int64_t’を出力するためのPRId64マクロが含まれています。このマクロは通常、プラットフォームに応じて "d"、"ld"、"lld" のような文字列定数に展開されます。以下のようなコードがあるとします。

printf ("The amount is %0" PRId64 "\n", number);

gettextツールとライブラリーには、これら<inttypes.h>のマクロにたいする特別なサポートがあるので、上記のような場合は単に以下のように書くことができます。

printf (gettext ("The amount is %0" PRId64 "\n"), number);

この場合、POファイルには"The amount is %0<PRId64>\n"という文字列が含まれます。翻訳者は同様に"%0<PRId64>"と翻訳すれば、実行時にgettext関数が、"d"、"ld"、"lld" などから適切な文字列定数に変換します。

これは事前に定義された<inttypes.h>マクロにたいしてのみ機能します。あなたが‘MYPRId64’のような似たようなマクロを定義した場合、xgettextはそれを知ることができないので、コードを以下のように変更してください:

char buf1[100];
sprintf (buf1, "%0" MYPRId64, number);
printf (gettext ("The amount is %s\n"), buf1);

これでプラットフォームに依存するコードと、インターナショナリゼーションのコードは、別のステートメントに分けられました。バッファーの長さは100バイト以内でよいことに注意してください。なぜなら利用可能なすべてのハードウェアーの整数型は128ビットに制限されており、128ビット整数を出力するには、10進、8進、16進に関わらず最大で54バイトあればよいからです。

これは他のプログラム言語には適用できます。JavaとC#では文字列結合は、それらのコンパイラーのビルトイン操作なのでとても頻繁に使用されます。以下のようなCやJavaのコードがあるとします

System.out.println("Replace "+object1+" with "+object2+"?");

これを以下のような書式師弟文字列を含むステートメントに変更します:

System.out.println(
    MessageFormat.format("Replace {0} with {1}?",
                         new Object[] { object1, object2 }));

C#の場合は以下のように変更します

Console.WriteLine("Replace "+object1+" with "+object2+"?");

これを以下のような書式師弟文字列を含むステートメントに変更します:

Console.WriteLine(
    String.Format("Replace {0} with {1}?", object1, object2));

通常使用しないようなマークアップや制御文字は、翻訳可能な文字列の中に含めるべきではありません。翻訳者はマークアップや制御文字がもつ特別な意味は理解しません。

たとえば‘|’の右側と左側とで何らかのGUI要素を分ける規則があるような場合、翻訳者は特別なコメントなしではその規則を理解することはできません。このような場合は、翻訳者が右側と左側の文字列を個別に翻訳できるようにするのがよいでしょう。

他の例としては、‘argp’で制御文字‘\v’(vertical tab)を使用する場合の規則です。これは1つの文字列を2つのセクションに分ける場合に使用されます。このような文字列をそのまま翻訳可能文字列とするには問題があります。翻訳者によっては、これを単純に改行や空行に置き換えてしまうかもしれません。POファイルエディターの中には、制御文字のvertical tabを入力するのが困難なものもあります。上記の理由により、あなたは翻訳文字列の対応する位置に、‘\v’文字があることを期待できません。この問題にたいする解決策は、繰り返しになりますが、翻訳者が個別に文字列を翻訳できるようにしておいて、実行時に2つの翻訳された文字列を、規則が要求する‘\v’で結合することです。

HTMLマークアップは十分に一般的なマークアップなので、翻訳可能文字列を使用しても大丈夫でしょう。しかしGNU gettextツールは、翻訳された文字列がwell-formedなHTMLであるかは検証しないことに留意してください。

4.4 ソース内でマークはどのように見えるか

Cソース中で翻訳される文字列は、すべてマークする必要があります。マーキングは翻訳可能な文字列を、関数やプリプロセッサーのマクロに、単独の引数として引き渡す方法で行われます。翻訳のために利用可できる関数またはマクロは少なく、マーキングのキーワードとしてそれらの名前が使用されます。マーキングは翻訳される文字列自体に何かを行うよりは、文字列にアタッチすることによりマーキングを行なう方法が、より多く使用されます。明らかな例としては、書式文字列によりエラーメッセージを生成する場合です。書式文字列は翻訳する必要があり、フォーマット文字列の‘%s’で指定した箇所に挿入される文字列も同様だとすると、たとえばsprintfの結果には、‘error_string_out()’のようなルーチンからなる、多くの異なるインスタンスが含まれることになり、これらをすべてリストするのは非現実的です。

マーキングには2つの目的があります。1つ目は実行時に翻訳を取得するトリガーとなることです。キーワードは引数となる文字列にたいして、可能なかぎり(そして望む限り)、動的に適切なトランスレーションを返すルーチンへと解決されます。ローカライズ可能な文字列は、変数にあてがわれていたり、関数の引数になっている場合がほとんどです。しかし翻訳可能な文字列が構造体の初期化時に使用される等の例外もあります。翻訳可能文字列の特別なケースを参照してください。

2つ目の目的は、xgettextが、一連のプログラムソースをスキャンしてPOファイルのテンプレートを生成するときに、翻訳可能な文字列を適切に抽出する手助けをすることです。

翻訳可能な文字列をマークするための標準的なキーワードは‘gettext’で、これはGNU gettextパッケージの名前の由来にもなっています。パッケージで少量の‘gettext’キーワードやマクロ、関数をそのまま使うのは簡単です。しかしgettextインターフェースを多用するパッケージの場合、主要なキーワードには目立つ名前ではなく、より簡潔な名前を使用する方が便利です。キーワードはパッケージ内のすべての文字列の箇所に記述されますが、プログラマーは通常、彼らのプログラムのソースがインターナショナライズされるものだといつも強制的に思い出したいとは望みませんし、その必要もありません。また長いキーワードはより多くの文字数を使用するので、ソースの1行を79から80文字にインデントするための労力が余分にかかるという欠点もあります。

多くのパッケージはキーワードとして‘_’(単なるアンダーライン)を使用して、‘gettext ("Translatable string")’を、‘_("Translatable string")’のように記述しています。またGNU標準のコーディング規約は実際、この特定の用途のためにキーワードと開き括弧の間に、余白としてスペースを要求しています。これにより翻訳可能な文字列のためにかかる文字的なオーバーヘッドは、アンダーラインと2つの括弧というたった3文字に短縮されます。たとえGNU gettextがこの方式を内部的に使用していたとしても、これは公式な提案ではありません。正式なキーワードはあくまでも本物の‘gettext’です。しかし‘gettext’のかわりに‘_’を使用したい人は、以下のように定義すると簡単になります。

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

単に‘#include <libintl.h>’とするのではなく、上記のようにすれば簡単に使用できます。

マーキングのためのキーワードである‘gettext’と‘_’ は、翻訳可能文字列を単一の引数とします。他の位置に引数をするマーキング用の関数を定義することもできます。関数が呼び出されたときの引数の合計数にもとづいた位置のマーク用引数を作ることもできます(通常はC++の場合)。これはxgettextの‘--keyword’により実現されます。xgettextにこのような引数を渡すにはgettextizeが使用されます、その方法についてはpo/内のMakevarsとpo.m4内のAM_XGETTEXT_OPTIONで説明します。

長い文字列は複数行に分けられることに注意してください。コンパイル時にはISO CおよびISO C++にもとづく文字列の自動連結が行われますが、xgettextもこの構文をサポートしています。

後でメンテナンスするのも簡単になります。もしあなたがプログラマーで、文字列を追加、変更した場合、その文字列が翻訳される必要があると考えた場合は、‘_()’でマークすればよいのです。たとえば‘"%s"’は、翻訳しない文字列だとします。しかし‘"%s: %d"’は翻訳するような場合です(Frenchの場合は通常、Englishとは異なり、コロンの前にスペースを挿入する翻訳が必要になります)。

4.5 翻訳可能文字列のマーク

POモードには、翻訳者向けというよりはプログラマー向けの一連の機能があります。それらの機能により彼は、プログラムのソース中の文字列が、翻訳可能かどうか、対話的にマークすることができます。彼が選んだ他のエディターでも、それらの文字列を探してマークするのは、プログラマーにとって簡単な作業かもしれませんが、POモードはこれらの作業をより快適にしてくれます。またPOモードは、プログラマーの素養を持つ翻訳者、または翻訳者の素養を持つプログラマーにたいして、プログラムのソース中の翻訳可能な文字列をマークするツールを与えてくれると同時に、インターナショナライズされるパッケージにたいする翻訳を生成するツールを与えてくれるのです。

以下で説明するPOモードのコマンドが対象とするプログラムのソースは、POファイルのコマンドを使う前に、プロジェクト用のEmacs tagsテーブルを生成する必要があります。これは簡単です。任意のシェルウィンドウでプロジェクトのルートディレクトリに移動して、以下のようなコマンドを実行してください:

etags src/*.[hc] lib/*.[hc]

ここではsrc/、およびlib/ディレクトリーにあるすべての.hと.cファイルを処理したいとします。このコマンドは指定されたすべてのファイルを検索して、プロジェクトのルートディレクトリーにTAGSという、Emacsが解釈できる要約された形式のファイルを作成します。

GNUコーディング規約に従うパッケージには、すべてのディレクトリーとソースコードを含んだすべてのファイルにたいして、tags、またはTAGSファイルを作成するという目標があります。

1度TAGSを準備すれば、以下のコマンドが彼のソース中の翻訳可能な文字列をマークする手助けをしてくれます。これらのコマンドはPOファイルのウィンドウから実行される必要がありますが、POファイルはまだ作成されていません。しかし新しいウィンドウで空のPOファイルを新規に作成して、そこからコマンドを実行すれば問題ありません。この空のPOファイルの内容は、プログラムのソース中の文字列を翻訳可能にマークするにつれて、徐々に増えていきます。

,

翻訳候補となりそうな文字列をプログラムのソースから検索します(po-tags-search)。

M-,

検索された最後の文字列を‘_()’でマークします(po-mark-translatable)。

M-.

検索された最後の文字列を、利用可能なキーワードによりマークします。プレフィックスと一緒にこのコマンドを使うことにより、キーワードを管理することができます(po-select-mark-and-mark)。

, (po-tags-search)コマンドは、翻訳候補と思われるような次の文字列を検索して、プログラムのソースをEmacsの他のウィンドウで表示します(その文字列がウィンドウの上部にくるように表示されます)。文字列が長くてウィンドウに収まらないような場合は、文字列の最後の部分が表示されます。カーソルは常にPOファイルのウィンドウにあります。その文字列が他の言語に翻訳されたほうがよいと判断したら、M-,、またはM-.により文字列をマークします。翻訳する必要がないと判断した場合は、単に,コマンドで次の文字列を検索してください。

3つ以上の文字の並びは、翻訳候補となります。1行の文字の並びが最大で2つでも、文字の数が非文字より多い場合は、翻訳候補と判断します。文字を含まない文字列、または 孤立した文字だけの文字列は無視されます。コメント文字列、およびPOモードが把握しているキーワード(以下を参照してください)ですでにマークされている文字列も無視されます。

EmacsにたいしてTAGSを指定していない場合、最初にこのコマンドを使うときにミニバッファー(minibuffer)に入力を求められます。TAGSファイルは、Emacsの標準コマンドであるM-x visit-tags-tableを入力して、正しいTAGSファイルを入力することにより、後から変更することができます。Tag Tables in The Emacs Editorを参照してください。

,コマンドは毎回、前回に検索した箇所から検索を再開し、TAGSに従ってすべてのプログラムソースを処理するまで検索します。コマンド(C-u ,)にプレフィクス引数( prefix argument)を与えることにより、プログラムのソースの先頭から検索を再開させることができます。この場合、前回マークした翻訳可能な文字列は自動的にスキップされます。

,コマンドを使用することにより、Emacsの標準コマンドが使用できなくなることはありません。たとえば、標準のtags-search、およびtags-query-replaceコマンドは、,のサーチ順序とは独立して、中断されることなく使用できます。しかし、最初の,コマンド(またはコマンド引数をともなう,コマンド)は、Emacsの標準的なtags検索を最初のtagsにリセットしてしまうよう実装されているので、この再初期化は除きます。

M-, (po-mark-translatable)コマンドは、前回検索された文字列を、キーワード‘_’でマークします。M-. (po-select-mark-and-mark)コマンドは、ミニバッファーでキーワードの入力を求めて、文字列をマークするのにそのキーワードを使用します。どちらのコマンドも、マークした文字列に対応する新しい未翻訳のエントリーをPOファイルに作成して、そのエントリーをカレントのエントリーとします(そのエントリーをすぐに翻訳するのが簡単になります)。M-,やM-.によるプログラムソースの変更により、ソース1行の文字数が80文字を超えてしまうような場合もありますが、これにたいする再インデントなどは別の作業になります。プログラムソースのウィンドウから、Emacsの別のウィンドウに移ったりするために、POモードからOコマンドを使う場合もあるでしょう。,コマンドに次の文字列を告げるような場合、POファイルのウィンドウにカーソルを戻すには、なんらかのEmacsの標準コマンドを使う必要があります。

M-.には、キーワードをいちいち全部入力しなくてもよいような、スピードアップのための機能がいくつかあります。1つ目は、プロンプトで単にRETを押すだけで、好ましいキーワードが表示されるというスピードアップ機能です。2つ目は、入力したいキーワードにたいして、そのキーワードの先頭部分を一意に特定できる分だけ入力すれば、コマンドが残りの部分を補完してくれるスピードアップ機能です。これはPOモードが利用可能なキーワードを知っていて、ミスタイプによる誤ったキーワードは受け付けられないことを意味します。

キーワードの入力を求められたときに?を入力すると、コマンドは既知のキーワードのリストを表示し、そこから選択して入力することができます。(C-u M-.)によりコマンドが引数が指定された場合、単純なキーワード管理以外による、プログラムのソースとPOファイルのバッファーの更新が禁じられます。この場合、コマンドはキーワードの完全な入力を求め、そのキーワードは以降のM-.コマンドで使用されます。さらに、この新しいキーワードは自動的に、以降のコマンド用のお好みのキーワードに追加されます。C-u M-.にたいして既知のキーワードを答えた場合、単にお勧めのキーワードが1つ変更されるだけで、他には何もしません。

M-.により認識されるすべてのキーワードは、,コマンドによる文字列検索時に再編成されます。この時、これらのキーワードですでにマークされている文字列は自動的にスキップされます。同時に複数のPOファイルを開いている場合、それぞれが個別に既知のキーワードを保有します。現在のところPOモードにキーワードを削除するための機能はないので、(qを使用するなどして)ファイルを一旦閉じてから、再度開く必要があります。Emacs のウィンドウにPOファイルを新規に開いたときは、‘gettext’と‘_’だけがキーワードで、M-.コマンドのお好みのキーワードは‘gettext’になっています。実際のところ、‘_’はビルトインのM-,コマンドに割り当てられているので、お勧めにするには便利ではありません。

4.6 キーワードの前の特別なコメント

Cプログラム中の文字列は、しばしばprintfファミリーと呼ばれる関数呼び出しで使用されます。これらで使用される書式指定文字列に関して特筆すべきは、%で始まる書式指定子が含まれていることです。以下のようなコードがあるとしましょう。

printf (gettext ("String `%s' has %d characters\n"), s, strlen (s));

上記の文字列にたいして、以下のようなGermanの翻訳が考えられます:

"%d Zeichen lang ist die Zeichenkette `%s'"

Germanを話せないCプログラマーでも、まずい点があることに気がつくでしょう。文字列中の書式指定子の順序が変更されていますが、printfの引数の順序は変更されません。一番問題なのは、文字列のアドレスが期待されている箇所に、文字列の長さが渡していることです。

翻訳に起因する実行時のエラーを防ぐために、msgfmtは翻訳前の文字列と、翻訳後の文字列に含まれる引数のタイプと数を、静的にチェックすることができます。このチェックを満足しないような場合、msgfmtに‘-c’が指定されていると、msgfmtはエラーを発生させてMOファイルを生成しません。したがって、一貫性を保って‘msgfmt -c’を使用することにより、エラーを事前に検出して、実行時の問題を防ぐことができます。

Germanの翻訳で上述の単語順が正しい場合は、以下のように記述する必要があります

"%2$d Zeichen lang ist die Zeichenkette `%1$s'"

msgfmtルーチンは、この特別な表記法を認識できます。

プログラムのすべての文字列が書式文字列というわけではないので、.poファイルの中のすべての文字列をmsgfmtがテストする必要はありません。また文字列の中に書式指定子と似た文字列が含まれるが、その文字列がprintfで使われる文字列ではないような場合は、問題が発生します。

そのためxgettextは、それらの書式文字列と思われるメッセージに特別なタグを付与します。このタグ付けは絶対的なルールではなく、発見的なルールです。.poファイルの中のそれらのエントリーには、#,によるコメント行で、c-formatというフラグによりマークされます(POファイルのフォーマットを参照してください)。

注意深い読者は、まだ問題があると気づくでしょう。発見されたものが間違っている場合です。これは真実であり、そのためにxgettextは、プログラマーが意志決定すべき特別な種類のコメントを認識することができるのです。gettextキーワードと同じ行、またはそれに続く行にxgettext:c-formatという単語を含むコメントを発見すると、xgettextはどのような場合であれ、文字列をc-formatフラグでマークします。この種のコメントは、xgettextが文字列を書式文字列と認識しない場合(テストしてみて実際に認識されない場合)に使う必要があります。gettextキーワードと同じ行にコメントがある場合、翻訳される前にコメントを挿入しなければならないことに注意してください。

このような状況は頻繁に発生します。printf関数にわたされる文字列に書式指定子が含まれない場合もあります。そのようなケースでは通常、fputsを使用するのでしょうが、それでもこのような状況はあり得ます。このような場合、xgettextはそれを書式文字列として認識しませんが、翻訳に書式指定子として認識されるような文字列が含まれていると何が起こるでしょうか? printf関数はパラメーターにアクセスしようとしますが、翻訳前の文字列には何も引数がわたされないため、パラメーターは存在しません。

もちろん他の原因により、xgettextが間違って書式文字列ではない文字列を、書式文字列と認識することがあります。このような場合、msgfmtは多くの警告を出力し、.poファイルへの変換は失敗します。このように間違って書式文字列と認識されるのを防ぐには、上記と同様にxgettext:no-c-formatという文字列を含むコメントを使用します。

文字列がc-formatと間違ってマークされている場合、ユーザーは何が原因なのか調べることができます。--debugオプション使用して、どのように問題を解決するかについては、xgettextプログラムの呼び出しを参照してください。

4.7 翻訳可能文字列の特別なケース

注意深い読者なら、常に翻訳可能な文字列をgettext(または同様のもの)でマークすることはできないことに気づくでしょう。たとえば以下のようなケースです:

{
  static const char *messages[] = {
    "some very meaningful message",
    "and another one"
  };
  const char *string;
  …
  string
    = index > 1 ? "a default message" : messages[index];

  fputs (string);
  …
}

文字列"a default message"にたいするマーク付けは問題ありませんが、配列messagesを初期化する文字列はマークできません。どうすればよいのでしょうか? このような場合は2つのタスクを達成する必要があります。最初にxgettextプログラムが文字列を見つけ出せるように文字列をマークします(xgettextプログラムの呼び出しを参照してください)。次に実行時に文字列を出力する前に、文字列を翻訳するのです。

最初のタスクは、no-opという新しいキーワードを作ることにより達成できます。2番目のタスクは、配列の文字列にたいするすべてのアクセスポイントをマークします。考えられる解決策の1つは、以下のようなものです:

#define gettext_noop(String) String

{
  static const char *messages[] = {
    gettext_noop ("some very meaningful message"),
    gettext_noop ("and another one")
  };
  const char *string;
  …
  string
    = index > 1 ? gettext ("a default message") : gettext (messages[index]);

  fputs (string);
  …
}

どのようなケースでも、fputsに記述された文字列は翻訳されると思ってください。どのようにしてxgettextが、追加のキーワードgettext_noopを認識するかについては、xgettextプログラムの呼び出しを参照してください。

もちろん、これが唯一の解決策という訳ではありません。以下の方法のうちのいずれかを使用することもできます:

#define gettext_noop(String) String

{
  static const char *messages[] = {
    gettext_noop ("some very meaningful message"),
    gettext_noop ("and another one")
  };
  const char *string;
  …
  string
    = index > 1 ? gettext_noop ("a default message") : messages[index];

  fputs (gettext (string));
  …
}

しかしこの方法には欠点があります。プログラマーは文字列"a default message"にもgettext_noopを使うよう留意する必要があります。gettextを使用することにより、予期しない結果となる場合もあります。

利点の1つは、どのようなケースでも出力が翻訳されるようにするために、制御フローを分析する必要がないことです。この分析は一般的に難しいものではありませんが、これにあてはまらないような状況では、2番目の方法を使用することもできます。

4.8 翻訳バグの報告をユーザーに奨励する

コードにはバグが付き物ですが、翻訳も同様です。ユーザーがそれらのバグを報告できるようにする必要があります。メンテナーが同時に翻訳者であるような場合を除き、メンテナーが翻訳を変更することはないため、プログラマーやパッケージのメンテナーに翻訳のバグを報告するのは得策ではありません。したがって翻訳のバグは翻訳者に報告されなければなりません。

ここで紹介する方法で組織化することにより、メンテナーが翻訳のバグ報告をどこかへ転送したり、翻訳者や翻訳チームのアドレスのリストを維持する必要もなくなります。

すべてのプログラムには、バグを報告するためのアドレスを示す場所があります。GNUプログラムの場合、“–help”オプションにより表示される、“usage”(使用方法)とよばれる機能が該当する場所です。この場所に翻訳のバグ報告のためのアドレスを追加するよう、翻訳者に示すのです。たとえば以下のようなコードがあるとします

printf (_("Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);

以下のように、翻訳者への指示を追加することができます：

/* TRANSLATORS: The placeholder indicates the bug-reporting address
   for this package.  Please add _another line_ saying
   "Report translation bugs to <...>\n" with the address for translation
   bugs (typically your translation team's web or email address).  */
printf (_("Report bugs to <%s>.\n"), PACKAGE_BUGREPORT);

これらは‘xgettext’により抽出され、以下のようなエントリーを含む.potファイルとなります:

#. TRANSLATORS: The placeholder indicates the bug-reporting address
#. for this package.  Please add _another line_ saying
#. "Report translation bugs to <...>\n" with the address for translation
#. bugs (typically your translation team's web or email address).
#: src/hello.c:178
#, c-format
msgid "Report bugs to <%s>.\n"
msgstr ""

4.9 翻訳にたいして正確な名前をマークする

人や都市、場所の名前などは翻訳用にマークする必要があるでしょうか? Latin文字で記述する言語(English、Spanish、French、German等)しか知らない人は、“no”と言いたいでしょう。なぜなら通常は、それらの言語間で名前は変更されないからです。しかし一般的には、ある文字体系から他の文字体系に変換するときには、音声表記や音訳により名前も変換されます。たとえばRussianやGreekの名前は、Englishに変換されるときにLatinのアルファベットに変換され、EnglishやFrenchがJapaneseに変換されるときはKatakana文字に変換されます。対象となる言語を話す人たちは、一般的には翻訳前の文字で記述された元の名前を読めないので、これらの変換が必要になります。

それゆえプログラマーとしては、名前を翻訳用にマークするとともに、翻訳者にたいしてそれが元の正確な名前であることと、どのように取り扱うかについての特別なコメントを付与する必要があります。以下は簡単な例です:

printf (_("Written by %s.\n"),
        /* TRANSLATORS: This is a proper name.  See the gettext
           manual, section Names.  Note this is actually a non-ASCII
           name: The first name is (with Unicode escapes)
           "Fran\u00e7ois" or (with HTML entities) "François".
           Pronunciation is like "fraa-swa pee-nar".  */
        _("Francois Pinard"));

GNU gnulibは、オリジナル名にカッコ内に翻訳された名前を自動的に追加する‘propername’　(http://www.gnu.org/software/gnulib/MODULES.html#module=propername)というモジュールを提供しています。これによりスクリプトを変更しなくてもよいような場合には、翻訳者がASCIIで記述できないような名前にたいして、適切な非ASCII文字を入力するというタスクから開放されます。この、より快適な形式は以下のようなものです:

printf (_("Written by %s and %s.\n"),
        proper_name ("Ulrich Drepper"),
        /* TRANSLATORS: This is a proper name.  See the gettext
           manual, section Names.  Note this is actually a non-ASCII
           name: The first name is (with Unicode escapes)
           "Fran\u00e7ois" or (with HTML entities) "François".
           Pronunciation is like "fraa-swa pee-nar".  */
        proper_name_utf8 ("Francois Pinard", "Fran\303\247ois Pinard"));

元の名前を、(UnicodeエスケープやHTMLエンティティーとしてではなく)直接Unicodeで記述して、IPA(International Phonetic Alphabet: 国際音標文字。http://www.wikipedia.org/wiki/International_Phonetic_Alphabet)を参照してください)により発音を示すこともできます。

翻訳者としては、名前を翻訳するときは注意深く行う必要があります。なぜなら名前がバラバラに翻訳されたり、間違って翻訳されることは、人を不快にさせるからです。

あなたの言語がLatin文字を使用している場合、必要なのはその言語で普段使用している文字で名前を再構築することだけです。これはc-cedilla文字を含む翻訳を提供するような場合です。あなたの言語がLatin文字とは異なる文字を使用していて、人がそれを通常Latin文字として読まれるようには話していない場合、それは翻訳を意味しています。プログラマーが簡単な方法を使用している場合でも、Latin文字を読む人のために、括弧付きで元の名前を記述する必要があります。プログラマーが上述の‘propername’モジュールを使用している場合は、元の名前を括弧付きで記述するのはプログラムが行うので、あなたが記述する必要はありません。以下は対象言語がGreekの場合の例です:

#. This is a proper name.  See the gettext
#. manual, section Names.  Note this is actually a non-ASCII
#. name: The first name is (with Unicode escapes)
#. "Fran\u00e7ois" or (with HTML entities) "François".
#. Pronunciation is like "fraa-swa pee-nar".
msgid "Francois Pinard"
msgstr "\phi\rho\alpha\sigma\omicron\alpha \pi\iota\nu\alpha\rho"
       " (Francois Pinard)"

このように名前の翻訳は微妙な領域に属する話題なので、翻訳を提出する前にテストすることをお勧めします。

4.10 ライブラリーソースの準備

あなたがプログラムではなくライブラリーを作成する場合、gettextの使用方法にはわずかな違いしかありません。ここでは前提として、ライブラリーが自分自身の翻訳ドメインとPOTファイルを持つとします(ライブラリーがメインプログラムの翻訳ドメインとPOTファイルを使用する場合は、前のセクションを変更なしに適用できます)。

1. ライブラリーのコードでは、setlocale (LC_ALL, "")を呼び出しません。localeのセットはメインプログラムの責任です。ライブラリーのドキュメントにはこの事実を明記して、ライブラリーを使用するプログラム開発者が認識できるようにする必要があります。
2. ライブラリーのコードでは、textdomain (PACKAGE)を呼び出しません。text domainのセットはメインプログラムの責任です。
3. プログラムのための初期化は以下のようなコードでした

     setlocale (LC_ALL, "");
     bindtextdomain (PACKAGE, LOCALEDIR);
     textdomain (PACKAGE);
   

   ライブラリーの場合は以下のコードだけになります

     bindtextdomain (PACKAGE, LOCALEDIR);
   

   ライブラリーのAPIにまだ初期化の関数が無いなら、bindtextdomain呼び出しを含む初期化関数を作成する必要があります。しかし通常、この初期化関数をエクスポートしたりドキュメント化する必要はありません。初期化関数がまだ呼び出されていない場合は、ライブラリーのすべてのエントリーポイントとなる関数から初期化関数を呼び出すだけで十分です。これを満足するような典型的な例は、初期化関数が呼び出し済みかどうかを保持するブール値の静的な変数を使用する方法です:

   static bool libfoo_initialized;
   
   static void
   libfoo_initialize (void)
   {
     bindtextdomain (PACKAGE, LOCALEDIR);
     libfoo_initialized = true;
   }
   
   /* This function is part of the exported API.  */
   struct foo *
   create_foo (...)
   {
     /* Must ensure the initialization is performed.  */
     if (!libfoo_initialized)
       libfoo_initialize ();
     ...
   }
   
   /* This function is part of the exported API.  The argument must be
      non-NULL and have been created through create_foo().  */
   int
   foo_refcount (struct foo *argument)
   {
     /* No need to invoke the initialization function here, because
        create_foo() must already have been called before.  */
     ...
   }
   

4. プログラムでは通常、各ソースファイル中で、以下のように‘_’マクロを定義しました

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

   自身の翻訳ドメインを持つライブラリーの場合は、以下のようになります:

   #include <libintl.h>
   #define _(String) dgettext (PACKAGE, String)
   

   別の言い方をすると、gettextのかわりにdgettextを使用するということです。同様に、ngettextが使用される箇所には、dngettextを使用する必要があります。

5 POテンプレートファイルのマーク

ソースの準備ができたら、プログラマーはPOテンプレートファイルを作成します。このセクションでは、その目的のためにxgettextをどのように使用するかについて説明します。

xgettextは、domainname.poという名前のファイルを作成します。あなたはそれをdomainname.potという名前にリネームする必要があります(xgettextは、どうして直接domainname.potを作成しないのでしょうか? これは歴史的な理由からです。xgettextが設計されたときはPOファイルとPOテンプレートファイルの区別があいまいで、拡張子の‘.pot’も使用されていなかったからです)。

5.1 xgettextプログラムの呼び出し

xgettext [option] [inputfile] …

xgettextプログラムは、与えられた入力ファイルから、翻訳可能な文字列を抽出します。

5.1.1 入力ファイルの位置

‘inputfile …’

入力ファイルを指定します。

‘-f file’

‘--files-from=file’

入力ファイルの名前を、コマンドラインからではなく、fileから読み込みます。

‘-D directory’

‘--directory=directory’

ディレクトリーのリストにdirectoryを追加します。このディレクトリーのリストからソースファイルを検索します。しかし.poファイルが出力されるのは、カレントディレクトリーです。

inputfileに‘-’が指定された場合は、標準入力から読み込みます。

5.1.2 出力ファイルの位置

‘-d name’

‘--default-domain=name’

出力ファイルとして、(messages.poのかわりに)name.poを使用します。

‘-o file’

‘--output=file’

(name.poやmessages.poではなく)指定されたファイルに出力を書き込みます。

‘-p dir’

‘--output-dir=dir’

ファイルはdirに出力されます。

出力のfileに‘-’または‘/dev/stdout’が指定された場合、出力は標準出力に書き込まれます。

5.1.3 入力ファイルの言語の選択

‘-L name’

‘--language=name’

Specifies the language of the input files. The supported languages are C、C++、ObjectiveC、PO、Shell、Python、Lisp、EmacsLisp、librep、Scheme、Smalltalk、Java、JavaProperties、C#、awk、YCP、Tcl、Perl、PHP、GCC-source、NXStringTable、RST、Glade、Lua、JavaScript、Vala、GSettings、Desktop.

‘-C’

‘--c++’

--language=C++の省略指定です。

デフォルトでは、入力ファイルの言語は拡張子により推測されます。

5.1.4 入力ファイルの解釈

‘--from-code=name’

入力ファイルのエンコーディングを指定します。このオプションはメッセージ文字列や、それらのコメントに非ASCII文字が含まれている場合のみ必要です。TclとGladeの入力ファイルは、このオプションの指定に関わらず、UTF-8が想定されることに注意してください。

デフォルトでは、入力ファイルのエンコーディングはASCIIであると仮定されます。

5.1.5 オペレーションモード

‘-j’

‘--join-existing’

既存のファイルのメッセージを結合します。

‘-x file’

‘--exclude-file=file’

fileのエントリーは抽出されません。fileには、POファイルかPOTファイルを指定します。

‘-c[tag]’

‘--add-comments[=tag]’

tagで始まるコメントブロックを、出力ファイル中のキーワード行の前に配置します。このオプションでtagを指定しない場合には、出力ファイル中のすべてのキーワード行の前にコメントブロックが配置されます。

コメントブロックと想定されるブロックが抽出されるために、ブロックはキーワード行により調整されなければならないことに注意してください。 たとえば以下のCソースコードでは:

/* This is the first comment.  */
gettext ("foo");

/* This is the second comment: not extracted  */
gettext (
  "bar");

gettext (
  /* This is the third comment.  */
  "baz");

2番目のコメント行は抽出されないでしょう。なぜならコメント行とキーワードの間にブランク行が1つあるからです。

‘--check[=CHECK]’

msgidおよびmsgid_pluralにたいして構文チェックを行います。サポートされているチェックは:

‘ellipsis-unicode’

ASCIIの...より、Unicodeのellipsis文字を優先します。

‘space-ellipsis’

ellipsis文字の前の空白文字を抑制します。

‘quote-unicode’

ASCIIの"'`より、Unicodeのクォーテーションマークを優先します。

‘bullet-unicode’

ASCIIの*または-より、Unicodeのbullet文字を優先します。

オプションはすべての入力ファイルに効果をもちます。特定の文字列にたいするチェックを有効、または無効にするために、ソースファイル中で特別なコメントxgettext:でマークすることができます。たとえば、--check=space-ellipsisを指定して、なおかつ特定の文字列にたいしてチェックを行いたくない場合には、以下のコメントを追加します:

/* xgettext: no-space-ellipsis-check */
gettext ("We really want a space before ellipsis here ...");

xgettext:コメントの後に、カンマで区切られたフラグを記述できます。利用可能なフラグは、‘[no-]name-check’という形式で、nameは有効な構文チェックです。フラグのプレフィクスがno-の場合は、否定を意味します。

文字列全体ではなく、msgid内の各センテンスへのチェックに適用されるテストがいくつかあります。xgettextはパターンマッチを行うことによりセンテンスの終わりを検出し、通常は特定の個数のスペースを後にともなうピリオドを探します。この数は--sentence-endオプションで指定されます。

‘--sentence-end[=TYPE]’

サポートされる値は:

‘single-space’

ピリオドの後に少なくとも1つの空白文字を要求します。

‘double-space’

ピリオドの後に少なくとも2つの空白文字を要求します。

5.1.6 言語特有のオプション

‘-a’

‘--extract-all’

すべての文字列を抽出します。

このオプションはほとんどの言語、すなわち、C、C++、Objective-C、Shell、Python、Lisp、EmacsLisp、librep、Java、C#、awk、Tcl、Perl、PHP、GCC-source、Glade、Lua、JavaScript、Vala、GSettingsに影響を与えます。

‘-k[keywordspec]’

‘--keyword[=keywordspec]’

検索する追加のキーワードをkeywordspecに指定します。keywordspecを指定しない場合には、デフォルトのキーワードを使用しないことを意味します。

keywordspecとして指定されたidがCのものだった場合、xgettextは関数(またはマクロ)idの各呼び出しの最初の引数から文字列を検索します。keywordspecが‘id:argnum’という形式で指定された場合、xgettextは呼び出しのargnum番目の引数を探します。keywordspecが‘id:argnum1,argnum2’の形式で指定された場合、xgettextは呼び出しのargnum1番目とargnum2番目の引数から文字列を探して、複数形として処理すべきメッセージのsingular(単数形)とplural(複数形)として扱います。同様に、keywordspecが‘id:contextargnumc,argnum’や‘id:argnum,contextargnumc’という形式で指定された場合、xgettextはcontextargnum番目の引数の文字列をコンテキスト指定子(context specifier)として扱います。そして GNOME のための特別なサポートとして、keywordspecが‘id:argnumg’という形式で指定された場合、xgettextはargnum番目の引数がcontextを伴う文字列と認識して、GNOME glibの‘"msgctxt|msgid"’という構文を使用します。そしてGNOMEのための特別なサポートとして、keywordspecが‘id:argnumg’という形式で指定された場合、xgettextはargnum番目の引数がcontextを伴う文字列と認識して、GNOME glibの‘"msgctxt|msgid"’という構文を使用します。
またkeywordspecが‘id:…,totalnumargst’という形式で指定された場合、xgettextは実際の引数の数がtotalnumargsと等しい場合のみ、この引数指定を処理します。これはC++でのオーバーロードされた関数の呼び出しなどで便利です。
最後に、もしkeywordspecが‘id:argnum...,"xcomment"’という形式で指定された場合、xgettextは指定された引数から文字列を抽出するときに、追加のコメントとしてxcommentをメッセージに追加します。通常のシェルのコマンドラインから使用する場合は、xcommentを括るダブルクォーテーションはエスケープする必要があることに注意してください。

このオプションはほとんどの言語、すなわち、C、C++、Objective-C、Shell、Python、Lisp、EmacsLisp、librep、Java、C#、awk、Tcl、Perl、PHP、GCC-source、Glade、Lua、JavaScript、Vala、GSettings、Desktopに影響を与えます。

明示的に無効化されていない限り、常に検索されるデフォルトキーワードの指定は、言語に依存します:

• C、C++、GCC-sourceの場合: gettext、dgettext:2、dcgettext:2、ngettext:1,2、dngettext:2,3、dcngettext:2,3、gettext_noop、そしてpgettext:1c,2、dpgettext:2c,3、dcpgettext:2c,3、npgettext:1c,2,3、dnpgettext:2c,3,4、dcnpgettext:2c,3,4。
• Objective C: Cと同様です。NSLocalizedString、_、NSLocalizedStaticString、__も該当します。
• shellスクリプトの場合: gettext、ngettext:1,2、eval_gettext、eval_ngettext:1,2。
• Pythonの場合: gettext、ugettext、dgettext:2、ngettext:1,2、ungettext:1,2、dngettext:2,3、_。
• Lispの場合: gettext、ngettext:1,2、gettext-noop。
• EmacsLispの場合: _。
• librepの場合: _。
• Schemeの場合: gettext、ngettext:1,2、gettext-noop。
• Javaの場合: GettextResource.gettext:2、GettextResource.ngettext:2,3、GettextResource.pgettext:2c,3、GettextResource.npgettext:2c,3,4、gettext、ngettext:1,2、pgettext:1c,2、npgettext:1c,2,3、getString。
• C#の場合: GetString、GetPluralString:1,2、GetParticularString:1c,2、GetParticularPluralString:1c,2,3。
• awkの場合: dcgettext、dcngettext:1,2。
• Tclの場合: ::msgcat::mc。
• Perlの場合: gettext、%gettext、$gettext、dgettext:2、dcgettext:2、ngettext:1,2、dngettext:2,3、dcngettext:2,3、gettext_noop。
• PHPの場合: _、gettext、dgettext:2、dcgettext:2、ngettext:1,2、dngettext:2,3、dcngettext:2,3。
• Glade 1の場合: label、title、text、format、copyright、comments、preview_text、tooltip。
• Luaの場合: _、gettext.gettext、gettext.dgettext:2、gettext.dcgettext:2、gettext.ngettext:1,2、gettext.dngettext:2,3、gettext.dcngettext:2,3。
• JavaScriptの場合: _、gettext、dgettext:2、dcgettext:2、ngettext:1,2、dngettext:2,3、pgettext:1c,2、dpgettext:2c,3。
• Valaの場合: _、Q_、N_、NC_、dgettext:2、dcgettext:2、ngettext:1,2、dngettext:2,3、dpgettext:2c,3、dpgettext2:2c,3。
• デスクトップの場合: Name、GenericName、Comment、Icon、Keywords。

デフォルトキーワードの指定は、‘-k’オプション、‘--keyword’を指定するか、keywordspecを指定せずに‘--keyword=’として無効にすることができます。

‘--flag=word:arg:flag’

関数wordの、arg番目の引数の一部となるような文字列のための、追加のフラグを指定します。‘c-format’や、それの反対の‘no-c-format’のような、利用可能な書式文字列を示すフラグを利用でき、‘pass-’を前置して指定することもできます。
--flag=function:arg:lang-formatは、言語langの関数functionのarg番目の引数を書式文字列とみなすという意味です(GCC関数の属性に慣れている人は、--flag=function:arg:c-formatが、Cソース中の関数 functionに付記される‘__attribute__ ((__format__ (__printf__, arg, ...)))’宣言と同様だと思えばよいでしょう)。たとえばGNU libcから、関数‘error’を使用する場合、それの振る舞いについて--flag=error:3:c-formatのように指定することができます。この指定によりxgettextは、すべてのgettext呼び出しのfunctionのarg番目の引数に出現する文字列を、書式指定文字列としてマークします。これは書式指定子が含まれていないような文字列にたいして‘msgfmt -c’によりチェックを行う場合に便利です。これにより翻訳者が実行時のクラッシュを引き起こすような書式指定子を意図せずに使ってしまうことを防ぐことができます。
--flag=function:arg:pass-lang-formatは、言語langにおいて、書式文字列が出現しなければいけない位置にfunction呼び出しがある場合、その関数のarg番目の引数には、同じタイプの書式文字列となければならないという意味です。(GCC関数の属性を知っている人は、--flag=function:arg:pass-c-formatが、Cソース中の関数functionに付記される‘__attribute__ ((__format_arg__ (arg)))’宣言と同様だと思えばよいでしょう)。たとえばgettext関数の略記である‘_’を使用している場合は、--flag=_:1:pass-c-formatを使う必要があります。この指定によりxgettextは、_("string")呼び出しの最初の引数"string"には書式指定文字列が必要だと伝えるために、その文字列を書式指定文字列としてマークします。これは書式指定子が含まれていないような文字列にたいして‘msgfmt -c’によりチェックを行う場合に便利です。これにより翻訳者が実行時のクラッシュを引き起こすような書式指定子を意図せずに使ってしまうことを防ぐことができます。
このオプションは、C、C++、ObjectiveC、Shell、Python、Lisp、EmacsLisp、librep、Scheme、Java、C#、awk、YCP、Tcl、Perl、PHP、GCC-source、Lua、JavaScript、Vala(つまり、ほとんどの言語)に影響を与えます。

‘-T’

‘--trigraphs’

入力におけるANSI Cの三連表記(trigraph)を理解します。
このオプションは言語がC、C++、ObjectiveCの場合のみ効果があります。

‘--qt’

Qtの書式指定文字列を認識します。
このオプションは言語がC++の場合のみ効果があります。

‘--kde’

KDE 4の書式指定文字列を認識します。
このオプションは言語がC++の場合のみ効果があります。

‘--boost’

Boostの書式指定文字列を認識します。
このオプションは言語がC++の場合のみ効果があります。

‘--debug’

メッセージ中の書式指定文字列を、c-formatやpossible-c-formatフラグでマークすることにより、誰がマークしたかを表示します。後者の形式は、xgettextが決定したときに使用され、前者の書式はプログラマーが決定したときに使用されます。

デフォルトではc-format形式だけが使用されます。翻訳者はそれらの詳細について気にする必要はありません。

このxgettextの実装は、プリプロセッサーのマクロの中の文字列や、ANSIによる隣接した文字列の結合、エスケープ文字による行の継続等の厄介なケースを処理することができます。

5.1.7 出力の詳細

‘--color’

‘--color=when’

色や色以外のテキスト属性を使うか、いつ使うかを指定します。詳細は--colorオプションを参照してください。

‘--style=style_file’

--colorにたいしてCSS style ruleファイルを使うかを指定します。詳細は--styleオプションを参照してください。

‘--force-po’

何もメッセージが定義されていない場合でも、常に出力ファイルに書き込みます。

‘-i’

‘--indent’

インデントされた形式で.poファイルを書き込みます。

‘--no-location’

‘#: filename:line’のような行を書き込みません。このオプションを使用することにより、熟練した翻訳者が、どのようなコンテキストでメッセージが使用されるのかを理解するのが困難になることに注意してください。

‘-n’

‘--add-location=type’

‘#: filename:line’という行を生成します(デフォルト)。

typeはオプションで、‘full’、‘file’、または‘never’を指定できます。オプションが指定されない、または‘full’の場合は、ファイル名と行番号のの両方が生成されます。‘file’の場合、行番号は省略されます。‘never’の場合は、完全にこの行を抑制します(--no-locationと同じです)。

‘--strict’

Uniforumに厳密に準拠したPOファイルを出力します。このUniforum形式はGNUの拡張をサポートしないため避けたほうがよいでしょう。

‘--properties-output’

Javaの.propertiesの書式で、Java ResourceBundleを出力します。このファイル形式はplural formをサポートせず、廃止されたメッセージを暗黙で除去することに注意してください。

‘--stringtable-output’

.stringsの書式で、NeXTstep/GNUstepのローカライズされたリソースファイルを出力します。このファイル形式はplural formをサポートしないことに注意してください。

‘--its=file’

fileで定義されたITSルールを使用します。これはXMLファイルデだけ効果があることに注意してください。

‘--itstool’

itstool(http://itstool.org)で認識されるコメントを書き出します。これはXMLファイルデだけ効果があることに注意してください。

‘-w number’

‘--width=number’

出力ページの幅をセットします。これにより出力ファイル中の長い文字列が指定した幅(例:スクリーンの列数)に収まるように、各行の長さがnumber以下のような複数の行に分割されます。

‘--no-wrap’

長いメッセージ行を分割しません。出力ページの幅を超えるようなメッセージ行も、複数行に分割されません。出力ページの幅を超えるファイル参照行だけが分割されます。

‘-s’

‘--sort-output’

ソートされた出力を生成します。このオプションを使用することにより翻訳者が、メッセージがどのようなコンテキストで使用されるかを理解するのが、困難になることに注意してください。

‘-F’

‘--sort-by-file’

ファイルの場所により出力をソートします。

‘--omit-header’

‘msgid ""’というエントリーにたいして、ヘッダーを書き込みません。

これはソースファイルの変更をテストする等の目的で、.gmoファイルを生成するときに便利です。--omit-headerを使用すると、同じファイルにたいして、同じオプションでxgettextを実行すれば、実行した時が異なっていても同じ結果を得ることができます。

このオプションをASCII以外の文字が含まれたファイルにたいして使用した場合、エラーとなることに注意してください。

‘--copyright-holder=string’

出力に著作権所有者(copyright holder)をセットします。stringにはパッケージの著作権所有者を指定する必要があります(パッケージのソースから抽出されたmsgstr文字列の著作権は、パッケージの著作権所有者に帰属することに注意してください)。翻訳者は、翻訳物の著作権を譲渡、もしくは放棄することが望まれます。これによりパッケージのメンテナーは法的なリスクなしでそれらを配布できるのです。stringが空の場合、出力ファイルはパブリックドメインに属するとマークされます。この場合も翻訳者は著作権を譲渡、もしくは放棄することが望まれます。繰り返しになりますが、そうすることによりパッケージのメンテナーは法的なリスクなしでそれらを配布できるのです。

stringのデフォルト値はFree Software Foundation, Inc.です。これは単にxgettextが最初に使用されたのが GNU プロジェクトであることが理由です。

‘--foreign-user’

出力からFSFの著作権を省略します。これは‘--copyright-holder=''’とするのと同じです。これはGNUプロジェクト以外で、翻訳物をパブリックドメインにしたいときに便利です。

‘--package-name=package’

出力のヘッダーに、パッケージ名をセットします。

‘--package-version=version’

出力のヘッダーにパッケージのバージョンをセットします。このオプションは、同時に‘--package-name’を指定したときだけ効果があります。

‘--msgid-bugs-address=email@address’

msgidに関するバグの報告先アドレスをセットします。このアドレスは、翻訳者が未翻訳文字列のバグを報告するための電子メールのアドレス、またはURLです。

• - センテンス全体となっていないような文字列。メンテナーのためのガイドライン 翻訳可能な文字列の準備を参照してください。
• - 不明な用語を使用したり、追加のコンテキストを理解することが必要とする文字列 。
• - 日付・時刻・通貨の表記で、無効な仮定をしている文字列 。
• - plural化に関する問題。
• - 間違ったEnglishのスペル。
• - 間違った書式。

このアドレスは、あなたのメールアドレスでも構いませんし、翻訳者が登録しなくても投稿できるメーリングリストのアドレスや、翻訳者があなたに連絡をとることができるウェブページのアドレスにすることもできます。

デフォルトは空文字列が設定されており、これは翻訳者にはこれらの情報が分からないことを意味します! このオプションを指定するのを忘れないでください。

‘-m[string]’

‘--msgstr-prefix[=string]’

msgstrの値に前置する文字列としてstring(指定されていない場合は"")を使用します。

‘-M[string]’

‘--msgstr-suffix[=string]’

msgstrの値に後置する文字列としてstring(指定されていない場合は"")を使用します。

5.1.8 情報的な出力

‘-h’

‘--help’

このヘルプを表示して終了します。

‘-V’

‘--version’

バージョン情報を表示して終了します。

6 新しいPOファイルの作成

新しい翻訳を開始する場合、翻訳者はpackage.potの初期コメント(ファイルの先頭にあります)とヘッダーのエントリー(最初のエントリーで、これもファイルの先頭付近にあります)に変更を加えたものをコピーして、LANG.poを作成します。

これを行う一番簡単な方法は、‘msginit’を使うことです:

$ cd PACKAGE-VERSION
$ cd po
$ msginit

かわりにコピーしてから手で変更する方法もあります。この場合、翻訳者はpackage.potをLANG.poというファイル名でコピーしてから、ファイル内の初期コメントとヘッダーエントリーを修正します。

6.1 msginitプログラムの呼び出し

msginit [option]

msginitプログラムは、新しいPOファイルを作成して、メタ情報をユーザーの環境にもとづいて初期化します。

以下はその詳細です。POファイルの以下のヘッダーフィールドは、もし可能なら自動的に充填されます。

‘Project-Id-Version’

この値はconfigureスクリプト、またはカレントディレクトリー内の他のファイルから推測されます。

‘PO-Revision-Date’

値はPOTファイルのPO-Creation-Data、または現在の日時から取得されます。

‘Last-Translator’

値はユーザーのpasswordファイルとメール設定ファイルから取得されます。

‘Language-Team, Language’

これらの値は、カレントlocaleと、翻訳チームの事前に定義されたリストから取得されます。

‘MIME-Version, Content-Type, Content-Transfer-Encoding’

これらの値は、POTファイルの内容と、カレントlocaleからセットされます。POTファイルがcharset=UTF-8を含む場合、そのPOTファイルは非ASCII文字を含むことを意味するので、UTF-8エンコーディングを維持します。それ以外では、POTファイルがプレーンASCIIの場合は、そのlocaleのエンコーディングを使用します。

‘Plural-Forms’

値は最初に埋め込みテーブルから見つかったものです。

実験的な機能として、環境変数GETTEXTCLDRDIRをセットすることにより、msginitにUnicode CLDRの情報を使用するように指示できます。

6.1.1 入力ファイルの位置

‘-i inputfile’

‘--input=inputfile’

入力となるPOTファイルです。

inputfileが指定されなかった場合、カレントディレクトリからPOTファイルを検索します。‘-’を指定すると、標準入力から読み込みます。

6.1.2 出力ファイルの位置

‘-o file’

‘--output-file=file’

指定されたPOファイルに出力を書き込みます。

出力ファイルが指定されなかった場合は、ユーザーのロケール設定の‘--locale’オプションに依存します。‘-’を指定すると、出力は標準出力に書き込まれます。

6.1.3 入力ファイルの構文

‘-P’

‘--properties-input’

入力ファイルがPOファイルの構文ではなく、Javaの.propertiesの構文にのっとったJava ResourceBundleファイルだとみなします。

‘--stringtable-input’

入力ファイルがPOファイルの構文ではなく、NeXTstep/GNUstepのlocalized resourceの.stringsの構文にのっとったファイルだとみなします。

6.1.4 出力の詳細

‘-l ll_CC’

‘--locale=ll_CC’

対象のlocaleを設定します。llにはlanguage codeを、CCにはcountry codeを設定する必要があります。インストールされているすべてのlocaleのリストを出力するには、‘locale -a’コマンドを使用できます。デフォルトはユーザーのlocale設定が使用されます。

‘--no-translator’

POファイルが翻訳者の手で作成されたものではなく、自動的に生成されたものであることを宣言します。

‘--color’

‘--color=when’

色や色以外のテキスト属性を使うか、いつ使うかを指定します。詳細は--colorオプションを参照してください。

‘--style=style_file’

--colorにたいしてCSS style ruleファイルを使うかを指定します。詳細は--styleオプションを参照してください。

‘-p’

‘--properties-output’

Javaの.propertiesの書式で、Java ResourceBundleを出力します。このファイル形式はplural formをサポートせず、廃止されたメッセージを暗黙で除去することに注意してください。

‘--stringtable-output’

.stringsの書式で、NeXTstep/GNUstepのローカライズされたリソースファイルを出力します。このファイル形式はplural formをサポートしないことに注意してください。

‘-w number’

‘--width=number’

出力ページの幅をセットします。これにより出力ファイル中の長い文字列が指定した幅(例:スクリーンの列数)に収まるように、各行の長さがnumber以下のような複数の行に分割されます。

‘--no-wrap’

長いメッセージ行を分割しません。出力ページの幅を超えるようなメッセージ行も、複数行に分割されません。出力ページの幅を超えるファイル参照行だけが分割されます。

6.1.5 情報的な出力

‘-h’

‘--help’

このヘルプを表示して終了します。

‘-V’

‘--version’

バージョン情報を表示して終了します。

6.2 ヘッダーエントリーを入力する

新規作成したときに初期値として入力されている、"SOME DESCRIPTIVE TITLE"、"YEAR"、および"FIRST AUTHOR <EMAIL@ADDRESS>、YEAR"などのコメントは、意味のある情報に書き換えるべきです。これはテキストエディターにより行うこともできますが、Emacsを使っていれば(拡張子を識別して)自動的にPOモードに切り替わります。これはM-x fundamental-modeと入力して無効にすることができます。

ヘッダーのエントリーの変更も、POモードで行うことができます。Emacsで、M-x po-mode RETと入力して、さらにRETを押すと、エントリーの編集が開始できるので、以下のフィールドに入力してください。

Project-Id-Version

パッケージの名前とバージョンです。xgettextにより入力されていない場合は入力してください。

Report-Msgid-Bugs-To

これはxgettextによってすでに入力されています。未翻訳の文字列に関するバグを報告するための、電子メールアドレスかURLが含まれています:

• - センテンス全体となっていないような文字列。メンテナーのためのガイドライン 翻訳可能な文字列の準備を参照してください。
• - 不明な用語を使用したり、追加のコンテキストを理解することが必要とする文字列 。
• - 日付・時刻・通貨の表記で、無効な仮定をしている文字列 。
• - plural化に関する問題。
• - 間違ったEnglishのスペル。
• - 間違った書式。

POT-Creation-Date

これはxgettextによってすでに入力されています。

PO-Revision-Date

これはPOファイルのためのエディターが、ファイルを保存するときに入力される項目なので、あなたは入力する必要はありません。

Last-Translator

名前と電子メールアドレス（ダブルクォーテーションなし）を入力してください。

Language-Team

言語の英語名と、あなたが所属するlanguage teamの電子メールアドレスか、ホームページのURLを入力してください。

重複して作業するの防ぐためだけではなく、言語に関する難しい問題を調整するためにも、翻訳を開始する前にtranslation teamに連絡することをお勧めします。

フリーな翻訳プロジェクトでは、それぞれの翻訳チームが、チーム自身のメーリングリストを持っています。チームの最新のメーリングリスト一覧は、Free Translation Projectのホームページ(http://translationproject.org/) の"Teams"という場所にあります。

Language

あなたの言語の言語コードを入力してください。以下の3つの形式のいずれかになります:

• - ‘ll’: ISO 639の2文字(小文字)の言語コードです。コードの一覧はLanguage Codesを参照してください。
• - ‘ll_CC’: ‘ll’はISO 639の2文字(小文字)のlanguage code、‘CC’はISO 3166の2文字(大文字)のcountry codeです。いくつかのlanguageは、異なるcountryで使用される方言を持っていますが、country codeの仕様に冗長性はありません。たとえば‘de_AT’はAustriaで使用され、‘pt_BR’はBrazilで使用されます。country codeは方言を区別するために提供されています。コードの一覧についてはLanguage CodesとCountry Codesを参照してください。
• - ‘ll_CC@variant’: ‘ll’はISO 639の2文字(小文字)のlanguage code、‘CC’はISO 3166の2文字(大文字)のcountry code、‘variant’はvariant designatorです。variant designator(小文字)には、‘latin’や‘cyrillic’のようなscript designatorを指定することもできます。

‘ll_CC’の命名規則は、システムがGNU libcにもとづいてlocale名を決定する方法でもありますが、重要な違いが3つあります。

• POファイルのこの項目はlocale名とは異なり、‘ll_CC’という組み合わせは、languageの主たる方言であることを示す‘ll’という略記であらわされます。たとえば、このコンテキストでは‘de’は‘de_DE’(Germanyで話されるGerman) と等しく、‘pt’は‘pt_PT’(Portugalで話されるPortuguese)と同じです。
• POファイルのこの項目では、‘.encoding’のような接尾辞は使用しません。
• POファイルのこの項目では、メッセージの翻訳とは関係のない、‘@euro’のようなvariant designatorは使用しません。

そのため、あなたのlocale名が‘de_DE.UTF-8’の場合、POファイルのlanguage specificationは‘de’だけになります。

Content-Type

‘CHARSET’を、あなたのlocaleのlanguageで使用するcharacter encodingかUTF-8で置き換えてください。この項目は、msgmergeとmsgfmtの正しい動作のために必要です。同様にlocaleのcharacter encodingが、あなたのものとは異なるユーザーにとっても必要です(gettextが使用する出力文字セットの指定方法を参照してください)。

localeのcharacter encodingは、シェルのコマンド‘locale charmap’を実行して得ることができます。このコマンドの結果が‘C’や‘ANSI_X3.4-1968’の場合のcharacter encodingは‘ASCII’(=‘US-ASCII’) となり、これはあなたのlocaleが正しく設定されていないことを意味します。そのような場合は、あなたの属するtranslation teamに、どのcharset を使用すればよいのか尋ねてください。‘ASCII’は、Latin 以外の language には適用できません。

POファイルは、オペレーティングシステムの高度なインターナショナリゼーションの利便性に依存せずに可搬性を持たなければならないため、使用できるcharacter encodingsは GNU libcと GNU libiconvでサポートされるものに限定されています。使用できるcharacter encodingはASCII、ISO-8859-1、ISO-8859-2、ISO-8859-3、ISO-8859-4、ISO-8859-5、ISO-8859-6、ISO-8859-7、ISO-8859-8、ISO-8859-9、ISO-8859-13、ISO-8859-14、ISO-8859-15、KOI8-R、KOI8-U、KOI8-T、CP850、CP866、CP874、CP932、CP949、CP950、CP1250、CP1251、CP1252、CP1253、CP1254、CP1255、CP1256、CP1257、GB2312、EUC-JP、EUC-KR、EUC-TW、BIG5、BIG5-HKSCS、GBK、GB18030、SHIFT_JIS、JOHAB、TIS-620、VISCII、GEORGIAN-PS、UTF-8です。

GNUシステムでは、対応する言語にたいして以下のエンコーディングが頻繁に使用されます。

• ISO-8859-1: Afrikaans、Albanian、Basque、Breton、Catalan、Cornish、Danish、Dutch、English、Estonian、Faroese、Finnish、French、Galician、German、Greenlandic、Icelandic、Indonesian、Irish、Italian、Malay、Manx、Norwegian、Occitan、Portuguese、Spanish、Swedish、Tagalog、Uzbek、Walloon
• ISO-8859-2: Bosnian、Croatian、Czech、Hungarian、Polish、Romanian、Serbian、Slovak、Slovenian
• ISO-8859-3: Maltese
• ISO-8859-5: Macedonian、Serbian
• ISO-8859-6: Arabic
• ISO-8859-7: Greek
• ISO-8859-8: Hebrew
• ISO-8859-9: Turkish
• ISO-8859-13: Latvian、Lithuanian、Maori
• ISO-8859-14: Welsh
• ISO-8859-15: Basque、Catalan、Dutch、English、Finnish、French、Galician、German、Irish、Italian、Portuguese、Spanish、Swedish、Walloon
• KOI8-R: Russian
• KOI8-U: Ukrainian
• KOI8-T: Tajik
• CP1251: Bulgarian、Belarusian
• GB2312、GBK、GB18030: Chineseの簡略表記
• BIG5、BIG5-HKSCS: Chineseの伝統的表記
• EUC-JP: Japanese
• EUC-KR: Korean
• TIS-620: Thai
• GEORGIAN-PS: Georgian
• UTF-8: 上記の言語を含む任意の言語

あなたの言語の翻訳に、その言語の1重引用符か2重引用符が使用されており、そのlocaleのencodingが ISO-8859-* のいずれかの場合は、POファイルはlocaleのencodingではなくUTF-8 encodingで作成するのが最善です。これはUTF-8では、ISO-8859-*が持っていない実際の引用文字(1重引用符はU+2018とU+2019、2重引用符はU+201CとU+201D)が表現可能だからです。UTF-8のlocale のユーザーは実際の引用符文字列を見ることができますが、ISO-8859-*のlocaleでは垂直方向のアポストロフィーと垂直方向のダブルクォーテーションが(文字セットの変換により)代用で表示されます。

X11でこれらの引用文字を入力するために、xmodmapプログラムでキーボードのマッピングを使用することができます。この場合、X11 での引用文字の名前は"leftsinglequotemark"、"rightsinglequotemark"、"leftdoublequotemark"、"rightdoublequotemark"、"singlelowquotemark"、"doublelowquotemark"になります。

UTF-8 encodingは、新しいバージョンのGNU Emacsでだけサポートされていることに注意してください。たとえばEmacs 20 with Mule-UCSやEmacs 21ではUTF-8 encodingがサポートされていますが、2001年1月時点のXEmacsではサポートされていません。

文字のエンコーディング名は、大文字または小文字で記述することができますが、通常は大文字が好まれます。

Content-Transfer-Encoding

8bitにセットしてください。

Plural-Forms

このフィールドはオプションで、POファイルにplural formがあるときだけ必要です。これは‘msgid_plural’というキーワードを検索すればわかります。plural formのフィールドの書式については複数形(plural forms)にたいする追加の関数と複数形の翻訳を参照してください。

7 既存のPOファイルの更新

7.1 msgmergeプログラムの呼び出し

msgmerge [option] def.po ref.pot

msgmergeプログラムは、Uniforumスタイルの2つの.poファイルをマージして1つにします。def.poファイルは既存のPOファイルで、メッセージが一致していれば既存の翻訳は新しいファイルに引き継がれます。その際、コメントは残されますが、抽出されたコメントやファイル内の位置などは破棄されます。ref.potは、最新のソースより作られたPOファイルですが、古い翻訳や、(通常はxgettextにより作成された)PO Templateファイルを参照するため、ドットコメント(訳注:プログラマーから翻訳者へのコメント#.のこと)やファイル内の位置情報は保存されますが、ファイル内のいくつかの翻訳やコメントは、破棄されるでしょう。完全に一致するメッセージが見つからない場合、より良い結果を生成するためにfuzzy一致が使用されます。

7.1.1 入力ファイルの位置

‘def.po’

古いソースを参照する翻訳です。

‘ref.pot’

新しいソースへの参照です。

‘-D directory’

‘--directory=directory’

ディレクトリーのリストにdirectoryを追加します。このディレクトリーのリストよりソースファイルを検索します。しかし.poファイルが出力されるのは、カレントディレクトリーです。

‘-C file’

‘--compendium=file’

メッセージを翻訳するための追加のライブラリーを指定します。翻訳compendiaの使用を参照してください。このオプションは複数指定することができます。

7.1.2 オペレーションモード

‘-U’

‘--update’

def.poファイルを更新します。すでにdef.poが最新の場合は何もしません。

7.1.3 出力ファイルの位置

‘-o file’

‘--output-file=file’

指定されたファイルに出力を書き込みます。

出力ファイルが指定されていない、または‘-’が指定された場合、結果は標準出力に出力されます。

7.1.4 更新モードでの出力ファイルの位置

処理結果はdef.poファイルに書き戻されます。

‘--backup=control’

def.poのバックアップを作成します。

‘--suffix=suffix’

通常使用されるバックアップの接尾辞を上書きします。

--backupオプション、もしくは環境変数VERSION_CONTROLを通じてバージョン管理の方式を選択します。以下の値が指定できます:

‘none’

‘off’

(--backupオプションが指定されていたとしても)バックアップを作成しません。

‘numbered’

‘t’

番号付きのバックアップを作成します。

‘existing’

‘nil’

このファイルの番号付きのバックアップがすでに存在する場合、番号付きバックアップを作成し、そうでなければ単純なバックアップを作成します。

‘simple’

‘never’

常に単純なバックアップを作成します。

--suffixまたは環境変数SIMPLE_BACKUP_SUFFIXが設定されていない場合は、バックアップの接尾辞として‘~’を使用します。

7.1.5 オペレーションの修飾

‘-m’

‘--multi-domain’

def.po内の各ドメインにたいして、ref.potを適用します。

‘-N’

‘--no-fuzzy-matching’

完全に一致するものが見つからない場合、fuzzyマッチングを行いません。これにより処理のスピードが大幅に改善されます。

‘--previous’

翻訳されたメッセージをもつ古いmsgidにたいしてfuzzyマーカーを追加するときに、‘#|’マークをつけて古いメッセージを保持します。

7.1.6 入力ファイルの構文

‘-P’

‘--properties-input’

入力ファイルがPOファイルの構文ではなく、Javaの.propertiesの構文にのっとったJava ResourceBundleファイルだとみなします。

‘--stringtable-input’

入力ファイルがPOファイルの構文ではなく、NeXTstep/GNUstepのlocalized resourceの.stringsの構文にのっとったファイルだとみなします。

7.1.7 出力の詳細

‘--lang=catalogname’

ヘッダーのエントリーで使用される‘Language’フィールドを指定します。このフィールドの意味についてはヘッダーエントリーを入力するを参照してください。‘Language-Team’と‘Plural-Forms’のフィールドは変更されないことに注意してください。このオプションを指定しない場合、‘Language-Team’フィールドから最適なものを推測して、‘Language’フィールドに入力します。

‘--color’

‘--color=when’

色や色以外のテキスト属性を使うか、いつ使うかを指定します。詳細は--colorオプションを参照してください。

‘--style=style_file’

--colorにたいしてCSS style ruleファイルを使うかを指定します。詳細は--styleオプションを参照してください。

‘--force-po’

メッセージが何も含まれていない場合でも、常に出力ファイルに書き込みます。

‘-i’

‘--indent’

インデントされた形式で.poファイルを書き込みます。

‘--no-location’

‘#: filename:line’という行を書き込みません。

‘-n’

‘--add-location=type’

‘#: filename:line’という行を生成します(デフォルト)。

typeはオプションで、‘full’、‘file’、または‘never’を指定できます。オプションが指定されない、または‘full’の場合は、ファイル名と行番号のの両方が生成されます。‘file’の場合、行番号は省略されます。‘never’の場合は、完全にこの行を抑制します(--no-locationと同じです)。

‘--strict’

Uniforumに厳密に準拠したPOファイルを出力します。このUniforum形式はGNUの拡張をサポートしないため避けたほうがよいでしょう。

‘-p’

‘--properties-output’

Javaの.propertiesの書式で、Java ResourceBundleを出力します。このファイル形式はplural formをサポートせず、廃止されたメッセージを暗黙で除去することに注意してください。

‘--stringtable-output’

.stringsの書式で、NeXTstep/GNUstepのローカライズされたリソースファイルを出力します。このファイル形式はplural formをサポートしないことに注意してください。

‘-w number’

‘--width=number’

出力ページの幅をセットします。これにより出力ファイル中の長い文字列が指定した幅(例:スクリーンの列数)に収まるように、各行の長さがnumber以下のような複数の行に分割されます。

‘--no-wrap’

長いメッセージ行を分割しません。出力ページの幅を超えるようなメッセージ行も、複数行に分割されません。出力ページの幅を超えるファイル参照行だけが分割されます。

‘-s’

‘--sort-output’

ソートされた出力を生成します。このオプションを使用することにより翻訳者が、メッセージがどのようなコンテキストで使用されるかを理解するのが、困難になることに注意してください。

‘-F’

‘--sort-by-file’

ファイルの場所により出力をソートします。

7.1.8 情報的な出力

‘-h’

‘--help’

このヘルプを表示して終了します。

‘-V’

‘--version’

バージョン情報を表示して終了します。

‘-v’

‘--verbose’

診断レベルを上げます。

‘-q’

‘--quiet’

‘--silent’

プログレスインジケーターを表示しません。

8 POファイルの編集

8.1 KDEのPOファイルエディター

8.2 GNOMEのPOファイルエディター

8.3 EmacsのPOファイルエディター

幸運にもあなたがEmacsのユーザーならば、POファイルの編集・変更のための快適な環境を提供するために特別に作成されたPOモードがあります。POファイルを編集するときPOモードを使えば、追加のPOファイルやcompendium POファイルを閲覧したり、POファイルの元となるCプログラムのソースへの参照を追跡するのが簡単になります。またプログラム中の文字列にたいして対話的に翻訳可能のマークをつけたり、POファイルを検証してエラーのある行を再配置するための特別な機能があります。

POモードを使うにはまず、主要なPOモードのコマンド(主要なPOモードのコマンドを参照してください)以外に、エントリー間の移動(エントリーの決定を参照してください)や、翻訳されていないエントリーの処理方法(未翻訳エントリーを参照してください)を理解する必要があります。

8.3.1 GNU gettextのインストールを完了する

1度GNU gettextディストリビューションを入手して解凍し、configure、コンパイルしてしまえば、‘make install’コマンドでxgettext、msgfmt、gettext、msgmergeなどのプログラムや、それらが利用できるメッセージのカタログを所定の場所に配置することができます。快適なインストールの締めくくりとして、EmacsのユーザーのためにPOモードを利用できるようにしましょう。

POモードをインストールしているうちに、あなたは.emacsファイルを修正して、以下のような行を追加したいと思うことでしょう:

(setq auto-mode-alist
      (cons '("\\.po\\'\\|\\.po\\." . po-mode) auto-mode-alist))
(autoload 'po-mode "po-mode" "Major mode for translators to edit PO files" t)

こうしておけば以後、.poのようなファイルや、ファイル名に‘.po.’という文字列が含まれるファイルを編集するとき、Emacs が必要に応じてpo-mode.elc(またはpo-mode.el)をロードして、割り当てられたバッファーにたいするPOモードのコマンドが自動的に利用可能になります。POモードがアクティブな任意のバッファーのモードラインには、POという文字が表示されます。単一のEmacsセッションで、1度に複数のPOファイルをアクティブにすることができます。

Emacsのバージョン20以上を使用していて、システムに適切なインターナショナルフォントがインストールされているなら、様々なPOファイルにたいして自動的にcoding systemを決定する方法をEmacsに指定することもできます。これはEmacsのスクリーンに翻訳を表示する時にしばしば、必要なフォントがロードされ使用されるということです(常にではありませんが)。これを実現するためには、あなたの.emacsファイルに以下の行を追加します:

(modify-coding-system-alist 'file "\\.po\\'\\|\\.po\\."
                            'po-find-file-coding-system)
(autoload 'po-find-file-coding-system "po-mode")

これでもまだinternationalなcharacterのかわりに四角が表示されるようなら、(Shiftキーを押しながらマウスボタン1をクリックして)違うフォントセットを試してみてください。

8.3.2 主要なPOモードのコマンド

GNU gettextのインストールを完了するで説明されているような行を追加してEmacsを設定した後は、POファイルを検知するとEmacsがそのウィンドウにたいしてPOモードを有効にします。これによりそのウィンドウは読み取り専用となり、po-mode-mapが設定されます。これはテキストモードから継承されたのではなく、純粋なEmacsのモードです。もしpo-mode-hookに指定された関数があれば、実行されます。

あるウィンドウにたいしてPOモードが有効になると、‘PO’という文字が、そのウィンドウのモードラインに表示されます。モードラインにはPOファイルに含まれている各種エントリーがいくつあるかも表示されます。たとえば‘132t+3f+10u+2o’という文字列が表示されている場合、POモードには132個の翻訳済みのエントリー(翻訳済みのエントリーを参照してください)と、3個のfuzzyエントリー(fuzzyエントリーを参照してください)、それに10個の未翻訳のエントリー(未翻訳エントリーを参照してください)と、2個の廃止されたエントリー(陳腐化したエントリーを参照してください)が含まれていることを翻訳者に示しています。この際、エントリーが0個のものは表示されません。この例にならうと、fuzzyエントリーが解消され、未翻訳のエントリーが翻訳され、廃止されたエントリーが削除されれば、モードラインには‘145t’だけが表示されることになります。

主要なPOコマンドの中には、以下のセクションのカテゴリー分けに適合しないものもあります。それらのコマンドとは、POモードやPOモードが管理するウィンドウを、特別な方法で終了する方法などです。

_

POファイルにたいする最後の変更を取り消します(po-undo)。

Q

処理を終了してPOファイルを保存します(po-quit)。

q

問い合わせの後に処理を終了します(po-confirm-and-quit)。

0

一時的にPOファイルのウィンドウを離れます(po-other-window)。

?

h

POモードのヘルプを表示します(po-help)。

=

POファイルに関する統計情報を取得します(po-statistics)。

V

POファイル全体のフォーマットを検証します(po-validate)。

_コマンド(po-undo)は、Emacsのundo機能と連携します。Undoing Changes in The Emacs Editorを参照してください。_を入力する度に、翻訳者がPOファイルにたいして行った変更が少しずつ取り消されていきます。取り消し機能を実現するために、POモードのコマンドはアトミックになっています。これは特にRETコマンドにたいして当てはまります。このコマンドを使用して行った1度の変更は、編集がいくつかの操作により行われたものだったとしても、1度の取り消しで元に戻ります。しかし編集中のウィンドウでは、作業をより小さい単位で取り消すことができます。

Qコマンド(po-quit)と、qコマンド(po-confirm-and-quit)は、翻訳者がPOファイルにたいする作業を終了するときに使用します。後者のコマンドは前者のコマンドに比べると冗長なコマンドです。ファイルが変更されていた場合、まずディスクにファイルが保存されます。ファイルが変更されていない場合でも、コマンドはまずPOファイルに未翻訳のメッセージが残されていないかをチェックして、もしそのようなメッセージが残っていた場合、翻訳者は本当にこのPOファイルにたいする作業を終了したいのか尋ねられます。これはEmacsのPOファイルにたいするバッファーを離れるときに望ましい方法です。単にバッファーをkillする通常のC-x kコマンド(kill-buffer))は、好ましい方法ではありません。

0コマンド(po-other-window)は、POモードを一時的に離れるときに使用する、よりソフトな方法です。このコマンドはカーソルをEmacsの他のウィンドウに移動して、他のウィンドウを表示します。たとえば翻訳者が、メッセージのソース文脈中での箇所を探して、ソースのバグを修正するためだけにPOモードを開いている場合などに使用します。このコマンドにより翻訳者たる彼女は、プログラマーたる彼へと性転換を遂げ、修正したいプログラムを表示しているウィンドウにカーソルを移すことができます。後でPOファイルのウィンドウにカーソルを戻すか、このファイルをもう一度編集するかをEmacsに指定した時に、POモードが復元されます。

hコマンド(po-help)は、POモードで利用可能なすべてのコマンドの要約が表示されます。翻訳者が任意の文字を入力することにより、通常のPOモードの操作に戻ることができます。?コマンドでも、hコマンドと同じ結果を得ることができます。

=コマンド(po-statistics)は、POファイルのすべてのエントリーを集計し、現在のエントリーが先頭から数えて何番目かと、未翻訳のエントリー数、廃止されたエントリー数等のすべての数を表示します。

Vコマンド(po-validate)は、msgfmtのverbose modeにより、編集中のPOファイルをチェックします。このコマンドは最初に編集中のPOファイルをディスクに保存します。GNU gettextのmsgfmtは、POファイルの出力としてMOファイルを生成するツールで、POモードがPOファイル全体の書式や個々のエントリーの書式をチェックするのに、このプログラムの機能が使用されています。

msgfmtプログラムはEmacsと非同期で実行されるので、POファイルの評価が終わっていなくても、制御はすぐに翻訳者に戻されます。標準エラー出力への出力はEmacsにより収集されて、他のウィンドウの‘*compilation*’バッファーに表示されます。Emacsの通常コマンドのC-x`(next-error)や、その他の同様のコンパイル時のコマンドにより、翻訳者は素早くPOファイル中の提示された位置に移動することができます。カーソルがエラーのある行に移動すると、翻訳者がエラーを修正するためのPOモードのコマンドを選択することができます。

8.3.3 エントリーの決定

POファイルのウィンドウの中のカーソルは、ほとんど常にエントリ一部となります。唯一の例外は、カーソルがファイルの最後のエントリーの後ろにあったり、POファイルが空だったりという、特別なケースのときだけです。カーソルのある位置のエントリーのことを、カレントエントリーと呼びます。POモードのコマンドの多くは、カレントエントリーにたいして操作を行うので、翻訳者にとってカーソルを動かすことはPOファイルを閲覧できるだけでなく、エントリーに作用するコマンドの対象エントリーを選択することでもあるのです。

POモードのコマンドには、特別な方法によりカーソルの位置を変更するものがあります。それらの特別な目的に対応する位置へカーソルを動かす方法については、ここで説明します。他の方法については、以降のセクションで説明します(C-h mで完全な一覧を得ることもできます)。

.

カレントエントリーを再表示します(po-current-entry)。

n

カレントエントリーの次のエントリーを選択します(po-next-entry)。

p

カレントエントリーの前のエントリーを選択します(po-previous-entry)。

<

POファイルの最初のエントリーを選択します(po-first-entry)。

>

POファイルの最後のエントリーを選択します(po-last-entry)。

m

後で利用できるように、現在のエントリーの場所を記録します(po-push-location)。

r

以前に記録したエントリーの場所に戻ります(po-pop-location)。

x

現在のエントリーの場所と、以前に記録したエントリーの場所を交換します(po-exchange-location)。

Emacsのカーソル位置を変更するための、文字、行、paragraph、画面単位での移動や検索などのコマンドは、POモードでカレントエントリを選択するのに使用できます。しかしPOモードには、通常のEmacsでカーソルを移動するコマンドには無いような、カレントエントリーを表示するための標準的な方法があります。.コマンド(po-current-entry)は、Emacsの画面が変更されたときなどPOモード以外の方法やでカレントエントリーが変更された時に、カレントエントリーを適切に再表示するという単一の目的のためのコマンドです。

翻訳者が作業をしているときに、POモードによりウィンドウ配置を厳格に強制されることが、彼女を助けるものなのか、それともイライラさせるものなのかは未だ不明です。私たちは当初、ウィンドウがどのように振る舞うべきかについて明確なアイデアを持っていました。しかしその一方で、Emacsを使うとき自分で完全にコントロールできるほうを好む人もいます。固定されたウィンドウ配置は、翻訳者が有効・無効を選択できるようにPOモードのオプションとして、実験的な機能として提供されるべきでしょう。もしこの機能を使う必要性や、記述する衝動をもつ人がだれもいないなら、私たちはこのアイデアを放棄するべきなのでしょう。これを行うには、プログラマーよりも翻訳者からの動機が必要です。私にとって、経験を積んだ翻訳者の意見は、他者がどうやって翻訳するか想像するしかないプログラマーの意見にくらべて、より価値があるからです。

nコマンド(po-next-entry)とpコマンド(po-previous-entry)は、カーソルをカレントエントリーの前または後のエントリーに移動します。POファイルの最後のエントリーにカーソルがあるときにnを押したり、最初のエントリーにカーソルがあるときにpを押しても、移動は行われません。

<コマンド(po-first-entry)と>コマンド(po-last-entry)は、POファイルの最初のエントリー、または最後のエントリーにカーソルを移動します。POモードのほとんどのコマンドは、POファイルの最後のエントリー以降にカーソルがあるときは、‘After last entry’のようなエラーを戻します。<コマンドと>コマンドは、カーソルがPOファイルのエントリーにない場合でも動作する特性があるので、このような状況をうまく解決するのに使う人もいます。しかしこれらのコマンドも、POファイルが空の場合は失敗します。ソースから対話的に空のPOファイルにエントリーを追加していくようにPOモードを開発するプランもあります。翻訳可能文字列のマークを参照してください。

翻訳者が特定のエントリーを翻訳する前には、そのエントリーに関連する用語や言い回しを探すために、POファイルの残りの部分を参照する必要があるかもしれません。もちろん彼女はEmacsの標準的な慣例にしたがって、カレントカーソルの位置をレジスターなどに保存して、後でその場所に戻るのにそのレジスターを使ったり、場所を記憶するためのリングバッファーを使うこともできます。

これらの方法にたいして、POモードは特別なスタックにカーソルの場所を保存するという、別の方法を提供します。mコマンド(po-push-location)は、スタック上に既に保存してあるカーソル位置の情報の上に、カレントエントリーをpushします。rコマンド(po-pop-location)は、スタックの最上部の要素をpopして、カーソルをその要素に関連付けられた位置へと移動します。これによりpopされた要素の位置情報は失われ、次のrコマンドでは、その要素の1つ前に保存された位置にカーソルが移動します。これはスタックに保存された位置の情報がなくなるまで同じように動作します。

翻訳者がスタックの最上位の要素に関連付けられているエントリーの位置を確認してから他の場所に移動して、後で元の場所に戻る等の理由で、エントリーの場所をスタックに保存したいとき、彼女はrの直後にmを使うべきです。

xコマンド(po-exchange-location)は、カーソルをスタックの最上位の要素に関連付けられた位置に再配置すると同時に、移動する前のカレントエントリーの位置を最上位の要素に保存します。つまり、xコマンドを繰り返し使うと、それら2つのエントリーを行き来することができます。これを行うにはまず、最初のエントリーにカーソルを移動してからmコマンドを使用し、その後2番目のエントリーでxコマンドを使えば、2つのエントリー間を行き来することができます。

8.3.4 エントリー内の文字列の正規化

特定の文字列をPOファイルのエントリーにエンコードする場合、複数行を分割したり括ったりする方法、さらには特殊な文字をバックスラッシュでエスケープする方法までもが異なっている等、とても多くの方法があります。POモードには、特定のエンコードの文字列をmsgidフィールドに挿入するために、既存のPOファイルをスキャンする機能があります。POモードにはこれらを簡単に認識するためのビルトイン機能が内部的に存在しますが、これを高速に行うのは技術的に困難です。この効率に関する問題の解決を容易にするために、わたしたちは文字列の正規表現を採択しました。

POファイル内の文字列の標準的な表現方法については現在も議論されていますが、POモードでは正規表現を実験的に採用しています。xgettextとPOモードで、同じ文字列を統一された方法で表示するのは、POモードで必要となる内部的な正規化が、GNU gettextからのxgettextの使用をも自動的に満たすので便利なのです。明示的なPOモードの正規化は、POファイルが他の場所からインポートされたときや、慣例そのものが変更されたときに必要です。

正規表現が必要なPOファイルの文字列を正規化するために、以下のPOモードのコマンドが利用可能です:

M-x po-normalize

エントリーをより標準化することにより、PO ファイル全体を整理します。

特別なコマンドであるM-x po-normalizeコマンド(キーは関連付けられていません)は、未翻訳のエントリーおよび翻訳済みのエントリー両方を、POファイル内部の標準的な引用符で括って、すべてのエントリーを修正します。このコマンドは最後のエントリーより後ろにあるゴミも削除します。このコマンドは、他の場所からインポートしたPOファイルを新たにインポートするときや、わたしたち自身がこの正規化された引用書式を改善していけるならば、有用となるでしょう。この正規化された書式はPOファイルを整理するだけでなく、ほかのPOモードのコマンドがmsgidから文字列を検索する処理のスピードを大幅に改善します。

M-x po-normalizeは、エントリーにたいして3パスの処理を行います。最初のパスで、複数行のmsgidとmsgstrに、K&R CスタイルのC文字列書式を使用しているGNU gettext 0.6以前のPOファイルを発見して変換します。この発見的な処理は、廃止されたエントリーに関連付けられておらず、バックスラッシュで終端されたコメントでは失敗します。これは後続のパスで、廃止されたコメントに続くコメントを完成させる処理に依存します。この最初のパスは、すべての古いPOファイルの調整後は行われません。2番目と3番目のパスでは、すべてのmsgidとmsgstrの文字列を、それぞれ正規化していきます。これらのパスではXViewのmsgfmtの継続行のためのバックスラッシュも除去します。

このように明示的に正規化を指定するコマンドは、他のソースからPOファイルをインポートするときだけではなく、現在使われている慣用句や美的観点による改善を容易にします。正規化コマンドで提案された調整を後で行うのは簡単で、最終的には他のGNU gettextツールも、この適合を自動化する必要があります。Emacsを持っていないが、それでもPOファイルを上手に手作りしたい人のために、以下では正規化された文字列の書式を説明します。

POモードの文字列は単一行か複数行になります。文字列内に埋め込まれた改行が存在するとき、すなわち‘[^\n]\n+[^\n]’というパターンにマッチする文字列は複数行になります。例えば以下のような文字列があったとします:

msgstr "\n\nHello, world!\n\n\n"

この文字列の空白を改行に置き換えると、以下のような文字列になります:

msgstr ""
"\n"
"\n"
"Hello,\n"
"world!\n"
"\n"
"\n"

ここでは問題点を明確にするために、カリカチュアーされた例を使用して議論していきます。通常、複数行の体裁は悪いものではありません。これを処理するための実装は多分、次のような提言にしたがったものになるでしょう。すべての改行、および空行を表す改行を空文字列の中にまとめます(n > 1からn-1番目の改行は文字列を区切る改行です)。これにより文字列は以下のようになります:

msgstr "\n\n"
"Hello,\n"
"world!\n"
"\n\n"

文字列の初期化に関しては、まだ未解決の点もあります。これらの問題については、解決されたものからこのドキュメントに記載されるでしょう。

8.3.5 翻訳済みのエントリー

POファイル中のエントリーのmsgstrが翻訳されて、fuzzy(fuzzyエントリーを参照してください)もマークされていない場合、そのエントリーを翻訳済みのエントリーと呼びます。以後の処理では、翻訳済みのエントリーだけがGNU msgfmtでコンパイルされて、プログラムで利用できるようになります。他の種類のエントリーは除外され、それらにたいする翻訳は出力されません。

翻訳済みのエントリーを処理するためのコマンドがいくつかあります。

t

次の翻訳済みエントリーを検索します(po-next-translated-entry)。

T

前の翻訳済みのエントリーを検索します(po-previous-translated-entry)。

tコマンド(po-next-translated-entry)とTコマンド(po-previous-translated-entry)は、翻訳済みのエントリーを見つけて、前方または後方に移動するためのコマンドです。翻訳済みのエントリーが見つからなかった場合、POファイルのバッファーの先頭または終端に戻って検索します。

翻訳済みのエントリーは通常、翻訳者が翻訳を編集した結果です。翻訳の修正を参照してください。ただし変数po-auto-fuzzy-on-editがnilでない場合、新しく翻訳されたエントリーは、公式な翻訳となる前に、最初はfuzzyエントリーになります。この場合、後でこのfuzzyエントリーのfuzzyを解消して、正式な翻訳済みのエントリーにする必要があります。fuzzyエントリーを参照してください。

8.3.6 fuzzyエントリー

POファイルのエントリーは、一連の属性を持っています。それらは名前から得られるような性質をもち、翻訳に関するシステムコメントを明示するために使用されます。その属性1つがfuzzyで、この属性をもつエントリーがfuzzy(あいまいな)な翻訳であることを示します。この属性がつけられたエントリーのことを、fuzzyエントリーと呼びます。

通常fuzzyエントリーは、おおよそ目的にあった翻訳であるような翻訳済みエントリーにたいして、翻訳者が見直しのために使用するものです。これらのfuzzyエントリーは、古い翻訳済みのPOファイルを新しいPOテンプレートファイルに対応して更新するために、msgmergeプログラムを適用することにより生成されることもあり、それはこのツールが、新しいmsgidが、古いものをわずかに修正したものであって、新しい修正されたエントリーに古い翻訳を選択できると推測したときです。元の文字列(msgid文字列)にたいするわずかな変更は、翻訳にも影響を与える場合があり、これは翻訳者による判断が必要です。あるエントリーにたいしてmsgmergeがfuzzyのマークを付与するのには、このような理由があるのです。

翻訳者が後で再検討する必要があるエントリーを覚えておくために、彼女自身の都合でエントリーをfuzzyとすることもあります。したがって特にfuzzyエントリーを処理するためのコマンドが、いくつかあります。

f

次のfuzzyエントリーを検索します(po-next-fuzzy-entry)。

F

前のfuzzyエントリーを検索します(po-previous-fuzzy-entry)。

TAB

カレントエントリーのfuzzy属性を取り除きます(po-unfuzzy)。

fコマンド(po-next-fuzzy-entry)とFコマンド(po-previous-fuzzy-entry)は、前方もしくは後方のfuzzyエントリーに移動します。fuzzyエントリーが見つからなかった場合、PO ファイルのバッファーの先頭または終端に戻って検索します。

TABコマンド(po-unfuzzy)は、エントリーに付与されているfuzzy属性を取り除いて、通常は翻訳済みのエントリーとします。さらに、変数po-auto-select-on-unfuzzyがnilでない場合には、TABコマンドにより自動的に他の対象となるエントリーに移動します。po-auto-select-on-unfuzzyの初期値はnil です。

po-auto-fuzzy-on-editの初期値はnilです。しかし変数po-auto-fuzzy-on-editにtをセットすると、RETコマンドで編集したエントリーは、後から再チェックなどができるようにfuzzyとマークされます。この場合、通常の使用法では、翻訳者が変更したエントリーは、(すでにfuzzy だった場合をのぞき)fuzzyエントリーに変更されることになります。彼女が翻訳に満足した場合、TABを使えばfuzzy属性をクリアーするとともに、他のエントリーへと移動することができます。まだ翻訳が不十分だと思ったときは、SPCを使えばfuzzy属性を保持したまま他のエントリーに移動することができます。

翻訳者が作業中のエントリーを後で見直したいようなときに見つけやすいように、翻訳済みのエントリーをfuzzyとマークする場合は、DELコマンド(po-fade-out-entry)を使うこともできます。

翻訳者が作業を終えてPOファイルのバッファーをqコマンドで閉じるとき、まだfuzzyエントリーが残っている場合は、終了してもよいか確認を求められます。

8.3.7 未翻訳エントリー

xgettextで元となるPOファイルを作成する場合には、msgidは未翻訳の文字列で初期化され、msgstrには空文字列がセットされます。このように翻訳に空文字列がセットされているエントリーのことを、未翻訳(untranslated)のエントリーと呼びます。プログラマーがプログラム内の文字列に変更を加えた場合、変更された文字列にたいする新しい未翻訳のエントリーとしてPOファイル中に現れることになります。

未翻訳のエントリーにたいしても、有効なエントリー間の移動に通常使用するコマンドと同様のレベルで考えることができます。未翻訳のエントリーは、最後に‘msgstr ""’があるので、容易に識別できます。

翻訳者の作業は(非常に簡単に表現するならば)、未翻訳のエントリーを探して編集・翻訳して、未翻訳のエントリーがなくなるまでそれを繰り返していくことではないでしょうか。特に未翻訳のエントリーを処理するためのコマンドが、いくつかあります。

u

次の未翻訳のエントリーを検索します(po-next-untranslated-entry)。

U

前の未翻訳のエントリーを検索します(po-previous-untransted-entry)。

k

カレントエントリーを未翻訳にします(po-kill-msgstr)。

uコマンド(po-next-untranslated-entry)とUコマンド(po-previous-untransted-entry)は、前方もしくは後方の未翻訳のエントリーに移動します。未翻訳のエントリーが見つからなかった場合、POファイルのバッファーの先頭または終端に戻って検索します。

kコマンド(po-kill-msgstr)は、単に翻訳された文字列を空文字列にすることによって、エントリーを未翻訳のエントリーにするコマンドです。翻訳の修正を参照してください。

翻訳者が作業を終えてPOファイルのバッファーをqコマンドで閉じるとき、まだ未翻訳のエントリーが残っている場合は、終了してもよいか確認を求められます。

8.3.8 陳腐化したエントリー

POファイルの陳腐化したエントリーとは、msgmergeによりローカライズされるパッケージ内で、その翻訳がもはや必要ないのでコメントアウトされているエントリーのことです。

陳腐化したエントリーにたいしても、有効なエントリー間の移動に通常使用するコマンドと同様のレベルで考えることができます。行にmsgidやmsgstrが含まれているか否かに関係なく、行が#で開始されているという事実により、陳腐化したエントリーを識別できます。

再初期化するために翻訳を空文字列に置き換えて、元の未翻訳の空文字列にするコマンドがあります。これらのコマンドはEmacsのkillリングと互換性があるので、以前にkillリングに保存された文字列を翻訳として挿入することもできます。またユーザーは翻訳を対話的に編集することができます。これらすべてのコマンドは廃止されたエントリーの編集にも適用できますが、エントリーは廃止された状態のままになります。

陳腐化したエントリーに特化したコマンドがいくつかあります。

o

次の陳腐化エントリーを検索します(po-next-obsolete-entry)。

O

前の陳腐化したエントリーを検索します(po-previous-obsolete-entry)。

DEL

有効なエントリーにたいしては、それを陳腐化したエントリーにします。陳腐化したエントリーの場合は、エントリーを削除します(po-fade-out-entry)。

oコマンド(po-next-obsolete-entry)とOコマンド(po-previous-obsolete-entry)は、前方もしくは後方の陳腐化したエントリーに移動します。陳腐化したエントリーが見つからなかった場合、POファイルのバッファーの先頭または終端に戻って検索します。

PO モードには、陳腐化したエントリーにたいして、そのエントリーを非コメント化することにより有効なエントリーにする方法は用意されていません。用意されていない理由は、元となる未翻訳の文字列と、プログラム中の文字列の対応をとることができなくなるからで、これは msgid 駆動の哲学と反するからです。

とはいえ有効なエントリーをコメントアウトして、陳腐化したエントリーとすることは可能です。後でGNU gettextユーティリティーが処理するとき、翻訳が見つからなければ未翻訳の文字列が使用されます。DELコマンド(po-fade-out-entry)は、カレントエントリーを消滅の方向へと押しやるコマンドです。有効なエントリー(翻訳されたエントリー)の場合には、そのエントリーをfuzzyエントリーにします。すでにfuzzyエントリーの場合には、確認後にそのエントリーをコメントアウトします。すでに廃止されたエントリーの場合には、そのエントリーをPOファイルから削除します。削除した翻訳を、他のPOファイルの、(通常は)未翻訳のエントリに再使用するのは簡単です。翻訳の修正を参照してください。

今後POモードを開発していく上で、あなたを寝不足とさせるような、解決すべき興味深い問題が存在します。POモードをよりよくするこのアイデアとは、新しく出現した文字列にたいする翻訳として、すべての陳腐化したエントリーの中から最適な候補を推測することです。これはアルゴリズム的に解決するには困難な問題であり、文字列の相似をより効果的に計測するための開発を行う必要があると私は考えています。現在ではこれらの作業は翻訳者がすべて決定しなければなりませんが、いつの日か陳腐化したエントリーから翻訳を検索することができる便利なツールを提供できるように努力しています。

8.3.9 翻訳の修正

POモードは、通常Emacsのバッファーを変更するような方法でPOファイルを直接編集することを防ぎます。そうすることで、直接編集してファイル全体のフォーマットや文字列の引用符を誤って編集してしまう等の、容易に発生し得るエラーを防ぎます。他の種類のエラーもありますが、それらのエラーは翻訳者がVコマンドを使っていつでも、バッチ検証プロセスにより発見・診断することができます。その他のエラーについては、翻訳者自身の判断と、彼女が翻訳したパッケージにたいする同じ母国語ユーザーによる、言語的な判定に頼る必要があります。

翻訳を作成し、機械的な診断およびユーザーによる報告を経た後、翻訳者は以下のコマンドを使って翻訳を変更します。

RET

翻訳を対話的に編集します(po-edit-msgstr)。

LFD

C-j

翻訳を元の未翻訳の文字列で再初期化します(po-msgid-to-msgstr)。

k

翻訳をkillリングに保存してから、削除します(po-kill-msgstr)。

w

翻訳をkillリングに保存するだけで、削除はしません(po-kill-ring-save-msgstr)。

y

翻訳をkillリングのもので置き換えます(po-yank-msgstr)。

RETコマンド(po-edit-msgstr)は、新しい翻訳を編集したり既存の翻訳を変更するための、新しいEmacsのウィンドウをオープンします。新しいウィンドウにはPOファイルのカレントエントリーの、翻訳のコピーが含まれています。翻訳のコピーは、すぐに編集できるように引用符を除かれていて、Emacsによる編集コマンドのすべてが使用できます。翻訳者が文字列の変更を終えたら、C-c C-cにより、自動的に引用符を付加した形式で結果を保存し、編集用のサブウィンドウを閉じることができます。変更を保存せずに取り消す場合には、C-c C-kを使用してください。詳細は、サブエディションの詳細を参照してください。

LFDコマンド(po-msgid-to-msgstr)は、翻訳を元の文字列で初期化します。このコマンドは通常、翻訳者が以前の作業を破棄して、元の文字列にたいして新しく翻訳をやり直したいときに使用します。

未翻訳のエントリーを編集するときに、常にLFDコマンドを自動的に実行させることもできます。po-auto-edit-with-msgidにtをセットすれば、翻訳に何も文字列が設定されていない場合には、元の文字列により翻訳が初期化されます。デフォルトではpo-auto-edit-with-msgidはnilです。

実際のところ、空の文字列から翻訳を開始するのか、それとも元の文字列のコピーから翻訳を開始するのかは好みの問題です。元の言語と、翻訳する言語があまりに異なっている場合には、単に空の文字列から開始するのがよいでしょう。その反対に元の言語と翻訳する言語が似ている場合には、元の文字列の数字や文字を再入力する手間を省きたいときもあるでしょう。未翻訳の余分な元文字列を取り除く手間がかかるとしても、彼女は元の文字列を見ながら未翻訳の文字列を翻訳で上書きしていく方法を好むかもしれません。

これにより、空文字列になる前の内容は、killリングと呼ばれる特別な場所に置かれます。wコマンド(po-kill-ring-save-msgstr)も、翻訳をkillリングにコピーする効果に違いはありませんが、エントリーをそのままにする点が異なります。この場合、エントリーから翻訳は削除されません。どちらのコマンドも、Emacs愛好家にはよく知られている共有バッファーである、Emacsのkillリングを使用します。

翻訳者は作業する過程で、kやwを多く使うことでしょう。それにともないkillリングには翻訳が保存されていきます。killリングに保存された文字列は、後でEmacsの他のバッファーに挿入することができます。killリングは、単一のPOファイル内の異なるエントリー間だけではなく、翻訳者がPOファイルを複数開いている場合は、異なるPOファイル間で翻訳文字列を移動するのに使用されます。

POモードではないバッファーと文字列をやりとりするのを容易にするために、kコマンドでkillリングに置かれた翻訳文字列は、引用符が取り除かれて保存されます。すなわち、文字列を囲うための引用符は取り除かれ、複数行の文字列は結合され、バックスラッシュでエスケープされた文字は対応する実際の文字に変換されます。陳腐化したエントリーの場合、保存される前に翻訳は非コメント化されます。

yコマンド(po-yank-msgstr)は、カレントエントリーの翻訳をkillリングの文字列で完全に置き換えます。Emacsの用語にしたがうと、置き換えた文字列は、PO ファイルのバッファーへyank(yanked)されたといいます。Yanking in The Emacs Editorを参照してください。最初にyを使用したときは、killリングに最後に追加された値が翻訳として戻されます。他のキーを押さずに、もう一度yをタイプすると、killリングの最後から2番目に追加された文字列が、翻訳として挿入されます。yを何度も繰り返すことにより、望む文字列が見つかるまで、killリングに保存された文字列を巡回することができます。

文字列がPOファイルのエントリーにyankされるときには、自動的にPOファイルの書式にしたがった形式の引用符が付与されます。さらに陳腐化したエントリーの場合には、文字列は適切にコメント化されます。プログラムが使用できるように、翻訳された個々の文字列に引用符を付与するために、翻訳者が患わされることはありません。

kとwだけが、文字列をkillリングに保存するコマンドではないことに注意してください。POモードの多くのコマンドは、翻訳された文字列(または翻訳者のコメント)を置き換えて、自動的にリングに保存します。この一般的なルールに当てはまらないコマンドは、yankコマンド自身です。

文字列のkillとyankについては、一般的な状況の実例で説明したほうがよいでしょう。プログラマーが文字列にちょっとした変更を加えたとしましょう。その後、彼が行った変更は、変更した文字列にたいする新しい未翻訳のエントリーとしてPOファイルに出現し、元の変更されていない文字列にたいする翻訳は、陳腐化したエントリーとなります。多くの場合、翻訳者は未翻訳エントリーのmsgstrに、陳腐化したエントリーの変更前の翻訳を流用することで作業を節約できるでしょう。その後、陳腐化したエントリーが必要ないなら、安全に削除することができます。

翻訳者が未翻訳のエントリーを見つけて、それが既存の翻訳と少ししか違わないのではないか、と思ったとしましょう。そのような場合は、すぐにカレントエントリーの場所をmでマークしてから、陳腐化したエントリーを検索して、変更される前の文字列にたいする翻訳を探すためにoを使用します。見つかったら、DELコマンドで廃止されたエントリーを削除します。なぜなら彼女はDELコマンドが翻訳をkillすることを知っており、それはつまり翻訳がkillリングに保存されることを知っているからです。その後rコマンドで最初の未翻訳エントリーに戻り、保存した翻訳をyコマンドでmsgstrにyankします。これで翻訳者は、RETを使って自由に翻訳内容を調整することができます。そしてその後は再びuとmで次の未翻訳の文字列を探していくのかもしれません。

翻訳者が同じキーシーケンスを何度も使用する必要があるときには、要求したときにそのキーシーケンスを再生させるEmacsの機能について学習するほうがよいかもしれません。Keyboard Macros in The Emacs Editorを参照してください。

8.3.10 コメントの修正

翻訳とは、言語的な難しさをともなう作業です。翻訳においてどのような決定をしたのか、その選択に関してドキュメントを残す必要があるでしょう。これらのドキュメントは、翻訳者のコメントとしてPOファイルに保存されます。これは、翻訳者が自由に作成・削除、または変更ができるコメントで、彼女が後でPOファイルを見直すときなどに便利です。

最初の‘#’の後に空白がないコメント、たとえば‘#.’や‘#:’ではじまるコメントは、翻訳者のコメントではありません。これらは、gettextツールにより作成されたコメントです。それらのシステムが追加したコメントは、翻訳者が変更するべきではないコメントなので、以下で説明するコマンドの対象外です。POファイルのフォーマットを参照してください。

以下のコマンドは翻訳を変更するコマンドと似ているので、一般的な原則は同様に適用できます。翻訳の修正を参照してください。

#

翻訳者のコメントを対話的に編集します(po-edit-comment)。

K

翻訳者のコメントをkillリングに保存してから、削除します(po-kill-comment)。

W

翻訳者のコメントをkillリングに保存するだけで、削除はしません(po-kill-ring-save-comment)。

Y

翻訳者のコメントを、killリングのもので置き換えます(po-yank-comment)。

これらの、翻訳文字列を変更するためのPOモードの類似コマンドは、翻訳文字列の代わりに翻訳者のコメントを処理する以外は、同じように動作します。詳細はすでに説明済みなので、以下ではこれらのコマンドを簡単に説明します。翻訳の修正を参照してください。

#コマンド(po-edit-comment)は、POファイルのカレントエントリーにたいする翻訳者コメントのコピーを含む、新しいEmacsウィンドウをオープンします。エントリーにそのようなコメントがない場合、POモードは翻訳者がエントリーにコメントを追加したいと解釈し、空のスクリーンが表示されます。編集前にコメントマーク(#)とそれに続くスペースは自動的に削除され、編集後に自動的に再付加されます。陳腐化したエントリーにたいする翻訳者コメントは、非コメント化とコメント化の操作が2度行われます。編集ウィンドウでC-c C-cキーを押すと、コメントの編集を終了します。詳細については、サブエディションの詳細を参照してください。

po-subedit-mode-hookに関数が登録されている場合には、編集バッファーに文字列が挿入されたときに実行されます。

Kコマンド(po-kill-comment)は、翻訳者コメントをkillリングに保存してから削除します。Wコマンド(po-kill-ring-save-comment)は、翻訳者コメントをkillリングにコピーするだけで、カレントエントリーのコメントは変更しません。Yコマンド(po-yank-comment)は、翻訳者コメントをkillリングの文字列で置き換えます。このコマンドを繰り返し入力すると、挿入されたコメントはkillリングに保存された他の文字列で順に置き換えられます。

killリングの文字列は、すべて同じ性質をもちます。翻訳された文字列と翻訳者のコメントに違いはありません。たとえば翻訳者が翻訳を終了したとき、以前の翻訳の何が悪かったのかをドキュメント化して覚えておこうと、コメントを付与したい場合を考えます。彼女は翻訳者コメントで、以前の翻訳を引用したいと思うのではないでしょうか。それを行うには、まず翻訳者コメントを、killリングに残っている以前の翻訳で初期化するでしょう。すでにkillリングに保存されている以前の翻訳を使って編集するには、#の前にM-wとタイプすれば、以前の翻訳がkillリングに保存されるので、それに説明文などを追加すればよいでしょう。

すでに何らかの翻訳者コメントがあり、そのコメント全体を置き換えるのではなく翻訳者がコメントを追加したい場合を考えてみましょう。その場合には#でコメントを編集する必要があります。編集ウィンドウが開いたら、Emacsの標準コマンドのC-y(yank)とM-y(yank-pop)で、以前の翻訳を取得できます。

8.3.11 サブエディションの詳細

PO subeditマイナーモードは、ここで詳細な説明をする価値のある特殊なモードです。これによりEmacsの通常の編集コマンド以外に、以下で説明するコマンドがインストールされます。

C-c C-c

編集を完了します(po-subedit-exit)。

C-c C-k

編集を中止します(po-subedit-abort)。

C-c C-a

追加(auxiliary)のPOファイルを参照します(po-subedit-cycle-auxiliary)。

ウィンドウにはメッセージにたいする翻訳、もしくは翻訳者コメントが表示されます。翻訳者は自分の思うように、このウィンドウ内のコンテンツを変更します。作業が終わったら、C-c C-cコマンド(po-subedit-exit)を使えば、バッファーが切り替えられていたり、表示されていなくても、編集した翻訳で元の翻訳を置き換えてPOファイルに反映することができます。

kill翻訳者が自分の翻訳(または翻訳者コメント)に満足できなくて、RETコマンド(または#コマンド)を押す前の状態に戻したい場合には、C-c C-kコマンド(po-subedit-abort)を使えば、編集したものを破棄して、元の翻訳(または翻訳者コメント)に戻すことができます。他にも、普通にC-c C-cで編集を終了してから、U(訳注： UndoをするコマンドがUコマンドと記述してあるが、EmacsのUndoコマンドであるCtrl+_コマンドの間違いではないか)で元のバージョンに戻す方法があります。

C-c C-aコマンド(po-subedit-cycle-auxiliary)は、カレントエントリーの翻訳を編集しているとき、すでに他の言語へ翻訳されたメッセージに目を通したいときに使用します。このコマンドは翻訳者が複数の言語に通じているときなどに便利でしょう(もちろん利用可能な追加のPOファイルがある場合ですが(追加POファイルを調べるを参照してください)。

po-subedit-mode-hookに関数が登録されている場合には、編集バッファーに文字列が挿入されたときに実行されます。

編集中には、翻訳文字列の最後で意図せずRET(改行)キーを入力したり、必要な改行を誤って削除していまわないよう注意を払う必要があります。そのような文字が編集バッファーで非表示になっていると、容易に間違いを犯してしまいます。そのような間違いが起きないように、RETコマンドでは、編集している文字列の最後に自動的に<が付加されます。この<は実際のメッセージ文字列ではありません。C-c C-cで編集ウィンドウを閉じると、POモードは自動的にそのような<文字を削除して、適切な空白文字に置き換えます。翻訳者が末尾の<の後ろに文字を追加すると、<は区切り文字としての性質を失って、翻訳文字列の一部となります。<を削除した場合には、編集文字列はそのまま評価され、たとえ非表示であったとしても、末尾に改行があればそれもそのまま評価されます。翻訳した文字列が本物の<で終わる場合には、区切り文字の<も削除されずに表示されるので、編集ウィンドウの文字列の終端には2つの<が表示されます。

翻訳(またはコメント)を編集するとき、翻訳者はカーソルをPOファイルのバッファーに戻してから、エントリーを表示するために自由に他のエントリーに移動を行えます。編集を保留して、POファイルバッファーの他の箇所に移動したり、他のエントリーの編集をはじめることもできます。それぞれのエントリーは、それら自身のサブエディットバッファーで編集されます。1つのエントリーにたいする特定の翻訳やコメントを同時に編集したり、異なるPOファイルのエントリーを同時に編集することも可能です。すでに編集中のエントリーにたいしてRETをタイプすると、単にそのエントリーの編集を再開します。Emacsの複数のウィンドウの扱いに慣れれば、翻訳者はより快適になるでしょう。

保留したサブエディットの完了または中止は、編集を開始した順番に関わらず任意の順番で行うことができます。複数のサブエディットを保留している状態で、(qコマンドで)POファイルを閉じようとすると、サブエディットが1つずつ順番に再開されるので、翻訳者それら個々について決定していくことができます。

8.3.12 Cソースのコンテキスト

POモードは、GNU gettextユーティリティーで作成されたPOファイルの場合、それらのユーティリティーが生成したPOファイルに特別なコメントを挿入するので、特に威力を発揮します。それらの特別なコメントの中には、POファイルのエントリーの未翻訳の文字列が、プログラムのソース中で出現する位置を示すものがあります。

翻訳者が未翻訳の文字列を翻訳するとき、その元文字列があまりに簡潔すぎたり、不可解あったり、曖昧である等、通常のように有効でない場合があります。そのような文字列をどのように翻訳するか決める前に、その文字列が本当は何を意味するのか、そしてそれにぴったりな翻訳は何なのかを理解する必要があります。このような問題を判断するために残された唯一の方法は、プログラムのソースからその文字列の場所を探し、その周辺に残されたプログラマーのコメントや、他に助けになりそうな何かを探すことに時間を割くことです。

翻訳者が有能なプログラマーである場合、プログラムのソースを見ることにより多くの助けを得ることができるでしょう。しかしプログラミングに精通していなくて、Cのコードを見ると不安な気持ちになったとしても、恥ずかしがらずにたまにはソースを見てみましょう。そうすれば彼女が必要とする何らかのヒントを得られるようになれるでしょう。プログラマーのコメント、そして(彼が適切な名前をつけていれば)変数名や関数名、プログラムコード自体の全体的な構成などに注意を払って学習することにより、すぐにプログラムのコードを見ても違和感を感じないようになるでしょう。

以下は、翻訳者がPOファイルのエントリーから、プログラムのソースコンテキストを参照するのに助けとなるコマンドです。

s

プログラムのソースコンテキストを表示、またはソースコンテキストのサイクル表示を再開します(po-cycle-source-reference)。

M-s

メニューで選択されたプログラムソースのコンテキストを表示します(po-select-source-reference)。

S

ソースファイルの検索パスにディレクトリを追加します(po-consider-source-path)。

M-S

ソースファイルの検索パスからディレクトリを削除します(po-ignore-source-path)。

sコマンド(po-cycle-source-reference)とM-sコマンド(po-select-source-reference)は、どちらも他のウィンドウを開いてプログラムのソースファイルの、翻訳しようとしている文字列が使用されている場所を表示します。このように、これらのコマンドは文字列にたいするソースプログラムのコンテキストを与えます。しかしエントリーがコンテキストへの参照を保有していなかったり、検索パスにあるプログラムソースでは参照が解決されない場合、コマンドはその旨をエラーとして表示します。

s(またはM-s)も新しいウィンドウをオープンしますが、カーソルはPOファイルのウィンドウに留まったままです。翻訳者がプログラムソースのウィンドウに移動したい場合には、明示的にOコマンドを使用する必要があります。

はじめてsを使用するときや、POファイルのエントリーのソースコンテキストが直前に取得したものと異なるときには、コマンドはこのエントリーにたいして利用可能な、最初のコンテキストを返します。すでにそのPOファイルのカレントエントリーにたいする、何かしらのコンテキストを表示していて、さらに他のものを探したいときには最後に表示したコンテキストのウィンドウでsを入力することにより、検索を再開できます。このコマンドにより、翻訳者がソースファイルのコンテキストからカーソルを移動していた場合には、カーソルがコンテキストの場所に戻されます。他のコマンドを入力しないでsコマンドを連続して入力すると、POモードはこのエントリーにたいして利用可能なコンテキストを順々に表示していき、最後のコンテキストを表示すると、また最初のコンテキストに戻って表示します。

M-sコマンドは異なる動作をします。このコマンドは参照を循環して表示せずに、いくつか存在する参照のうちから1つを翻訳者に選択させます。翻訳者がM-sで表示される質問にたいして、すぐにTABを押すと、翻訳者が適切なものを選べるように利用可能なすべての参照メニューが表示されます。このコマンドは翻訳する1つの文字列にたいして、多数の利用可能なコンテキストが存在するときに有用です。

プログラムのソースファイルは通常、POファイルの場所から相対的に見つけることができます。この検索が失敗したときには、特別なケースとしてPOファイルの1つ上のディレクトリーからの相対パスのファイルも検索対象になります。これらの2つのケースを考えておけば、大抵のPOファイルを処理することができます。しかしPOファイルが移動されていたり、通常あるべき場所とは異なる場所で編集されているときには検索が失敗します。このような場合には、翻訳者がPOモードにたいして、POファイルが本来どのディレクトリーにあるのかを、伝える必要があります。そのように指定したディレクトリーのことをまとめて、プログラムソースの検索パスと呼びます。Sコマンド(po-consider-source-path)は、検索パスに新しいディレクトリーを対話的に入力するために使用され、M-Sコマンド(po-ignore-source-path)は、検索パスから削除したいディレクトリーを選択して削除するのに使用されます。

8.3.13 追加POファイルを調べる

POモードには、複数の言語に通じている翻訳者が、彼女の知っている言語への既存の翻訳を利用するための機能があります。この機能は、他の言語への翻訳を追加のコンテキストとして、彼女の作業に提供することができます。また一度に複数の言語への翻訳を作成したいような場合にも、翻訳者にたいして作業を容易にするための機能をもっています。

追加(auxiliary)のPOファイルとは、翻訳者が作業するパッケージの、他の言語用の既存のPOファイルのことです。追加のPOファイルを定義・処理したり、作業中のエントリーのコンテキストを表示するためのコマンドが存在します。

以下は、POモードで利用可能な、追加のPOファイルのコマンドです。

a

追加のPOファイルから、同じエントリーにたいする他の翻訳を探します(po-cycle-auxiliary)。

C-c C-a

追加のPOファイルを指定して、それに切り替えます(po-select-auxiliary)。

A

表示しているPOファイルを、追加のPOファイルとして定義します(po-consider-as-auxiliary)。

M-A

表示しているPOファイルを、追加のPOファイルのリストから削除します(po-ignore-as-auxiliary)。

Aコマンド(po-consider-as-auxiliary)は、現在のPOファイルを、追加のPO ファイルのリストに追加し、M-Aコマンド(po-ignore-as-auxiliaryは、リストから削除します。

aコマンド(po-cycle-auxiliary)は、すべての追加POファイルを一つずつ走査して、カレントエントリーと同じmsgidにたいする、他の言語に翻訳されたエントリーを検索するコマンドです。POファイルが見つかったら、そのPOファイルが現在のウィンドウに表示されます(そのウィンドウがもっとも前面に表示されます)。追加のPOファイルに作業中のPOファイルが含まれていない場合は、これらの処理を行う前に追加しておくとよいでしょう。このようにしておけば、aコマンドで検索された他言語のPOファイルがウィンドウに表示されても、aコマンドを繰り返し入力して、元のPOファイルに戻ることができるからです。

C-c C-aコマンド(po-select-auxiliary)は、翻訳者にたいして追加のPOファイルを補完付き入力で選択させて、そのPOファイルに切り替えるコマンドです。選択したPOファイルにカレントエントリーと同じmsgidがあった場合は、そのエントリーをカレントエントリーとします。同じエントリー存在しない場合には、カーソルは元の位置から変更されません。

この機能が完全に動作するためには、msgidが、同じ方法で正確に、正規化されて記述されている必要があります。たとえ文字列を記述する方法は異なっていてもmsgidに同じ文字列が設定されていれば問題はありませんが、違う文字列が記述されていると、POモードの追加POファイル関連のコマンドの動作が損なわれてしまいます。しかしほとんどのPOファイルのmsgidは、同じGNU gettextツールで書き込まれたものなので、実際には問題になることはないでしょう。

しかしソースファイルの文字列をマークしながら、POモードで一から作成したPOファイルは、異なる形式で正規化されています。そのために‘M-x normalize’コマンドをPOファイルに適用するのです。POモードと他のGNU gettextツール間の矛盾を解決するまでは、翻訳者は正規化の問題に留意してください。

8.4 翻訳compendiaの使用

compendium(要約)とは、多くのパッケージで繰り返し使用される翻訳を含んだ特別なPOファイルのことです。翻訳者はgettextツールを使って、新しいcompendiumを構築して、compendiumに含まれた翻訳から、エントリーをcompendium に追加したり、未翻訳エントリーの初期化、既存の翻訳済みエントリーの更新できます。

8.4.1 compendiaの作成

基本的に、すべてのPOファイルに含まれる翻訳済みエントリーだけを、有効なcompendiumとして定義できます。翻訳者が特別なcompendiaを所有したい場合があります。連結POファイル(concatenating PO files)とPOファイルからメッセージを抽出したサブセット(extracting a message subset from a PO file)という、2つのケースを考えてみましょう。

8.4.1.1 POファイルの連結

複数の有効なPOファイルを、1つのcompendiumファイルに連結するためには、‘msgcomm’か、‘msgcat’(推奨)を使用することができます:

msgcat -o compendium.po file1.po file2.po

デフォルトでは‘msgcat’は、同じ文字列にたいして異なる翻訳がある場合には、それらの翻訳を蓄積します。これらの複数の翻訳にはfuzzyマークが付与されるとともに、目立つように装飾されます。たとえば以下のような2つのファイルがあるとします。file1.poは以下のような内容です:

#: src/hello.c:200
#, c-format
msgid "Report bugs to <%s>.\n"
msgstr "Comunicar `bugs' a <%s>.\n"

そしてfile2.poです:

#: src/bye.c:100
#, c-format
msgid "Report bugs to <%s>.\n"
msgstr "Comunicar \"bugs\" a <%s>.\n"

これらにたいしてmsgcatを呼び出すと、以下のような結果になります:

#: src/hello.c:200 src/bye.c:100
#, fuzzy, c-format
msgid "Report bugs to <%s>.\n"
msgstr ""
"#-#-#-#-#  file1.po  #-#-#-#-#\n"
"Comunicar `bugs' a <%s>.\n"
"#-#-#-#-#  file2.po  #-#-#-#-#\n"
"Comunicar \"bugs\" a <%s>.\n"

“競合”は翻訳者が手動で解決する必要があります。彼女は最初のバージョンが適しているのか、それとも2番目のバージョンなのか(それとも新しい翻訳を提供する必要があるのか)を決定して、“マーカー行”を削除し、fuzzyマークをはずす必要があります。

最初に検索される翻訳済みのメッセージが常に最善の翻訳であることを翻訳者が知っている場合は、‘--use-first’スイッチを使用できます:

msgcat --use-first -o compendium.po file1.po file2.po

よいcompendium ファイルを作るには、fuzzyや未翻訳エントリーを含めてはいけません。入力ファイルがそのようなエントリーで“汚染”されている場合は、‘msgattrib --translated --no-fuzzy’を使って入力ファイルを前処理するか、結果ファイルを後処理しなければなりません。

8.4.1.2 POファイルからのメッセージサブセットの抽出

同じメッセージを何度も翻訳したいと思う人はいないでしょう。たとえば、あなたがgetopt.cのメッセージを含んだcompendiumファイルが欲しいと思うかもしれません。

既存のPOファイルから1つのcompendiumにメッセージのサブセット(例: getopt.cのすべてのメッセージ)を抽出する場合は、‘msggrep’を使用できます。

msggrep --location src/getopt.c -o compendium.po file.po

8.4.2 compendiaの使用

compendiumファイルを使用して、スクラッチから翻訳を初期化したり、既存の翻訳を更新できます。

8.4.2.1 新しい翻訳ファイルの初期化

まだ翻訳されたPOファイルが存在しないときは、“古い”翻訳済みファイルとして/dev/nullを使用できます。

msgmerge --compendium compendium.po -o file.po /dev/null file.pot

8.4.2.2 既存の翻訳ファイルの更新

compendiumファイルと既存のPOファイルを結合した後、それをマージしてPOTファイルを作成し、陳腐化したエントリーを削除します(これは任意です。ここでは‘msgattrib’が使用されています)。

msgcat --use-first -o update.po compendium1.po compendium2.po file.po
msgmerge update.po file.pot | msgattrib --no-obsolete > file.po

9 POファイルの操作

POファイルを手で扱うよりは、自動的な方法で取り扱うほうがよいときがあります。GNU gettextには、この目的のための完全なツールが含まれています。

2つのパッケージを1つのパッケージにマージするときには、元の2つのパッケージのPOTファイルが結合されたものが、マージされたパッケージのPOTファイルになります。したがってメンテナーは、翻訳された各言語ごとに、既存の2つの翻訳済みパッケージを1つの翻訳カタログにマージしなければなりません。これを行うには‘msgcat’を使うのが最善です。マージにより発生し得る競合を解決するのは、翻訳者の役目となります。

ある翻訳者が他の翻訳者から作業を引き継ぐときに、彼女がそのlocaleの異なるエンコーディングを使っている場合には、カタログの文字のエンコーディングを変換することになるでしょう。これを行うには‘msgconv’プログラムを使うのが最善です。

メンテナーが他のパッケージからタグ付けされたメッセージを取得するとき、彼はこのソースファイルの既存の翻訳も取り込む必要があります(翻訳者が同じ作業をしなくても済むように)。これを行うには‘msggrep’を使う方法と、そのソースファイルからPOTファイルを作成して‘msgmerge’を使う方法があります。

翻訳者がある翻訳カタログを特定の方言や正書法に適応させたいとき – たとえばSwitzerlandで記述されたGermanを、Germanyで記述されたGerman に適応させる場合など – 彼女はカタログの中のすべてのメッセージに適用できるテキストプロセッサーが必要にるでしょう。これを行うためのツールが、‘msgfilter’です。

msgfilterの他の使い方としては、POファイルが作成される元となったPOTファイルに近いものを生成することです。これは、‘msgfilter sed -e d | sed -e '/^# /d'’のようなフィルターコマンドにより行うことができます。オリジナルのPOTファイルには異なるコメントがあったり、plural messageの数も異なります。この理由により、利用可能ならオリジナルのPOTファイルを使うほうがよいことに注意してください。

翻訳者が翻訳をチェックしたいとき、たとえば正書法のルールや非対話型のスペルチェッカーにしたがってチェックをしたいときは、‘msgexec’を使うことができます。

サードパーティー製のツールによりPO、またはPOTファイルを作成するとき、重複が無視されるときがあります。しかしGNU gettextツールは、同じファイル中に同じドメインで重複したmsgidがある場合にはエラーとなります。重複をマージするためには、‘msguniq’を使うことができます。

複数のファイル間での重複を維持(または破棄)するための、より一般的なツールとしては‘msgcomm’があります。

翻訳カタログが完全に翻訳されているかをチェックするには、‘msgcmp’を使うことができます。

翻訳カタログからfuzzyや未翻訳のメッセージだけを選択・抽出するためには、‘msgattrib’を使うことができます。

Englishの翻訳カタログを準備するための最初のステップとしては、‘msgen’が便利です。これは、各メッセージのmsgidをmsgstrにコピーします。

そして最後に、これらの様々なアプリケーションでも十分でない場合には、POファイルを取り扱う特殊なプログラムを記述するために使用できる、‘libgettextpo’ライブラリーが提供されています。

9.1 msgcatプログラムの呼び出し