1.3. 典型的な翻訳作業の例: 保守文書の更新

定常的に人手が必要で、かつ比較的量の少ない翻訳作業の一つに、 保守文書の更新作業と呼ばれるものがあります。 文書の翻訳や扱いに慣れるのに最適ですので、 はじめて作業をするのであれば、これから手を付けると良いと思います。

ここでお話する更新作業は、翻訳作業のうちの一つに過ぎませんし、 これ以外の翻訳作業や、翻訳を伴わない作業ももちろんあります。 英語は自信がない、という方は、次の章をご覧ください。

1.3.1. 更新作業とは

FreeBSD 日本語ドキュメンテーションプロジェクトでは、 FreeBSD FAQ 日本語版FreeBSD ハンドブック日本語版FreeBSD チュートリアル日本語版に加えて、 www.FreeBSD.org 日本語版を翻訳・保守管理しています。 もちろん、これらには元となる英語版が存在しますが、 それらには新しい話題が追加されたり、誤りの修正などで、 定期的に更新が行なわれます。

英語版が更新されれば、日本語版はそれに追随して更新しなければなりません。 更新作業とは、このように英語版の変更点を、日本語版に反映させる作業のことです。

以下に、具体的な作業の工程を概説します。

1.3.2. 文書の取得

更新作業が必要な文書は、 同期情報 で探すことができます。この中から遅れている文書を選び、取得します。

文書は、次の三つを取得してください。

  1. 更新された英語版ファイル

  2. 古くなった日本語版ファイル

  3. 差分ファイル[1]

「差分」とは聞き慣れない言葉かも知れませんが、 「英語版の変更点だけを抜き出したもの」です。 文書にはサイズが大きなものもあるため、 変更された部分の把握するのが困難な場合があります。 差分があれば、どの部分に変更があったのかひと目で分かりますし、 どれくらい作業すれば良いのかの目安にもなります。

では実際に、FreeBSD ハンドブック日本語版の文書を更新する例をあげて、 手順を追ってみましょう。

  1. まず、WWW ブラウザを使って、同期情報のページにアクセスします。 その中にある、FreeBSD ハンドブック日本語版の同期情報へのリンクを探します。

    Figure 1-1. FreeBSD ハンドブック日本語版の同期情報へのリンク

  2. 次に、そのリンクから FreeBSD ハンドブック日本語版の同期情報のページへ移動します。

    Figure 1-2. FreeBSD ハンドブック日本語版同期情報のページ

  3. このページから、更新作業を行なう文書を選択します。 この表には、文書のファイル名、 日本語版・英語版それぞれのリビジョン番号、 最新版との差分の量という、三種類の情報が書かれています。

    Figure 1-3. 同期していない文書リストの読み方

    文書のファイル名

    文書のファイル名です。これは、 基点となるディレクトリからの相対表示です。

    ファイル名は、CVS リポジトリ[2]へリンクされています。

    文書のリビジョン番号

    リビジョン(revision)とは、 更新される度にカウントされる番号のことです。 通常、リビジョンは 1.1 からスタートし、 1.2, 1.3, 1.4,... と、更新の度に増加します。

    ここで注意して欲しいのですが、 1.9 の次は 1.10 になります。 したがって、小数点表記の数字として比較してしまうと、 1.10 より 1.9 の方が新しいことになってしまいます。 ドットで分けられた数値を、左から順に比較してください。 つまり、2.11.1 より新しく、 1.101.9 より新しく、 1.1501.23 より新しい、ということになります。

    Note

    このリビジョン番号は、 cvs(1) や、そのベースとなっている rcs(1) によって管理されています。 リビジョン番号の詳しい形式については、それらの マニュアルページを参照してください。 また、rcs と cvs については、PSD-13, PSD-28 に詳しくまとめられています。FreeBSD 基本配布に含まれていますので、詳細については /usr/share/doc/psd/ 以下の該当文書を参照すると良いでしょう。

    それぞれ、そのリビジョン番号の文書にリンクされていますので、 更新する文書は、このリンクをたどって取得してください。

    差分情報

    表示は、日本語版の元となった古い英語版と、 最新の英語版との差分量を表しています。

    この例では、元となったのが 1.22 で、 最新版が 1.24 です。その後ろの (+59, -5, total 94) というのは、 「追加された行が 59、削除された行が 5、 差分全体が 94 行」であることを示します。

    この差分量が大きければ大きいほど、 必要となる作業は多くなります。 特に、total が 100 を超える文書は作業に時間がかかりますので、 なるべく小さなものを選ぶと良いでしょう。

    差分量の表示部分は、 実際の差分ファイルにリンクされています。

Important

三つの文書を取得する際、 英語版と日本語版のファイル名が同じであるため、 WWW ブラウザによっては、取得したファイルを上書きしてしまうことがあります。

ファイル名は、リビジョン番号を使って chapter.sgml.1.22 のようにしたり、英語版なら chapter.sgml.en のようにして管理すると良いでしょう。

1.3.3. 翻訳

文書が揃ったら、翻訳を行ないます。

1.3.3.1. 翻訳のルール

