5 Po4a でドキュメント翻訳の保守を楽にしよう

小林儀 匡

翻訳の保守は新規翻訳よりも手間のかかる作業になりがちです。 しかし、 これを怠ると原文との乖離は大きくなり、 折角の翻 訳も価値が下がっていきます。 Debian で開発されている Po4a は、 プレーンテキスト、 XML、 HTML、 LaTeX、 nroff (man) など様々な形式のドキュメント翻訳を PO という形式で管理し、 保守性を上げるツールです。 今回はこの Po4a の使い方と、 新たなドキュメント形式を PO で管理するために知っておくべき内部構造について説明し ます。

5.1 はじめに 〜地味で地道なドキュメント翻訳保守作業〜

長期的に見れば、 ドキュメント翻訳者の作業で最も大変で最も大切なのは、 ドキュメントの翻訳作業ではなく翻訳の保守作業で しょう。 何週間、 何ヶ月もの作業の末、 1 万行を超える長いドキュメントの翻訳作業を終えたとしても、 原文が変わり続ける限 り、 保守をしなければ翻訳の価値は下がっていきます。

保守は地味で地道な作業です。 原文に対しては、 次のような変更が発生します。

• 訳文には影響のない typo の修正
• 記述の追加・変更・削除 (修正を含む)
• パラグラフの位置の変更
• マークアップの変更 (マークアップ言語で書かれたドキュメントの場合)

同時に、 次のような非本質的な変更も頻繁に発生します。

• パラグラフのインデントの変更
• パラグラフの改行位置の変更 (主に語句の挿入・変更・削除に起因する)

こういった様々な種類の変更は大抵は混ざっています。 ドキュメントの翻訳者は通常、 diffで差分を眺めて変更を把握し、 それを翻訳に反映させます。 差分を読んで変更を把握する能力によって、 翻訳に反映させる作業が楽にも大変にもなり ます。

このようなドキュメント翻訳の保守作業に必要な労力を和らげてくれるのが Po4a です。 Po4a は、 様々な形式のドキュメン ト翻訳を PO という形式で一括して管理し、 保守性を上げるツールです。 以下では、 まず PO というファイ ル形式が、 翻訳にとってどのように便利なのかを説明し、 その上で Po4a がどのようなツールなのか説明し ます。

5.2 PO

PO は、 プログラムのメッセージの翻訳のために作られたファイル形式です。 ここではその書式や編集用のツールについて見て いきましょう。

5.2.1 PO の基本的な書式

まずは、 PO の基本的な書式を説明します。

PO には、 原文と訳文の対からなるエントリが空行区切りで多数収められています。 最初に、 簡単なエントリの例を紹介し ます。

一目瞭然ですが、 msgidから始まる一連の行、 msgstrから始まる一連の行の、 "で囲まれた部分は、 それぞれ原文と訳文 です。

「#」 で始まる行は基本的にすべてコメントです。 特に「#:」 で始まる行は、 原文を抽出した位置を示す参照用の行です。 こ れはxgettextがメッセージを抽出して POT を生成するときに設定します。 翻訳者は、 msgidを見ても理解できない場合、 こ の参照コメントをもとにしてソースコードを眺めることができます。

「#:」 以外にも、 様々な種類のコメントがあります。 そのようなコメントを含んだエントリの例を紹介し ます。

「#.」 で始まる行は、 原文のメッセージと一緒にソースコードから抽出されたコメントです。 主に、 メッセージの翻訳に注意 が必要な場合やメッセージが翻訳しにくい場合に、 開発者から翻訳者への説明に使われます。 これもxgettextがメッセージ抽 出時に設定します。

「#,」 で始まる行はフラグです。 最もよく使われるフラグは fuzzy というフラグでしょう。 これについては後述します。 これ は 様 々な ツ ー ル が 設 定 し ま す 。

それ以外の、 「#」 の後に何の記号もない行は、 翻訳者が翻訳作業時に勝手に追加したコメントです。 各エントリにはこのよう な翻訳者コメントを自由自在につけることができます。

このようなコメント情報は、 プログラムのソースコードに書くコメントと同様、 人間の作業にのみ必要となるものなので、 MO に変換するとき にすべて削除されます^*1 。

5.2.2 fuzzy エントリ

