いいじまです。 > まずこれまでどなたも意識されていなかったであろう内容で、 > 相当込み入っていて、話は非常に長くなります。できるだけ > 分かりやすく説明するつもりです。 > > 発端の出来事から説明します。 > 1) po4a を用いた翻訳が実施されていました。 > これが現状最新の翻訳でした。 > 2) draft ディレクトリが残っていました。 > 3) 事情不明な他者が翻訳開始を行おうと思い、 > そこに draft ディレクトリがあるので、 > draft 内ファイルに新翻訳を加えようとしました。 ... > 今後、draft ファイル編集方式と po4a 翻訳方式は、両者採用されて > いくでしょうが、少なくとも１つの翻訳案件での混在は不可とし、 > 翻訳担当者がそのいずれか一方から他方に切り替える際には、過去の > 方式のソースは一切削除することで、混乱を回避するという運用が > 考えられます。すでに上で述べたように draft ディレクトリを削除 > する（あるいは po4a ディレクトリを削除する）という作業を運用 > フローに含めて徹底させるということです。 データフローの「一方通行化」ではダメですか？ つまり、データの生成順序を「(po4a→)draft→release」と固定します。 po4aで編集してそれをcommitした場合は、即時に（あるいは毎日の定例バッチで）draftもその内容に更新して、この際に「直接このdraftを書き換えるな」という目印を何らかの形で附与しておきます。方法としてはファイルの冒頭にコメントをつけるとか、あるいはファイルのwrite permissionを落としておくとかが考えられます。 逆に、訳者がdraft直接編集を採用する場合には、前のバージョンpo4a形式のデータをリポジトリ内に残さない（あるいはダミーファイルに置き換える）ようにします。 あとは作業手順書の更新と、上記手順を全員が順守するための安全策をどう構築するかの問題になります。 > 削除を行うと HTML ページでの draft ファイル配信は行われなくなります。 > それでも良しとするのが、私の案です。 > draft ファイルの公開は、今考えると、そもそもが不要な気がします。 ちょっとここは議論が必要だと思います。HTMLが公開されていれば、担当者がMLに進捗を報告したあと、わざわざgitで訳文を取りに行かなくても第三者がhttp(s)で確認できる、特に、出先にいてUnix環境がなくてもWindowsやスマートフォンで簡単に閲覧できる、というメリットがあります。既にそういう環境が整っているのに、わざわざ手間をかけて廃棄するのはいかがなものかと思います。 P.S. リリース版のHTML公開をどうするかについては別途。 -- 飯嶋 浩光／でるもんた・いいじま ＠ PC IIJIMA Hiromitsu, aka Delmonta Email <delmo****@denno*****>
Fork