On Tue, May 11, 2021 at 4:28 AM K.Shirakata <argra****@ub32*****> wrote: > > 白方です。話の都合上複数のメールをマージして順序も変わっています。 > > On 2021/05/10 22:10, matsuand wrote: > > > でもでも.. ここまでしないとダメですか？ > > > > なんだか面倒そうに感じましたが？ > > このような感想を持たれたということはtranslation_listを > 手作業で作成されたのかな、と思うのですが、 > 実はリポジトリのadmin/以下にあるmktrlistスクリプトを使うと > 翻訳前の状態のtranslation_listを自動作成してくれます。 > (使い方はスクリプトの先頭にコメントで入っています) > > # これに触れているドキュメントは現状ないかもしれません…。 ちゃんと説明したドキュメントはないですね。 http://linuxjm.osdn.jp/guide/upstream_update.html が書きかけです。 新規にパッケージを追加するときの手順はとくに聞かれなかったので 何もフォローしていませんでしたが、手作業で作成されたようですね。 新規追加とバージョン更新時のファイル追加は同じなので、 admin 以下にある git2upd と upd_tl.perl を使って以下のような感じで行っていました。 空の translation_list を作っておいて upd_tl.perl を実行します。 試しに GNU_automake を新規に登録するならこれくらいの作業で済みます。 http://paste.openstack.org/show/805213/ translation_list の各行の変更を行うコマンドもあります。 admin/JM-tl-modify.pl 私はこれを使って translation_list を編集しています。 自分の名前やメールアドレスは環境変数でも指定できます。 > > On 2021/05/10 22:55, matsuand wrote: > > > で、話を戻しますと、 > > 私が「ここまでしないとダメですか？」と申し上げたのは > > まずスクリプトの存在を知らない状態で、translation_list > > は翻訳状況を示す一つのテキストファイルである、という > > 程度の認識です。 > > 元木さんも触れられていますが、translation_listは > 翻訳状況を記録しているだけでなく、この情報を元に > linuxjm.osdn.jp内のwebページを自動生成しています。 > > 例えば writev(2)のページ: > http://linuxjm.osdn.jp/html/LDP_man-pages/man2/writev.2.html > にアクセスするとreadv(2)のページが表示されますが、 > translation_listにリンク情報を設定していないと正しく > 表示されないと思います(試してはいませんが)。 > > この生成スクリプトはリポジトリのadmin/cron/webupdate.shにある… > と思っていたのですが-all付きのものもありますね。どちらだろう…。 > というかこれを起動するcronってどうなってたんでしたっけ…。 > …とりあえずどちらかが起動されて生成しています。 > (見て頂ければ分かりますが割と追うのが大変な分量です) webupdate.sh と webupdate-all.sh は両方動いています。 webupdate-all.sh の方がダウンロード用の tarball の生成まで行うのだったかな。 ちょっと重めの処理が含まれています。 現在は osdn.net の shell サーバーで、私のアカウントの cron で定期実行されています。 ＃ osdn.net の shell サーバーでプロジェクト権限で cron を実行する手段がないため、 ＃ 個人アカウントで cron が動いています。 amotoki ＠ sf-usr-shell:~$ crontab -l # m h dom mon dow command 33 */6 * * * /home/groups/l/li/linuxjm/jm.git/admin/cron/webupdate.sh 3 1 15 * * /home/groups/l/li/linuxjm/jm.git/admin/cron/webupdate-all.sh > > 正直私もどう動作しているのかを完全には把握しておらず半分 > ブラックボックス化しているので、ここに手を入れるということ自体は > 悪くないとは思いますが、現状うまく動いていますのでこれが > 壊れるのは困ります。 > > > スクリプトとの連携でそこに制約が発生するのであれば、 > > その協議如何では、従来どおり進めるか、 > > translation_list 書式変更とスクリプト変更を同時に行うか > > という選択肢かと思います。 > > > > スクリプトの存在を知らない私にとっては、今初めて伺った > > 限りでは、そういう二者択一の問題と解釈します。 > > これは確かにその通りなのですが: > > (1) translation_listはmktrlistで作成してその他は一旦保留。 > (2) translation_listの形式を変更し、web生成スクリプトを > 読み解いて壊れないように変更を行い、さらに > 補助スクリプト類(mktrlistなど)も対応する。 > > の二者択一となった場合、私としては、少なくとも一旦は > (1)を選択するのが無難ではないかな、という考えです。 こういったことは incremental に進めるのが無難ではないでしょうか？ matsuand さんが提案している jmtemplate の導入と、 translation_list の形式の見直しは、は、本来は独立した話です。 matsuand さんが思っていたよりも translation_list が大きな役割を果たしていたことが 判明したということだと思います。最初の妥協点としては、jmtemplate が生成する translation_list は従来のもとと互換性を保つ、もしくは translation_list については 従来のツール群を使う、というあたりではないでしょうか。 （導入に反対しているわけではないですが）導入したとしても jmtemplate は使いたい人が 使うツールという位置づけだと思っています。jmteplate が対応していないから書式を変える というのは、問題がすり替わっていると感じます。
Fork