matsuand です。 ribbon さんからの [JM:03277]「[POST:TR] at 3.2.4」 のメールにおいて発覚した、 本プロジェクト運用の"ほころび"について 課題としてあげます。 まずこれまでどなたも意識されていなかったであろう内容で、 相当込み入っていて、話は非常に長くなります。できるだけ 分かりやすく説明するつもりです。 発端の出来事から説明します。 1) po4a を用いた翻訳が実施されていました。 これが現状最新の翻訳でした。 2) draft ディレクトリが残っていました。 3) 事情不明な他者が翻訳開始を行おうと思い、 そこに draft ディレクトリがあるので、 draft 内ファイルに新翻訳を加えようとしました。 これは勘違いというレベルで片付けられない、運用上、 割と深刻な問題と考えます。 po4a が最新であるため、draft 内ファイルは古いもので あり、draft ファイルが消去されていれば、間違いは 起こらなかったかもしれません。ただそれだけで済む 話でもありません。 いろいろな場合分けの話もあるため、除外できるものは 早々に除外して、本筋を見極めます。 まず除外の話から。 1) の状況が発生したのは、最近 matsuand が着手している 翻訳作業内容として、翻訳はするけれども校正依頼は行わず リリースも行わない、という状態であったため、という話が あります。これの良し悪しがまた再燃するかもしれませんが、 これはここでは除外しようと思います。私が採っているこの 状態が仮になくなったとしても、問題は解決しないからです。 翻訳予約をしてから相当な時間が経過していて、ほぼ放置され ている翻訳案件が、現実にはいくつかあります。これに対して 翻訳予約を反故にして最新着手しようとしたときに、同じ問題 が発生します。除外扱いとして、これ以上深く述べません。 もう一つ除外の話 po4a が最新であることを知りつつ、はっきりとした意図を 持って、draft ファイルを編集する場合です。この場合は、 おそらく今まで発生したことのない、１つの翻訳案件内にて 意見が対立するのかバージョンが異なるのか、いずれにせよ ２つの(あるいは複数の)翻訳結果が混在することを意味します。 これはこれで git ブランチなどを活用すれば、できること ですが、これを許容することは、本プロジェクトに前例のない とてつもなく多大な影響を及ぼす事態となります。理論的には 可能であっても、少なくともここでの議論からは除外します。 --- po4a による翻訳が実際には最新の翻訳結果にあった状況で、 draft に手を出してしまうのは、ある意味、仕方のないこと かもしれません。draft ファイルの運用に慣れた方や、あるいは 現実問題としてJMガイドには draft ファイル運用が主流のもの として説明されていますから、誰もが draft ファイルに手を つけるのが自然です。このことを考慮できていなかったことは、 まず第一に私 matsuand の落ち度です。一応、私の弁解として これはプロジェクト全体の落ち度と考えたく思います。 では po4a が最新であることを示すためにも、それまで存在して いた古い draft ディレクトリは削除する、という方策が考えられ ます。これにより万事解決となると一見思えます。ただしネックが あります。draft ディレクトリは HTML ページでの公開対象に なっているからです。draft 内ファイルを公開対象として、今後も 維持するかしないかの議論につながります。維持するという結論に なるのであれば、draft ディレクトリは少なくとも、今の場合 po4a による最新の翻訳がリリースに至ってからでないと削除でき ません。維持しなくても良い、あるいは今後 draft ファイルは 公開対象としない、という結論になるのであれば、draft ファイル は po4a による新翻訳着手の段階で、早々に削除できます。 このような状況をどうするか、現段階は運用が何も定まっていません。 現実に発生した状況だけでなく、もっと深く考えていくと、 たとえばそれまで po4a で翻訳がなされていたものを、次に受け継ぐ 新翻訳担当者が、自分は po4a ではなく draft ファイル編集方式を 採る、と考えて作業着手した場合には、逆の問題が発生します。 つまり po4a ソースが古い翻訳版として残ることになり、draft ファイル が最新のものになるわけで、さらにその次に翻訳着手する者が現れた 場合に、draft ファイルと po4a のどちらが最新なのか、状況をつぶさ に調べてみないと判別できない、ということになります。上で draft ディレクトリを削除する話がここにも適用され、こちらの場合は po4a ディレクトリを削除する話になります。上と合わせて、そうする のであれば、それを明確化する運用が必要になります。 今後、draft ファイル編集方式と po4a 翻訳方式は、両者採用されて いくでしょうが、少なくとも１つの翻訳案件での混在は不可とし、 翻訳担当者がそのいずれか一方から他方に切り替える際には、過去の 方式のソースは一切削除することで、混乱を回避するという運用が 考えられます。すでに上で述べたように draft ディレクトリを削除 する（あるいは po4a ディレクトリを削除する）という作業を運用 フローに含めて徹底させるということです。 話について来て頂けているでしょうか？ ごちゃごちゃ面倒だから「良きにはからえ」という話になるようでしたら 適当に matsuand が対処します。 私の案は po4a を採用した時点で、とっとと draft ディレクトリは 削除することにします。これまではこれに気づいていなかったので draft ディレクトリを削除していませんでした。これも私が採ってきて いた作業方式、つまり翻訳はするけれどもリリースはしない、という ことから、draft ディレクトリはリリースまでは一切触れない、として いたことが原因です。今後は削除することにします。削除を行うと HTML ページでの draft ファイル配信は行われなくなります。 それでも良しとするのが、私の案です。 いくつも draft ディレクトリを削除せず残したままとしているものが あるので、いっせいに削除しないといけません。 draft ファイルの公開は、今考えると、そもそもが不要な気がします。 何かお考えを聞かせていただければ伺います。
Fork