Fork元木です。
とりあえず論点の整理はしてみますが、私は決定は行いません。
主に過去の経緯の共有にフォーカスします。
JM の翻訳は現状では行う予定はないので。
私がやっていた方法分かりにくいのは認めますが、
複数の点を同時に議論しているとまとまる議論もまとまらならなくなるので、
論点を整理して議論しませんか。
ざっくり分けると以下の2点ですよね。
(1) po4a を使うか、roff を直接翻訳する方法に戻すか。
(2) gitsubmodule を使っているので管理方法が git に詳しくない人にはわかりにくい。なんとかしてくれ。
(2) の submodule の方が簡単なのでこちらから。
submodule がわかりにくいなら、JM の main repo に戻してしまいましょう。
現在 submodule を使っているのは LDP man-pages, GNU coreutils, iptables の3つです。
submodule に分割したのは私ですが、これらは翻訳の管理方法として roff 直接編集ではない方法を
使っているものです。理由は、管理方法が違うので別 repository の方がわかりやすいだろうと思った、
新しい管理方法を試すのにツール群の依存関係を別 repository の方が確認しやすかった、
JM repository 全体が大きくて色んな場所で checkout するのが時間がかかって面倒だった、の3点です。
この程度の理由なので、JM の main repo に戻してしまいましょう。
(LDP man-pages で po4a を継続利用するのであれば、perkamon も取り込んでしまった方がいいと思います。)
(1) の po4a を使うかどうかですが、
私からは po4a を導入した経緯、理由は主に以下です。
(a) original 更新時に必要になる機械的な対応作業が大幅に軽減される
これが最大の理由です。LDP man-pages では翻訳されているページでも 1000 弱あります。
original の更新では機械的な変更（書式上の修正）が発生することもかなりあり、大きな手間でした。
roff 直接管理ではこれを 1000 近いファイルについて全部反映する必要があり、現実的ではありませんでした。
1000 近くの roff ファイルを diff を目で確認しながら更新するのは、ゾッとします。
(b) 更新箇所が明確になる
minor な変更の場合は ja.po の中に fuzzy がついて以前の原文と最新の原文が並んで表示されます。
差分を確認することで、翻訳の更新のポイントがわかりやすかったです。
(c) 英語混じりでも常に最新版のマニュアルが提供できる
LDP man-pages はシステムコールやライブラリ関数を扱っていることもあり、最新の方が重要です。
以前、翻訳されたページが古くて、英語版でないと使い物にならないことが多く、
LANG=C man 2 read するみたいなトリックが広まっていたこともあり (ribbon さんの po4a の
メールにあった nabetaro さんの slideshare にも書いてありますねw)、Fedora/GNOME などの翻訳界隈
の人と相談しました。そのときの話では、英語交じりでも最新の情報を提供するのがいいだろう、
更新の手間を減らす方法を探すのがいいだろう、というのがアウトプットでした。10年以上前の話です。
なお、(c) については、いろんな意見があると思います。私自身は、個人的には最新版が英語混じりでも
入っている方が好みです。言い換えると、JM が収録されるディストリビューションのコマンドと可能な
限り一致しているべきだという意見です。システムコールや iptables コマンドの man を表示して、古い
翻訳版が表示されるくらいなら、ない方がいいと思っているので。
Q. po ファイルは roff ファイルと 1:1 ではなくカテゴリー単位になっているのはなぜ？
A. 最大の理由はすでに LDP man-pages の po4a を使った翻訳をやっていてフランス語のチームが
スクリプト群 (perkamon レポジトリー) があったからです。最初は私も不便かなと思いましたが、
カテゴリーごとに共通の訳語も多く、これまでの経験ではメリットの方が多かったです。
あと、バージョン情報が roff ファイルごとにあるのを更新する作業を1000近くのファイルにするのは苦痛です。
カテゴリーごとでもちょっと多いですが、数十になるのは大きな違い。
Q. po4a デメリットは？
A. こんなところかな？
・PO を挟むので roff を直接したい人には不便。翻訳を確認するにも一度変換しないといけない
・日本語英語混じりのページができてしまう。これは releases にどのタイミングで移動するかで調整できる。
・翻訳のレビュー方法を確立する必要がある。roff とか整形後のやつでレビューすればいいと思います。
余談1: coreutils が別の管理方法になっている背景
記憶が確かなら GNU coreutils の man は、コマンドのヘルプからの変換で生成されていて、
日本語訳もコマンドのヘルプの翻訳が進んでいるので、JM で独自に訳す（二重に翻訳）よりも
コマンドの翻訳を充実させた方がいいだろうということで、help2man を使った管理にトライしていたはず。
> さらに、もう一つ。これは感想の類ですが。
> po4a を使うにしても、man page を一つ一つ po ファイルにするのではなく、
> man page をいくつも一緒にした大きな po ファイルを作るようになさっていて、
> そのために手順が複雑になっています。でも、そうした理由には、ファイルが
> 多すぎるからばかりではなく (2000 個ぐらいあるのでしょう)、マニュアルの
> バージョンを統一しておきたいということもあったのではありませんか。
>
> もしそうなら、roff による変更を受け入れることは、ライブラリのマニュアルの
> バージョンがバラバラになることを受け入れることになります。util-linux みたいな
> ものなら、一応独立したコマンドですから、それでも問題ないと思いますけれど、
> man2 や man3 の場合は、どうなんでしょうか。
JM 成立当初から、original の更新は一括でやっていたので、
翻訳済みマニュアルのバージョンをバラバラにするのは想定していなかったと思います。
実際には、翻訳済みになったマニュアルしか releases に移動していなかったので、
結果的にバージョンがバラバラのマニュアルが存在することになっていると思います。
古いものが居座り続けた結果、過去には日本語マニュアルは古すぎるから、
LANG=C で man を実行する方法が bad knowhow になったこともあります。
（今もそろそろそうなるのかな）
今書けることはこれくらいです。
疲れたので2週間くらい間を置きます。
On Mon, Mar 1, 2021 at 12:29 PM 長南洋一 <cyoic****@maple*****> wrote:
>
> 長南です。
>
> > http://linuxjm.osdn.jp/guide/LDP_man-pages_update.html#perkamon
> > のところは original の perkamon の repository がなくなってしまっている、
> > というか gitorisous はサービス終了したんですね。
> > この手順は、 JM 用に私が fork したレポジトリ (*) を使っていて、
> > それに original の perkamon の変更を取り込むときの手順ですね。
> > gitrious がなくなった今となっては不要ですね。
> >
> > 「オリジナルが更新されていない場合は自分で更新する」の手順をやる必要があります。
>
> やってみましたが、途中で見事にわけがわからなくなりました。
> 私には難しすぎます (^^;;
>
> さて、ここからが本題です。
> LDP man pages の引き継ぎには、二つの問題があると思います (iptables や
> GNU_coreutils のような submodule になっているもの全般に言えることですが)。
>
> 一つは、特に LDP man pages の場合、po4a を使う方法が難しいこと。
> でも、これは、「私には難しい」ということで、わかる方には何でもないことでしょう。
> それに、どうしても使い切れないのなら、{original,release} 以下と
> translation_list を手作業で更新してもよさそうですから (それで、用が足りますね)、
> それほどの問題ではありません。
>
> もう一つのほうが重要です。それは、JM 側から submodule 内を変更できるのか、
> ということです。"man git-submodule" の DESCRIPTION の最後のパラグラフには、
> こんな風に書いてあります。
>
> Submodules are not to be confused with remotes,
> -- (中略) ---
> you cannot modify the contents of the submodule from within
> the main project.
>
> さらに、続けて、
>
> If you want to merge the project histories and want to treat
> the aggregated whole as a single project from then on, you may
> want to add a remote for the other project and use the subtree
> merge strategy, instead of treating the other project as a submodule.
>
> この説明からすると、JM 側から submodule 内の更新は出来ないのではないでしょうか。
> 「うじうじ考えていないで、試してみればいいじゃないか」と言われそうですが、私は
> 臆病ですから、万一 repository を壊してしまったらと心配で、試せないでいます。
>
> もし、JM 側から submodule 内の更新が出来ないのなら、そして、JM 側から
> LDP man pages などの更新がしたいのなら、上の引用にあるように subtree
> にするか、あるいは、submodule としてではなく、直接 JM の jm/manual/ 以下に
> ぶら下げるかするよりないのではないでしょうか。
>
> どちらでもよいのですが、そこまでは、元木さんに (あるいは、git がよく分かって
> いる方に) やっていただきたいと思います。私には無理ですから。git の初歩しか
> 知らない私には、そういう影響の大きいことをするのは、怖すぎます。頼りすぎなことは
> わかっていますけれど。
>
> それから、もう一つ方法がありますね。以前、JM とは別に LDP man pages
> 翻訳のメンバーを募集していたことがなかったでしょうか。LDP man pages の
> 翻訳希望者にそちらのメンバーになってもらう手もあると思います。
>
> さらに、もう一つ。これは感想の類ですが。
> po4a を使うにしても、man page を一つ一つ po ファイルにするのではなく、
> man page をいくつも一緒にした大きな po ファイルを作るようになさっていて、
> そのために手順が複雑になっています。でも、そうした理由には、ファイルが
> 多すぎるからばかりではなく (2000 個ぐらいあるのでしょう)、マニュアルの
> バージョンを統一しておきたいということもあったのではありませんか。
>
> もしそうなら、roff による変更を受け入れることは、ライブラリのマニュアルの
> バージョンがバラバラになることを受け入れることになります。util-linux みたいな
> ものなら、一応独立したコマンドですから、それでも問題ないと思いますけれど、
> man2 や man3 の場合は、どうなんでしょうか。
>
> --
> 長南洋一
>
> _______________________________________________
> linuxjm-discuss mailing list
> linux****@lists*****
> https://lists.osdn.me/mailman/listinfo/linuxjm-discuss