matsuand です。質問です。 manual 配下の翻訳ディレクトリ内に 拡張子 lsm のファイルがある場合があります。 lsm は中身を見ると Linux Software Map に基づくファイルです。 質問1: これを用意するのは任意との理解でよいですか？ ＃存在するものは、みなさん手作業で作られている？ ちなみに事細かく調べました。 manual/<package> は全 122 件であり、 そのうち manual/<package>/original/<package>.lsm を持つ翻訳案件は 42 件、ないものは 80 件でした。 その状況をぱっと見て GNU_<package> がほぼ存在せず、 唯一 GNU_less にだけ存在しました。GNU ソフトウェア は入手元や開発者が GNU ホームページに集約されて lsm を示す必要もないから、ということでしょうか。 GNU_<package> 33 件で GNU_less を例外と考えて GNU_<package> を抜きにして考えると lsm ありが 41 件、lsm なしが 48 件です。 作ったり作らなかったりといった状況が見られます。 質問2 まず質問の前提として、 翻訳対象ソフトウェアが更新され、man ページも更新された として、新たに更新版向けの翻訳作業にとりかかるとします。 そのときにそれまでの、たぶん旧翻訳者により *.lsm が 生成済であるとします＝でも中身は古い情報になります。 あれ？ どうするの？ と一瞬戸惑うことになります。 更新版向けの *.lsm ファイルに書き換える、というのが 素直なやり方かと思いますが、そもそも質問1 に絡みますが この生成作業が任意であるとして、翻訳前任者が生成して いたら、その後はずっと作っていくことになりそうです。 必ずしも *.lsm 生成が任意という説明にはならなくなります。 任意だったら作るの辞めよう、と考えたとします。とすると それまでの *.lsm ファイルが残ってしまいます。翻訳作業は 最新版向けに行っているのに、*.lsm ファイルが古いとなると 整合がとれません。では古い *.lsm は削除するのか？ あるいは古いことを示すために *.lsm.old とかリネームする なんてことも考えたりします。 こんなこと、かつてあったでしょうか？ 細かすぎて、そんなの好きなようにしたら、となるでしょうか？ 今後は *.lsm を鋭意作っていくことを推奨する、といった 進め方もあるかと思います。 ＃ 本質問も現状運用を批判する意図はありません。 ＃ こうしなければならないといった提言も含みません。 ＃ 単純に状況把握、実作業進行のための質問です。
Fork