翻訳は、「ですます調」で、「句読点は半角のカンマとピリオド」、 「文字コードは EUC-JP」に統一してください。

ここで翻訳するのは、英文だけです。 para など、<> で括られた中身の部分や、 &copy; のように、&xxx; という形で表記されている部分は日本語に翻訳せず、 基本的にそのままにしておいてください。

さらに注意が必要なことが一つあります。 文書冒頭あたりにある、次のような行を探してください。

<!-- Original revision: 1.22 -->

これは、この翻訳文書が英語版 1.22 に基づいたものであることを示しています。 先ほどの同期情報の例で言うと、翻訳によって 1.24 を原文にした翻訳に変わることになりますから、 この部分を次のように書き換えます。

<!-- Original revision: 1.24 -->

翻訳文書が提出された時、この表記が変更されないままだと、 原文との対応がわからなくなってしまい、チェックに支障をきたすことがあります。 ですから、翻訳の際に必ず行なうようにお願いします。

1.3.3.2. 難しい文章に出会ったら

翻訳を行なっている途中で、どうしても意味が分からなかったり、 訳文はできたけど不安だ、という文章がある[3]と思います。そんな時は、一人で悩むより doc-jp ML で相談してください。

また、訳文の不安なものはリストアップしておき、 一緒に提出すると効果的です。 訳文のチェックは大変な作業なので、 どこを重点的にチェックして欲しいのかが書かれていれば、 作業の助けとすることができます。 訳文の品質を向上させるためにも、ぜひ行なってください。

1.3.4. チェック

翻訳が終了したら、まずは自分でチェックを行ないます。 チェックは、翻訳の項で解説したような文体、 句読点のルールにちゃんと沿っているか、 文字コードは適切か、リビジョン番号を書き換えているか、 というような点について行ないます。

1.3.5. 提出

ここまでで作成された成果物は、 旧版の日本語文書を元に変更部分を反映させた新しい日本語文書です。 翻訳作業が終わりチェックを行なったら、成果物を提出します。

成果物は、「旧版日本語文書からの差分」であるのがベスト [4]です。 差分を作成するには、diff(1) を使って

% diff -u (旧版ファイル名) (成果物のファイル名) > (差分を保存するファイル名)

としてください。

Note Windows や DOS など、diff(1) が標準で存在しない場合
 

diff(1) を探してきましょう :-)。 GNU fileutils を探せばあると思います…というのは不親切ですよね。 佐藤は詳しくないので、win32 のバイナリがあるとか、 参考になるサイトがあれば、どなたか教えてください。

差分が作成できたら、email に添付して doc-jp ML に送付します。 その時、どの文書に対する、 どのリビジョンの変更なのかを subject, もしくは本文に明記してください。 差分であれば、提出形式は添付に限らず、uuencode(1) されたものや、gzip(1) で圧縮されたものでも[5]構いません。

1.3.6. 成果物の反映

提出された成果物は、まず doc-jp ML で査読されます。 表現のおかしい部分などあれば、ここで修正を行なって 再度提出を行ないます。 提出が終わったら、作業はほぼ終了です。

成果物は、commit[6]という作業によって反映されます。 commit 作業は、committer の方々が行ないますので、 提出が終わったら、 その作業が行なわれるのを待つことになります。

通常、二〜三日もあれば commit されますが、 committer の方々が忙しかったりすると、 数日〜数週間かかる場合もあります。 提出の email を見落としていたりする可能性もありますので、 提出したのに反映されない場合には、 遠慮なく催促の email を doc-jp ML に出しましょう。

Notes

[1]

二つのファイルの差を表示するコマンド、 diff(1) で作成されるものです。 diff(1) コマンドは ほぼすべての UNIX 系の OS で標準コマンドとして利用可能なだけでなく、 他のほとんどのプラットフォームに移植されています。 作業する際に良く利用するツールですので、 インストールすることをおすすめします。

[2]

FreeBSD に含まれる配布物は、ほとんどすべてが cvs(1) によって管理されています。 CVS リポジトリとは、cvs(1) が作成するデータベースのことです。 そこには配布物のファイルが格納されています。 詳細は、cvs(1) のマニュアルページを参照してください。

同期情報のページを利用している限り、 CVS リポジトリを直接調べる必要はほとんどありませんので、 最初のうちは特に気にしないで構いません。

[3]

…というか、 少なくとも佐藤はそんなの日常茶飯事 :-) で、今まで全部ばっちりだったなんて文書はありません。

[4]

別にこれでないとダメ、というわけでもないのですが、 全文では分量が大きくなりますし、 査読や反映させるための負担も増してしまいます。 やむを得ない理由がなければ、なるべく差分でお願いします。

[5]

あんまりマイナーな形式を選ぶと、 みんなが読めなくて困るかも知れません。 ひと昔前は gzip(1)+uuencode(1) で本文に入れるのが主流でしたが、 現在は差分を gzip(1) して、 BASE64 でエンコードした添付形式が多いようです。

[6]

commit とは、cvs(1) の操作コマンドの一つです。 この操作コマンドを使うことで、 FreeBSD のソースツリーに変更が反映されます。 commit を行なうには権限が必要で、 その権限を持っている人を committer と呼びます。