[JM:02519] Re: original ディレクトリのコミットタイミングについて

アーカイブの一覧に戻る
Akihiro Motoki amoto****@gmail*****
2021年 6月 17日 (木) 23:27:56 JST


On Thu, Jun 17, 2021 at 10:34 PM matsuand <michio_matsu****@yahoo*****> wrote:
>
> matsuand です。
>
>
> ----- Original Message -----
> > From: Akihiro Motoki <amoto****@gmail*****>
> > To: matsuand <michio_matsu****@yahoo*****>; Linux JM discussion <linux****@lists*****>
> > Cc:
> > Date: 2021/6/17, Thu 22:17
> > Subject: [JM:02516] Re:       直近の git リポジトリ登録について
> ...
> > (1) manual/GNU_autoconf 以下には、通常含まれるはずの original, translation_list が
> >   入っていません。最低限どのようなファイルを置くかは決まっていると思いますので、
> >   それに準じてもらえると助かります。これまでは draft の登録を行う場合は、
> >   これをあらかじめリポジトリに追加してから draft を追加していました。
>
>
> translation_list はコミットします。
>
> ところで original ディレクトリについては、逆に気がかりです。
> これはちなみに、当案件 GNU autoconf の場合は、新規登録案件なので、
> 気にしなくて良い話ですが、コミット操作フローを全般的に考えた場合に
> 気にかかる話です。
>
> 何かというと、draft を挙げた段階で original をコミットしてしまって
> 良いものでしょうか、という疑念です。そういう運用で良しという話であれば
> それはそれでよいのですが。
>
> たとえ話として、これがプログラミング言語ソースのコミットであった
> と仮定して考えます。draft ディレクトリ内は、これから改修する予定の
> ソース、ということで、レビュー目的しかありません。original を刷新
> してしまうのが不自然に感じます。master ブランチ上のソースを使って
> いながら git HEAD のソースがビルドできない状態を作り出してしまって
> いると考えられます。original を更新するのは、リリースするタイミング
> ではないですか? これも取り決め次第かと思います。

まず、JM 設立当初に整理されたものを書いておきます。

もともと想定されているライフサイクルとしては、
なかなかちゃんと説明したものがないのですが、
http://linuxjm.osdn.jp/guide/translation_list.html の中程にある囲みが
比較的わかりやすいかもしれません

original は現在翻訳対象としているものの原文が入っているという位置づけで、
翻訳するひとは original をダウンロードして翻訳する、
draft は original に登録されたバージョンに対する翻訳のドラフト
release は翻訳・校正が終わった外部公開バージョン、という整理です。
original と draft は作業用という位置付け。

新しいバージョンが出たら、original を更新する、draft を追従する、
翻訳・校正が終わったら、draft の最終盤を release に反映する、
更新作業中は original と release のバージョン不一致は許容する、
release はリリース済みのものなので、original とのバージョン不一致が
問題になることは少ない、というのが従来の整理です。

roff を直接扱う方法だと、これで不整合はなかったと思います。

ここまでが従来の方法のはなし。

以下は私の分析も混じります。

linux.or.jp から osdn.net (sourceforge.jp) 移転後は、
投稿された draft の自動登録がなくなったので、
翻訳更新完了時点に draft と release をあわせて登録することも多かったはずです。
この場合、draft は原文がコメントとして残っている場合は意味があり、
po4a などで生成して draft と release が同じになっている場合はとくに
意味がなくなります。

po4a などのツールを使うようになると、original を参照して翻訳を生成するので、
この状況が少し変わって来て、運用にもあわせていく必要があることでしょう。
新しいバージョンに対応するために original を更新してしまうと、
release 版のバグ修正ができなくなってしまいます。
この場合は、 original, draft, PO ファイルを併せて更新する、
といったことも必要になるかもしれません。

また、私が original と translation_list がないのを気にしたのは、
このまま draft だけが登録された状態で翻訳作業が中断してしまった場合、
状態の把握がしにくくなるというのもあります。

改善の余地はあると思いますが、現在の translation_list を処理するスクリプトは
たしか original のバージョンが先に更新されることを前提に書かれていたと思います。

過去の経緯を中心に書きましたが、私が書けることはこれくらいです。


linuxjm-discuss メーリングリストの案内
アーカイブの一覧に戻る