On Thu, May 6, 2021 at 9:02 PM matsuand <michio_matsu****@yahoo*****> wrote: > > matsuand と申します。 > いろいろコメント、ありがとうございます。 > > コメントをお返しします。 > 今後みなさまとともに、協議していければよいと思っています。 はい、よろしくお願いします。 ＃別メールで書いたとおり、私自身は JM 活動に今はモチベーションは高くないので、 ＃これまでの背景などを説明するくらいにとどめますが。 > > ブランチを少しみましたが（usage.rst を流し見）、 > > このツールが何をしてくれるものなのかがよく分からなかった、 > > というのが正直な感想です。 > > > > ・matsuand さんのツールで何が楽になるのでしょうか？ > > 主に新規の翻訳対象作りを意識しています。 > 当 jmtemplate をコピーして usage.rst に書いた手順を進めれば、 > たぶん即座に環境整備できて翻訳作業にすぐに取り掛かれるという > 便利さがあると思っています。 > > po4a の Makefile 作りからは解放されます。 > translation_list 作りが楽になります。 > copyright ファイル作り(po4a の addendum)が楽になります。 > draft ファイルが、翻訳者が作らなくても利用可能になります。 なるほど。 Makefile は必ずしも必須ではないと思っています。 LDP man-pages のやつは規模が大きく、make 一発の方が楽なのでそうしていますが、 簡単なものなら、ファイル名を指定したら po4a-translate などを呼び出してくれる シェルスクリプトがあるだけでもいいような気もしています。 translation_list は、 git で original にページを追加すると (git add)、 admin/git2upd -> admin/upd_tl.perl を使うと、作成してくれます。 これが面倒なら仕方ないですが。 便利なことに越したことはないと思います。 > ＃現時点では大した重要性はありませんが、Autoconf による > ＃./configure スクリプトを利用しています。ですから > ＃作業環境ごと、あるいは作業担当者ごとの違いを > ＃比較的スムーズに吸収できます。 > > 私は近々にこれを用いた提案を行いたく思っています。 > 後々みなさまに見ていただき、評価を仰ぎたく思います。 > > > > ・レビューで原文と翻訳の対応が見やすくなるのでしょうか？ > > レビュー運用は大きな課題であり、当 jmtemplate ですべてを > 引き受けて解消するような道具ではありません。そこまで考えて > いませんし、考えてもなかなかそんな便利ツールはできないと > 思っています。（すみません、運用が固まっていないとの前提 > を感じ取ったので、このように表現しました。） > > > ・現在すでに翻訳があるものの更新などをするひとにはどんな便利なことがあるのでしょうか？ > > > 過去メールアーカイブをざっと見た際に、po4a への移行を行うとか > その移行が大変とか、操作不明につきどうとか、そういった雰囲気を読んだ > 記憶があります。もしそれが事実であるなら、既存の翻訳で po4a 化ができて > いないものは、比較的簡単に移行できると思っています。po4a を知らない方 > でも手が出せるものになります。ただし手修正作業はいろいろ発生しそうですが。 po4a は知らなくても、逆に jmtemplate を知る必要がある、ということなら、 個人の好みのということになると思います。 po4a 化の過程で roff の文法エラーになっているものも少なからず見つかったので、 こういったケアレスミスも防げる仕組みだとナイスです。 > もしそのような既存の翻訳対象があれば、私が移行作業を全面的に > 実施することも考えながら、当 jmtemplte 作りを進めています。 現状を考慮すると、特定のパッケージに興味がある人がやりやすい方法でするのが いいと思っています。仮の話ですが、 matsuand さんの興味が離れてしまった後に、 別のひとが po4a に戻りたいとか、もっと原始的な方法でやりたい、 と思ったときに不便でないレベルなら、いいと思います。 > > あと、 proposal_matsuand ブランチでは、現在 manual/ ディレクトリは翻訳物件のみが > > 格納されていますが、 manual/ 以下に置くのは避けた方がいいと思います。 > > 追加するなら、リポジトリのトップに tools とかディレクトリを作ってそこに置くのが > > 良さそうです。 admin/ 以下でもいいかもしれませんが。 > > manual 以下はウェブサイト用のスクリプトがスキャンしている可能性もあるので。 > > わかりました。むしろありがたいご助言です。 > tools ディレクトリなどが適当かと思います。 > > 実は当 jmtemplate の目立たないが重要な特徴として、横断的に複数翻訳対象に対して > 共通 Makefile とか、共通 configure 部品とかを用意している点です。 > そのためそれらを共通的な場所に置いてインクルードする形にすれば、 > より効率的になると思っていましたので、その方向性をお話しいただけたことは、 > まさに願っていたことです。 > > 今後、たとえば tools ディレクトリなどに移すようにします。 > > なおここまでにいろいろ、お話しをうかがってきた中で感じ取っていること > として、「どうしたらいいですか？」とお伺いしても、なかなか難しい問題を > 孕んでいるいるとお答えがすぐには戻ってこないような印象を受けました。 > あたりまえのことでしょうし、失礼な言い方かとも思いますが。 決まっている話が少ないので答えにくい点もあるのかもしれませんが、 それ以外にも、プライベートの時間を使ってやっている人がほとんどだと 思いますので、個人のプライオリティーは違います、 例えば、返事をするのに5分以内で返事を書ける内容ならすぐに返事をかけますが、 10分も20分もかかるようであれば、また今度にしようということも、よくあります。 誰も返事していないようであれば、仕方ないなと思って腰を上げることもあります。 忙しければ、誰か返事してくれればいいな、と思って、放置することもあるでしょう。 力作な質問がバースト的に来たら、圧倒されてしまうこともあるでしょう。 全員が自分と同じプライオリティーとモチベーションで動いているわけではないので、 プロンプトに返事がもらえる前提は少し過度な期待に思います。 数日単位で返事を待つくらいの余裕はあった方がよいかと。 ＃これでもずいぶん頑張って返事しているので、 ＃通常は今の20％くらい以上は期待しないでください。 > ですから私は、とりあえず実現したものを見ていただくことを優先したい > と考えています。ダメなら取り下げます。ＯＫなら進めます。 > 運用はどうなっていますか、と伺うよりも、案をあげてしまった方が、 > たくさん情報をいただけると感じてきましたので、そうさせていただきます。 全体の仕組みに影響を与えるのでなければ、進めてしまうのでいいと思います。 パッケージ単位にやり方が違うくらいあれば、それに対して自分が面倒をみるつもりが あるのであれば、進めてしまえばいいと思います。 > > またご報告します。 > > matsuand > michio_matsuyama AT yahoo DOT co DOT jp > > _______________________________________________ > linuxjm-discuss mailing list > linux****@lists***** > https://lists.osdn.me/mailman/listinfo/linuxjm-discuss
Fork