msgmergeが古い PO に新しい POT をマージする際、 既に翻訳されているエントリのmsgidに似たmsgidを持つエントリが 追加されることがあります。 例えば、 エントリ A のmsgidに似たmsgidを持つエントリ A’ が追加されるとします。 このと き、 msgmerge は A をベースとして A’ を翻訳できると判断し、 A’ の msgstr に A の msgstr の内容を設定し た上で、 A’ に fuzzy フラグをつけます。 このようにして作られるエントリが、 次のような fuzzy エントリ です。

しかしこれだけだと、 翻訳者には、 msgidがどう変化したのか分かりません。 そこで GNU gettext のバージョン 0.16 から 導入されたのが、 次のような、 「#|」 で始まるコメントです。

「#|」 で始まるコメントは、 以前のmsgidです。 msgmergeに--previousを指定した場合に設定されます。 このコメント を使えば、 以前のmsgidと現在のmsgidを比較できるので、 どのような変更をmsgstrに加えれば翻訳を現在のmsgidに対 応できるのかが簡単に分かります。 PO の保守性を上げる仕組みと言えます。 msgmergeに--previousが指定されていない場 合は指定しておくとよいでしょう。

5.2.3 ヘッダ

翻訳を扱う際、 翻訳者やその連絡先、 原文の問題の連絡先、 翻訳の更新日時、 文字セットなどは重要なメタ情報です。 PO で は、 最初のエントリをヘッダとして使用し、 そのエントリのmsgstrにこれらのメタ情報を含めることになっています。 ヘッダ のmsgidは空文字列にすると決まっています。

また、 著作権情報など、 書式が曖昧な情報や長い情報は、 ヘッダのコメント (つまりファイルの冒頭) に書くことになってい ます。

以下は、 aptitude の ja.po の例です。

なお、 ここでは省略しましたが、 筆者は、 メッセージカタログ内での用語統一を容易にするため、 aptitude や Subversion な ど大規模な PO では、 ヘッダのコメントに対訳表を含めています。

5.2.4 その他の書式

ここまでで、 PO のエントリの書式についてざっと見ました。

PO のエントリについては、 msgid と msgstr から成るもの以外にも、 複数形への対応として msgid、 msgid_plural、 msgstr[n] から成るものがあります。 詳しくは GNU gettext のドキュメン ト^*2 の 『3 The Format of PO Files』 を参照してください。

5.2.5 PO 編集ツール

PO で翻訳作業を行うには PO 編集ツールが便利です。 PO はテキストなのでどんなテキストエディタでも編集できますが、 翻 訳に含まれる「"」 や「\」 を手でエスケープするのは厄介です。 そのような機械的な処理は、 PO に特化した PO 編集ツールに 任せるのがよいでしょう。 また、 PO 編集ツールには翻訳支援機能を持つものもあるので、 作業効率も上がるはず です。

PO 編集ツールとしてよく知られているのは、 Emacs の PO 専用メジャーモードである po-mode、 KDE の PO 編集スイー トである KBabel、 GNOME の PO エディタである Gtranslator、 そして poedit です。

ここでは、 筆者が慣れている po-mode について、 筆者がよく使う操作だけざっと説明します。 説明中で何度も登場する「選 択エントリ」 とは「現在カーソルがあるエントリ」 の意味です。

まず、 エントリ間の移動には以下のようなキー操作が使えます。

n

次のエントリに移動します。

p

前のエントリに移動します。

t

次の既訳エントリに移動します。

T

前の既訳エントリに移動します。

f

次の fuzzy エントリに移動します。

F

前の fuzzy エントリに移動します。

u

次の未訳エントリに移動します。

U

前の未訳エントリに移動します。

o

次の obsolete エントリに移動します。

O

前の obsolete エントリに移動します。

m

選択エントリの位置をスタックに push します。

r

スタックから pop して得られたエントリに移動します。

また選択エントリの操作には以下のようなキー操作が使えます。

RET

編集用バッファを開いて、 選択エントリのmsgstrを編集します。

#

編集用バッファを開いて、 選択エントリの翻訳者コメントを編集します。

k

選択エントリのmsgstrをカット (kill) します。

K

選択エントリの翻訳者コメントをカット (kill) します。

w

選択エントリのmsgstrをコピーします。

W

選択エントリの翻訳者コメントをコピーします。

y

選択エントリのmsgstrにペースト (yank) します。

Y

選択エントリの翻訳者コメントにペースト (yank) します。

TAB

選択エントリの fuzzy フラグを取り除きます。

DEL

