matsuand です。ご返信ありがとうございます。 長南さんからのご指摘については、 不明な点もあり、疑問に思う点もあり、1 つのメールだけで ご説明することが難しいので、できるだけ焦点を絞って、 そして別観点は別メール立てしてご説明しようかと思います。 長南さん、 >> いろいろ、過去メールを拝見したり、ガイドページを拝見したりして >> 理解を深めています。その中で po4a を利用すると "draft" ファイルが >> 生成できないためレビューに支障がある、といった問題指摘を拝見 >> しました。 > > その情報はどこにありましたか。 Linux JM Guide、翻訳更新方法ページ http://linuxjm.osdn.jp/guide/translation_update.html そのページの「po4a 移行後の課題」の節に 「ja.po を投稿してもレビューできない。」 「できあがった draft でレビューする必要がある。」 とあるのを指しています。 そして本メールは、以下のご指摘部分のみについて考えます。 > po4a を使用する場合は、PO ファイルが原稿なのですから、原則として > 古い形式の draft ファイルは必要ありません。マニュアルの作成過程で使われ > ないのです。レビューの便宜ということなら、投稿に PO ファイルだけでなく、 > 原文、訳文の roff ファイルを付けた方が、見やすいという点で合理的です。 それでも良いと考えることができると思います。 ただし疑問が沸きます。 まず後段のご指摘からですが、レビューの便宜として PO ファイルに加えて 原文、訳文の roff ファイルを見る、というのは、レビューアーとしては 勘弁してほしい、となると思います。原文ファイルの記述箇所と、 訳文の記述箇所という２ファイルを比べっこするということです。 draft ファイル方式なら roff ファイル内の部分的な記述要素が 原文1、訳文1、原文2、訳文2 と並んでいて、 (原文1、原文2 は roff 内にてコメント化されています) それを１ファイルだけで確認できるわけですから楽です。 これに関連して、前述の Linux JM Guide 内の「作業メールのフォーマット」 では、レビュー依頼のために roff 原文を送信するように書かれています。 これは draft 段階では draft ファイルを送信することを意味している ように解釈しており、長南さんのご説明からすると、そのような作業 メール送信による運用(過去のもの?)とは、相容れない話になります。 (メール送信で draft ファイル、原文、訳文 roff ファイルを示す？) ＃ 「作業メールのフォーマット」に示されている運用は、たぶん ＃ 行われていないのではと想像しており、運用方法はどうなのか、 ＃ どうするのか、といった話に発展してくかと思います。 ＃ ただし本メールではそこまで議論は膨らませないつもりです。 さて、本メールにて指摘させていただきたい重要なポイントを 以下に示します。ひとことで言って PO ファイルただ１つだけでは レビューはできない、とご指摘させていただきます。 これは PO ファイルの生成成り立ち上、やむを得ない事情を含んでいます。 だから draft ファイルは（１ファイルだけでレビューを行う運用とする のであれば）その存在が欠かせないという持論につながります。 以下ご説明します。 単純な roff ファイルの po4a 処理によって生成される PO ファイル であれば問題が発生しにくいですが、一般論として PO ファイルは 元のファイル (今の場合 roff ファイル) の記述順番どおりに msgid、msgstr （原文翻訳対象に対する翻訳指定箇所）が並ぶ保証 はありません。PO ファイルだけをレビュー対象とした場合には、 これだけでもレビューアーは記述順番どおりの検証ができません。 さらに申し上げると、確か元木さんが過去メールで述べておられた と思いますが、元木さん作の po4a 処理では、複数ある原文 roff に対して ja.po というただ一つのファイルに集約した po4a 処理 をなさっているかと思います。これについてまさに元木さんが 過去メール内に的を射た利点欠点をまとめておられました。 ja.po １つにまとめると複数 PO ファイル内の同一記述箇所は msgid、msgstr にまとめられるという PO 処理の原則があります。 もう記述順番はめちゃくちゃです。 これは元roffファイルが１つであっても起こりうる状況です。 po ファイルの成り立ちに関しての説明は、 おわかりいただけるでしょうか。 レビュー運用に深くかかわる話です。 私は draft ファイルは、レビューには重宝すると思います。 ただし本当は git の（osdn サイト内の) pull request などを 通じて、最小限のレビュー依頼を挙げて、あとはレビューアーが git リポジトリ内の各ファイルを参照する、という形になるのが 自然かなと思っていますが、その際にも draft ファイルは ないと困ると思います。 ちなみに私が構築中の jmtemplate 内では「わざわざ」draft ファイルを作り出しています。従来の記法に合わせて、そうしている のであって、もうちょっと工夫すれば、HTML ファイル化したり tex ファイル化することだってできます。 (そうするつもりはまったくありませんが。) 元木さん方式、つまり ja.po 一本化方式の際のレビューは 相当やっかいなはずです。１つの man ページの仕上がりをレビュー したいのに、ja.po ファイルのどこにその記述があるのか、 全体としてどのような記述の流れになるのか、ja.po １つでは 相当、レビューアーに苦労を強いるからです。 po4a 処理上、そのように 1 本化したとしても、本 jmtemplate で考え出した draft ファイルは最終成果物から読み直して draft ファイルの自動生成を行うものなので、ja.po として 一本化される前の、大本の roff ファイル分だけ draft ファイルは生成されることになります。 (ちなみにまだその仕組みは構築していませんが、考え方として はそうであり、ゆくゆく作るつもりです。) レビューを draft ファイル１つだけで行うとする場合には、 po4a の利用の有無、ja.po 一本化を行う行わないの別を問わず、 jmtemplate が作り出す draft ファイルは一貫して対応できます。 なぜなら成果物からわざわざ逆算して draft を作り出すからです。 書きたい内容が次から出てきてしまい、長文失礼します。 とりあえず、本メールは以上とします。 お考えをお聞かせください。よろしくお願いいたします。 matsuand michio_matsuyama AT yahoo DOT co DOT jp
Fork