matsuand です。 返信します。２点。 On Wed, Feb 23, 2022 at 11:17 PM ribbon <jm****@ribbo*****> wrote: > ... > まだそのあたりは全然考えていません。 > sphinx での修正は敷居が高いため(Wikiだとすぐに修正できる)、 > 自分のメモという意味合いも兼ねて、まずはWiki に書き込んでいます。 sphinx についてですが、割と敷居は高くないと思っています。 これまでに「非常によく」整備していただいているので、 cd jm.git/guide export JMHOME=. sh build-jm-guide.sh html とすれば、たぶんビルドできます。 sphinx を venv 環境配下にダウンロードしてくれるため、 あらかじめ sphinx を用意しておく必要がないためです。 (一度やっておけば以降は make html のみ； make JMHOME=. html かな・・・？) 興味があればお試しください。 > > ちなみに私も翻訳手順を総じて書きたいと思っていますが、 > > さて ribbon さんとの作業分けが必要になりそうな気がします。 > > どうお考えですか？ > > 今のままだと、1つのファイルを修正する所に行き着くまで、相当時間がかかりそうです。 > Wikiでもsphinx でも良いので、作れるところは作っていただき、競合しそうな > 時点で調整、で良いのではないでしょうか。 wiki は一般ユーザー向け説明、 sphinx 文書は内部向け説明、 といった切り分けを思いつきました。 現状の sphinx 文書は、一般ユーザー/内部説明が混在した 状況のように感じられます。上のように切り分けてもいいな と思います。完全に切り分けることは目指しませんが、 一方で、wiki と sphinx で同じ内容を表現しても無駄 になってしまいますので。 今着手してみようかなと思うのは、内部向け説明として git コミットのタイミングとか、ディレクトリ生成の詳細な取り決め とか、あるいは現行バッチジョブの（リバースエンジニアリングした） 内部仕様説明とか。自分の理解と活用のためという目的も ありますが、整理しておくことで、今後のシステム管理に共する 目的として。一般ユーザーに向けた内容は、プロジェクト内部 関係者は十分理解しているという前提で、そのプロジェクト 内部関係者向けに書く、ということで、それを sphinx 文書内 に実現すれば、wiki とは対象読者が切り分けできて、 つまりは ribbon さんとはかぶらないかな、と考えています。 完遂できる自信はありませんが、とりあえずの方向として。
Fork