選択エントリが既訳の場合は fuzzy フラグをつけます。 未訳または fuzzy の場合は obsolete にします。 obsolete の場合は削除します。

C-j

選択エントリのmsgidの内容をmsgstrにコピーします。

s

選択エントリの参照コメントをもとにソースコードの該当行を表示します。 参照コメントに複数の位置が記述 されている場合は、 順番に表示します。

編集用バッファでは通常の Emacs の編集操作ができます。 特殊な操作は以下のとおりです。

C-c C-c

編集用バッファの内容を msgstr または翻訳者コメントの内容として設定し、 バッファを閉じま す^*3 。

C-c C-k

編集用バッファの内容を破棄してバッファを閉じます。

最後に、 メインバッファでの PO 全体に関わる操作は以下のとおりです。

_

行った変更を取り消します。

?, h

ヘルプを表示します。

V

msgfmtに--check (-c) をつけて実行し、 PO に問題点がないか確認した上で保存します。 例えば、 msgidが 改行記号で終わっているのにmsgstrが改行記号で終わっていない場合、 それが報告されます。

以上の簡単な説明から分かると思いますが、 po-mode は移動や編集がしやすく、 非常に便利です。

ただ、 po-mode には今のところ翻訳メモリのような機能はありません。 KBabel や Gtranslator は翻訳メモリを備えている ので、 翻訳メモリに興味のあるかたはこれらを試してみるのもよいでしょう。

5.2.6 GNU gettext ツール群

翻訳作業には PO 編集ツールを使うことになるでしょうが、 一方で GNU gettext が提供する、 PO や POT に対してコマンド ラインから自動処理できるツール群も、 知っておくと便利です。 以下でざっと説明します。

msgattrib

エントリの状態に応じた一括処理をします。 例えば、 「fuzzy エントリのみにする」 、 「fuzzy エントリか ら fuzzy フラグを取り除く」 といったことが可能です。

msgcat

複数の PO を繋げます。

msgcmp

PO と POT が含むmsgidセットを比較します。

msgcomm

複数の PO に含まれる共通のmsgidを抽出します。

msgconv

PO の文字セットを変換します。

msgen

英語の PO を作成します。 入力ファイルの未訳のエントリのmsgstrに、 msgidと同じ文字列を設定します。

msgexec

PO に含まれるすべての翻訳に対してコマンドを実行します。

msgfilter

PO に含まれるすべての翻訳に対して共通の処理をします。

msgfmt

PO をコンパイルして MO に変換します。

msggrep

パターンにマッチしたエントリを PO から抽出します。

msginit

PO を初期化します。

msgmerge

PO に POT をマージします。

msgunfmt

MO から PO に逆コンパイルします。

msguniq

PO に含まれる重複したmsgidを 1 つにまとめます。

xgettext

ソースコードからmsgidを抽出して POT を生成します。

開発者が主に使うのはxgettextとmsgmerge、 msgfmtですが、 他のツールも使いこなせるようになっておくと便利です。 使い方は各ツールのマニュアルページを参照してください。

5.2.7 まとめ

PO はプログラム翻訳のために作られたファイル形式で、 参照コメントのような翻訳に有用な情報や、 fuzzy エントリのような 翻訳作業・保守作業の効率を上げるための仕組みを含んでいることを説明しました。 また、 PO という書式に特化した編集ツー ルについても説明しました。

5.3 ドキュメント翻訳で PO を使うという考え方

プログラム翻訳のために生み出された PO は、 翻訳者にとって翻訳と保守の両方の作業をしやすい環境を提供する存在となり ました。 その理由としては以下のようなものが考えられます。

• PO 自体に翻訳と保守を支援するための仕組みがある上、 翻訳支援機能を持つ PO 編集ツールも存在する。
• メッセージの管理はツールがやってくれるので、 人間は翻訳の管理に集中していればよい。
  • メッセージがソースコードのどこにあるかが翻訳者にとって重要でないので、 メッセージがソースコード 内で移動しても翻訳者は気にする必要がない。
  • msgmerge で PO を更新すると、 どのエントリの翻訳を更新すべきか瞬時に分かり、 PO 編集ツールでそ のエントリへ簡単に移動できる。

一方でドキュメント翻訳については、 通常は原文をそのままコピーして翻訳作業を開始するため、 翻訳以外の部分 (インデン ト、 ドキュメント内での位置など) に変更があった場合、 その影響を翻訳者が受けます。 プログラム翻訳と比べて分量が多いの に保守性が低いので、 結果として翻訳者への負担は非常に大きくなります。 この状況は、 翻訳者にとって大きな悩みの種で した。

