On Mon, Mar 7, 2022 at 5:07 PM matsuand <michi****@gmail*****> wrote: > > matsuand です。 > > On Mon, Mar 7, 2022 at 2:54 PM IIJIMA Hiromitsu > <delmo****@denno*****> wrote: > > > ... > > データフローの「一方通行化」ではダメですか？ > > つまり、データの生成順序を「(po4a→)draft→release」と固定します。 > > po4aで編集してそれをcommitした場合は、即時に（あるいは毎日の定例バッチで）draftもその内容に更新して、この際に「直接このdraftを書き換えるな」という目印を何らかの形で附与しておきます。方法としてはファイルの冒頭にコメントをつけるとか、あるいはファイルのwrite permissionを落としておくとかが考えられます。 > > 逆に、訳者がdraft直接編集を採用する場合には、前のバージョンpo4a形式のデータをリポジトリ内に残さない（あるいはダミーファイルに置き換える）ようにします。 > > > > あとは作業手順書の更新と、上記手順を全員が順守するための安全策をどう構築するかの問題になります。 > > まずそもそも draft ディレクトリは、旧来の draft 編集方式では > まさにそこで編集作業を行う場所であるわけですから、なくては > ならない必須の場所でした。だからその存在は自明であったわけです。 > ところが po4a （あるいは別ツールでも） を利用する場合、 > draft ディレクトリは、存在を前提とする必要もなく義理もありません。 > draft ディレクトリを無くてはならないものとする方式と、 > 無いことが当たり前で最後まで無くても困らない方式とが > 混在運用されているからこそ、問題が発生します。 po4a を使う場合に draft フォルダーは不要であり、draft をリポジトリーに コミットする必要はない、という点に同意です。 分かりやすくするために、 po4a に移行した時点で draft フォルダーを 削除するのには賛成です。 > draft を経由することを前提とするということは、 > po4a 方式に draft を作り出す義務を課すことになります。 > それがベスト、ベターであるとする考えに従うのは、 > それはそれで構いません。現実に私は gendraft.perl なる > スクリプトを作成し、po4a 方式採用者が draft ファイルを > 作り出せるように手を打っています。 gendraft.perl はレビューのしやすさという観点では有用ですが、 内容的には PO ファイルの内容を変換しただけなので、 必要に応じて動的に生成すればよく、リポジトリーにコミットする 必要はないと思います。 > ただあまりにも、旧来の運用に引きずれら過ぎの様相です。 > 当初から po4a 方式しか採っていなかったとしたら、 > draft ディレクトリは存在していなかったはずです。 > だから何なのか。。。。 次回必要に応じて述べます。 > po4a 方式における draft ディレクトリは作成不要 > とすることに一票投じておきます。 po4a を使用している場合は、draft フォルダーは不要、 に私も一票入れておきます。 --- なお、po4a を使う場合には draft フォルダーを消すことにした場合、 LDP man-pages だけは特別扱いしてもらえると助かります。 LDP man-pages は、現在、翻訳率が 100％ でなくても公開版を作っています。 また、翻訳率が 80% 未満の場合は、一つ前の release 版を公開しています。 翻訳率がしきい値未満の場合はページを削除するようにしているので、 release フォルダーを出力先にすると、git add -u で staging する際に 作業がけっこう面倒になってしまいます。なので、draft フォルダーを出力先にして、 release には別途コピーしています。 もっとうまい方法がきっとあるでしょうから、皆さんの知恵に期待することにします。 --- > > > 削除を行うと HTML ページでの draft ファイル配信は行われなくなります。 > > > それでも良しとするのが、私の案です。 > > > draft ファイルの公開は、今考えると、そもそもが不要な気がします。 > > > > ちょっとここは議論が必要だと思います。HTMLが公開されていれば、担当者がMLに進捗を報告したあと、わざわざgitで訳文を取りに行かなくても第三者がhttp(s)で確認できる、特に、出先にいてUnix環境がなくてもWindowsやスマートフォンで簡単に閲覧できる、というメリットがあります。既にそういう環境が整っているのに、わざわざ手間をかけて廃棄するのはいかがなものかと思います。 > > ここには疑問があります。 > HTML 上での draft ページの公開は、常時必ず行われてきていますか？ > どこにも draft をコミットするタイミングを示した運用手順のドキュメント > がないので判然としません。少なくとも校正依頼を発信するメール本文に > draft ファイル内容を付する運用があることだけは承知しています。 > つまり ML には draft ファイルが掲示されているはずで、それが > HTML 化されているかどうかは二の次のように捉えていました。 > むしろ二の次で良いと思っています。出先で確認したければ、 > メール本文に書かれた draft 内容を見れば良いですし、 > そもそも出先に居るメンバーの方々のことを、どれだけ > 手厚くサポートしなければならないのですか？ という疑問すら > わきます。校正確認は職場のデスク上で休み時間に、 > あるいは家に返ってからゆっくりと、で良いでしょう。 > 手厚く保護するほど、出先の方からの情報が > 多数優越していれば別ですが。 ここで話題になっている「HTML ページ」はどれのことなのでしょうか？ 現在、ウェブ経由でアクセスできるページは 3 種類あります。 (1) リリース済みページの HTML 変換バージョン http://linuxjm.osdn.jp/html/LDP_man-pages/man3/getnetbyname.3.html (2) リリース済みページの roff 形式 http://linuxjm.osdn.jp/manual/LDP_man-pages/release/man3/getnetent.3 (3) draft ページの roff 形式 https://linuxjm.osdn.jp/manual/LDP_man-pages/draft/man3/getnetent.3 HTML ページの存在意義は (1) かなと思っています。 今は draft ページのことを議論しているので、(3) のことかな、と推測します。 URL 直接入力以外で (3) が参照されるのは、 http://linuxjm.osdn.jp/INDEX/progress.html のページからだけのはずです。 (3) の話であれば、translation_list で draft が存在する状態なら、 draft 相当のファイルを自動生成すればよいだけです。 matsuand さんが作成してくれた gendraft.pl で生成してもいいですし、 別の方法で生成してもいいです。いずれにせよ、リポジトリーに draft を コミットする必要性はないと考えます。 将来的には、レビューを GitHub Pull Request や Gerrit のような形で行う方が 建設的かもしれません。対訳でのレビューしやすい版が必要なら CircleCI や TravisCI などで生成すればいいと思います。
Fork