そこで生まれたのが、 ドキュメント翻訳に対しても PO を使おうという考え方です。 具体的には、 ドキュ メントの各ブロックをエントリとした PO を作り、 ドキュメントと PO とを相互変換できるようにするこ とで、 翻訳者が PO での翻訳管理に集中できるようにします。 以下のツールがそのような思想で作られてい ます。

Po4a

Debian で開発されている^*4 。 対象とするドキュメント形式は、 プレーンテキスト、 XML、 HTML、 LaTeX、 nroff (man)、 Pod など多数 で、 Perl で書かれたモジュールおよびプログラムの集合として実装されている。 Debian パッケージはpo4a。

poxml

KDE で、 KDE SDK モジュールの 1 つのコンポーネントとして開発されている。 対象とするドキュメン ト形式は DocBook XML で、 C++ で実装された、 po2xml、 xml2pot などの実行可能プログラムから成る。 Debian パッケージはpoxml。

xml2po

GNOME で gnome-doc-utils の 1 つのユーティリティとして開発されている。 対象とするドキュメント形 式は DocBook XML である。 Python で実装されたシンプルな 1 つのファイルから成るので、 手軽にドキュメ ントのビルドに使用できる。 Debian ではgnome-doc-utilsパッケージに含まれる。

poxml や xml2po が DocBook XML のみを扱うツールであるのに対し、 Po4a が様々な形式をサポートしているのは、 おそ らく GNOME や KDE と Debian の立場の違いを反映しているのでしょう。 GNOME や KDE はプロジェクト内でドキュメン ト形式を DocBook XML に統一できますが、 ディストリビュータである Debian では、 様々なソフトウェアの様々なドキュメ ントに対応する必要があるのです。

以降のセクションでは、 ドキュメント翻訳に PO を使用する 3 つのツールのうち、 唯一複数のドキュメント形式をサポート し て い る Po4a について見ていきます。

5.4 Po4a の基本

Po4a というソフトウェア名は、 「po for anything」 から来ています。 名前からも分かるように、 最初から様々なドキュメント 形式の翻訳を PO で管理することを目的としており、 そのために入力形式として複数の形式を扱うことを想定した作りとなっ ています。

例えば、 以下のような形式が現在サポートされています。

KernelHelp

カーネル設定ヘルプのドキュメント形式です。

nroff

Unix の伝統あるマニュアルページの形式です。 BSD マニュアルページで使用されている mdoc 形式もサポー トされています。 初心者が読み書きしにくい形式ですが、 Po4a でサポートされたので、 インラインのマーク アップだけ分かれば (原文の真似をすれば) 翻訳できます。

POD

Perl 関連のドキュメントに使われる形式です。 ソースコードの横にコメントとして書き込まれたドキュメント は翻訳しにくいですが、 それを PO として抽出し、 翻訳しやすくします。

SGML

最近では XML のほうが主流ですが、 一昔前のドキュメント形式の主流です。 現在サポートされている DTD は DebianDoc-SGML と DocBook SGML のものです。

TeX/LaTeX

著名な組版ソフトウェア LATEXの形式です。

GNU Texinfo

GNU のドキュメントに使用される形式です。

XML

最近よく使われるドキュメント形式です。 現在サポートされている DTD は Dia、 DocBook XML、 Guide XML、 XHTML のものです。

サポートされている形式の一覧は、 po4a-gettextize、 po4a-translate、 po4a-updatepoなどのコマンドに--help-formatオプションを 与えると表示できます^*5 。 コマンドに--format (-f) などを与えてドキュメント形式を指定する場合、 この一覧に載っている名前を使用してくだ さい。

5.5 Po4a の使い方

5.5.1 導入 (1): 原文ドキュメントファイルから POT を生成する

Po4a を使ってドキュメントの翻訳をする場合、 最初にすべきことは、 原文のドキュメントファイルから POT を生成すること です。 POT の生成にはpo4a-gettextizeコマンドを使用します。 -fオプションの引数にドキュメントファイルの形式を、 -m オプションの引数に原文ドキュメントファイル (マスタードキュメント) の名前を、 -pオプションの引数に出力する POT の ファイル名を与えて、 コマンドを実行します。 -Mオプションの引数で、 原文ドキュメントファイルの文字セットを指定するこ とも可能です。

特に問題がない場合はすんなりとコマンドの実行が終了し、 POT が生成されます。 ドキュメントの構造に問題がある場合 (例えば XML においてタグがきちんと閉じられていない場合) はエラーになります。

POT が生成されたら、 翻訳作業はプログラム翻訳の場合と同じです。 POT をコピーして PO を作成し、 ヘッダを適切に設 定した上で翻訳作業を始めましょう。

例 次の例では、 hoge.en.htmlという XHTML ドキュメントからhoge.potを生成しています。

hoge.en.html (入力):

コマンドライン:

hoge.pot (出力):

5.5.2 導入 (2): 原文・翻訳ドキュメントファイルから PO を生成する

原文と同じ形式で翻訳したドキュメントが既にあり、 それを Po4a 用の PO に移行したい場合にも、 po4a-gettextizeが使え ます。 「POT をコピーして PO を作った上で、 翻訳ドキュメントの各ブロックをコピー ・アンド・ペーストで PO の各エント リに埋め込む」 という、 間違いなくうんざりする作業は不要です。

ただしこの場合、 どの原文がどの訳文に対応するかを Po4a が把握する必要があるので、 原文ドキュメントファイルと翻訳ド キュメントファイルが同じ構造であることが前提になります。 「同じ構造」 とは、 Po4a が切り分ける単位、 つまりブロックのレ ベルで見たときに、 対応する要素が同じ順序で並んでいる、 という意味です。 もし翻訳側でブロックの追加や削除が行われてい たら、 変換はエラーで終わるでしょう。 一部のブロックの順序が入れ替わっている場合、 変換は見た目は無事に終 わるかもしれませんが、 入れ替わったブロックの msgid と msgstr の対応関係はおかしくなっているはず です。

訳注や翻訳者情報を別個のブロックとして翻訳ドキュメントに追加している場合、 それは一旦取り除いてください。 Po4a で は、 PO から翻訳ドキュメントを生成する際に、 原文にはない要素を追加する方法が提供されています。 方法については後述し ます。

原文ドキュメントファイルと翻訳ドキュメントファイルが同じ構造であれば、 po4a-gettextizeを用いた変換は成功するは ずです。 -fオプションの引数にドキュメントファイルの形式を、 POT を生成する場合の一連のオプションに加えて、 -lオプ ションの引数に翻訳ドキュメントファイルの名前を与えてコマンドを実行します。 -Lオプションの引数で、 翻訳ドキュメント ファイルの文字セットを指定することも可能です。

変換に成功すると、 すべてのエントリに fuzzy フラグが設定された PO が生成されます。 すべてのエントリに fuzzy フラグ が設定されるのは、 「ざっとでもいいので、 ユーザには変換後にすべてのエントリの原文と訳文を確認してほしい」 という開発 者の意図を反映したものですユーザが自由に編集できる普通のドキュメントに少し制限を与えて Po4a の管理下に置 く^*6 際に は 、 何 か し ら の 問 題 が 発 生 し て い る 可 能 性 が あ る の で す 。

例 以下では、 先程のhoge.en.htmlに対応する日本語訳hoge.ja.htmlを PO に変換することを試みます。

まずは、 とりあえずpo4a-gettextizeを実行してみました。

hoge.ja.html (入力):

コマンドライン:

訳注を独立したパラグラフにしたために PO への変換が失敗したと考え、 訳注の行を削ってもう一度po4a-gettextizeを 実行してみます。 入力ファイルの内容は省略します。

コマンドライン:

なんだか変なエラーが出てしまっています。 どうも、 titleとh1の原文がともに「Test file」 なのに、 一方の訳は「テスト ファイル」 で、 他方の訳が「テスト用のファイル」 となっていることに原因があるようです。 そこで、 両方の訳を統一して po4a-gettextizeにかけると、 変換に成功します。

hoge.ja.html (入力):

コマンドライン:

ja.po (出力):

5.5.3 PO と原文ドキュメントファイルから翻訳ドキュメントファイルを生成する

po4a-translate

5.5.4 原文ドキュメントファイルの更新を PO に反映させる

po4a-updatepo

5.5.5 PO と翻訳ドキュメントファイルを一括更新する

po4a

5.5.6 原文にない要素を翻訳ドキュメントファイルに挿入する

5.6 Po4a の内部構造

5.6.1 TransTractor::parse()

第 44 回東京エリア Debian 勉強会 2008 年 9 月
____________________________________________________________________________________________