いいじまです。 > ja.po の差分を作成しようと思ったのですが、 > ja.po を編集したら、各日本語訳の、引用符でくくられている部分の長さが、 > 編集していない所まで全部変わっていたので、差分が作れませんでした。 ですね。全面差し替えのようなdiff出力になっています。 ☆ ☆ ☆ で、私のほうでも一通りチェックしてみました。 直したい部分の正味の文字数はたかだか数十字なのですが、行単位でdiffをとると24kBになってしまったので、とりあえず圧縮ファイルにして添付します。 （zip圧縮にして、かつ中のファイルにも拡張子 .txt をつけているので、大抵の環境では普通に解凍して読めると思います。iPhoneの場合は標準の「ファイル」アプリだけで大丈夫なはずですが、どなたかAndroid界隈の事情についてご教授いただきたいです。） ☆ ☆ ☆ 以下、指摘事項の中で、説明を要すると思われるものを列挙します。 それぞれの事項の採否決定は、最終的にはribbonさんにお任せします。 （行数の変更は一切ないので、不採用のdiff断片を直接エディタで削除すればそのままpatchコマンドが食ってくれるはずです。） 逆にここで触れなかったものは「誤字・脱字・余字の訂正」「係り受けや助詞などの修正」「複数の記述の間で表現を統一」といったものです。ただしこちらについても、ribbonさんのほうで「これは誤り」と判断された場合は躊躇なく不採用としてください。 ☆ ☆ ☆ | "xz, unxz, xzcat, lzma, unlzma, lzcat - Compress or decompress .xz and .lzma " | "files" |-msgstr "xz, unxz, xzcat, lzma, unlzma, lzcat - .xz, .lzma ファイルの圧縮、伸長を行います。" |+msgstr "xz, unxz, xzcat, lzma, unlzma, lzcat - .xz, .lzma ファイルの圧縮、伸長" ここだけでなく、他のmanpageも同様に体言止めで統一する案のdiffを作ってみました。 他のパッケージの既存訳でも表記が揺れているようですが、体言止めにせよ「～します。」のように句点コミの文章の体裁を取るにしても、とりあえず何か表現を統一しておいたほうが良いかと。 |-"特にかつてのシステムを利用してきたユーザーは、(以下略) |+"特に、古いシステムを利用してきたユーザーは、(以下略) 日本語で「かつての」という言い方をする際には後ろに具体的な名詞の列挙が来る、というのが私の直観です。たとえば「かつてのWindows95/98」「かつてのガラケー」のように。 それをふまえると、「かつてのシステムを利用していた」という言い回しは、「かつて我々は『システム』と称される道具を利用してきた。しかし今では、かつて『システム』という名称で呼ばれていた道具は既に廃れている。」というニュアンスが色濃く感じられます。 |-"整合性チェックを一切計算しません。(以下略) |+"整合性チェックを一切行いません。(以下略) 「チェックを計算する」とは言わないと思います。 |-msgstr "B<.xz> ヘッダーの整合性を、常に CRC32 によって検証します。これを変更したり無効化することはできません。" |+msgstr "B<.xz> ヘッダーの整合性は、常に CRC32 によって検証します。これを変更したり無効化することはできません。" 「…を…します。」という表現からは「意図的にそうする」というニュアンスを感じます。ここではそうではなく、「整合性チェックに関するどんなオプションをユーザやスクリプトが指定しようとも、.xz ヘッダーのチェックにだけは必ずCRC32を使用する」という記述なので、「…整合性『は』、常にCRC32によって」としてみました。 | "リテラルの処理では、直前に伸長したバイトの上位 I<lc> " |-"ビットは、次のバイトと相関関係にあるという前提としています。たとえば通常の英文の場合、英大文字の次にはたいていは小文字が続きます。そしてその小文字の次は、たいていは別の小文字が続きます。また " |+"ビットは、次のバイトと相関関係にあることを前提にしています。たとえば通常の英文の場合、英大文字の次にたいていは小文字が続きます。そしてその小文字の次には、たいていは別の小文字が続きます。また " 第1文、「リテラルの処理では…という前提としています。」では係り受けが合っていません。 第2文～第3文、日本語は「1つの文の中に、同一の助詞で修飾された文節が複数存在すること」を嫌います。第2文の「次にはたいていは」は間に「、」を挟めば違和感が消えますが、読点どうしの間隔が短くなるので、別の方法として「には」→「に」を提案します。第3文の「次は、たいていは」への違和感の度合いは人によって違うと思いますが、とりあえず私の案では直してみました。 |-(中略)というのも、新たなフィルターによるデコード処理は、より大きくなりメモリ消費も増加するはずだからです。" |+(中略)というのも、新たなフィルターはより大きくなり、メモリ消費も増加するはずだからです。" 「デコード処理は、より大きくなり」に違和感を感じます。英語原文では「decoder」という単語を使っていますが（次述）、日本語の「デコード処理」という表現が示す正確な対象はdecoderではなく、「decoding process」だと思います。 英語原文の全体を見てみると「because the decoder of the new filter will be bigger and use more memory.」となっていて、will be bigger というのはプログラムコードのサイズが大きくなることを指していると解します。そこで上記のようにしてみました。 で、実はこの表現だと「メモリ消費も増加するはずだからです。」と微妙に係り受けが合っていません。でも、個人的には違和感をほとんど感じません。もしこれでも違和感を感じる場合には、原文に立ち戻って「より多くのメモリを消費するようになるはずだからです。」と訳し直してもいいと思います。 | msgid "Big or little endian" |-msgstr "ビッグおよびリトルエンディアン" |+msgstr "ビッグエンディアンおよびリトルエンディアン" 英語の原文の係り受け構造は「(big or little) + endian」です。 ところがこの訳を見てみると、第一感としては「(ビッグ) および (リトル + エンディアン)」と読めでしまいます。 そこでこんな長い対案になるわけですが、「ビッグ/リトルエンディアン」や「ビッグエンディアン・リトルエンディアン」あたりでもいいと思います。 英語では endianness という単語を使うこともあるので、それを借用して「エンディアンネス」とする手もありそうです。 | "マシン解析が可能な書式でメッセージ出力を行います。これは liblzma でなく B<xz> " |-"を利用したフロントエンドを容易に構築できるように意図したものです。おそらくは、さまざまなスクリプトを用いることを想定しています。本オプションを使って出力した結果は、B<xz> " |+"を利用したフロントエンドを容易に構築できるように意図したものです。さまざまなスクリプトを用いることが想定されるでしょう。本オプションを使って出力した結果は、B<xz> " | "の将来のリリースに向けて安定して提供していくつもりです。詳しくは B<ロボットモード> セクションを参照してください。" プログラムの設計者本人が「おそらくこれは◯◯を想定しています」という発言をするはずがありません。そういうオプションを設ける意図は、設計者の脳内では当然、明確になっているはずです。 （その意図の中身が「今まで存在していたから何となく」「誰かが何かに役立ててくれるかもしれないから」といった内容であっても、それでも「そういう意図が(少なくとも脳内では)明確になっている」と言えます。） | "ID as a decimal number (one or two digits)." (中略) |-(中略)ここで I<N> は 10 数値 " |+(中略)ここで I<N> は 10 進数 " | "(1 桁または 2 桁) で表されるチェック ID です。" コンピュータの世界で「decimal」はほぼ間違いなく「10進法」か「算用数字」の意味です。 | "B<xz> では環境変数 B<XZ_DEFAULTS> および B<XZ_OPT> " |-"をこの順で、設定された空白区切りのオプションを読み込みます。(以下略) |+"からこの順で、設定された空白区切りのオプションを読み込みます。(以下略) 補語「環境変数XZ_DEFAULTSおよびXZ_OPTを(この順で)」を受ける述語がありません。「読み込みます」の補語は「設定された空白区切りのオプションを」だけです。 そこで前段を「環境変数…『から』」という修飾句にしてみました。 |-(中略)したがって、ゴミデータは無視される扱いである前提で作られているスクリプトは、 |+(中略)したがって、ゴミデータは無視されるという前提で作られているスクリプトは、 「ゴミデータは無視される扱いである前提で…」だと、「ゴミデータは無視される扱いである。前提で…」や「ゴミデータは無視される扱いで、或る前提で…」という感触を受けます。 | "The option B<-T1> for B<xz> is there to force it to single-threaded mode, " | "because B<xargs>(1) is used to control the amount of parallelization." | msgstr "" |-"B<xz> に対してオプション B<-T1> を指定していますが、これは強制的にシングルスレッドモードにします。B<xargs>(1) " |-"は通常は並行処理数を制御するために利用されているからです。" |+"B<xz> に対してオプション B<-T1> を指定していますが、これは強制的にシングルスレッドモードにするためです。" |+"並行処理数の制御のために、既に B<xargs>(1) が使用されているからです。" find … -exec xargs -P数字 … xz … という方法で複数のプロセスを同時に走らせる方法の説明ですが（xargs -P の存在はいま初めて知りました）、明らかな誤訳だと思います。 「xargsは通常は」と問われると、私なら「一つずつ順番に処理していく(＝並列処理ではない)」と答えます。 | "images. It should usually beat PNG, which has a few more advanced filters " | "than simple delta but uses Deflate for the actual compression." (中略) |-(中略)PNG には単純なデルタよりも高度なフィルターをいくつか有していますが、(以下略) |+(中略)PNG には単純なデルタよりも高度なフィルターがいくつかありますが、(以下略) 「PNGには…有しています」の係り受けが合っていません。 「PNGは…有しています」なら、これはこれで十分アリだと思います。 |-(中略)B<xzdec> は処理途中の進行情報は表示しません。つまり " |+(中略)B<xzdec> は処理途中の進行情報も表示しません。つまり " 「進行状況『は』表示しません」だと、「じゃあ他の何かの情報は通常のxzと同様に表示するのか？」という疑問がわきます。ここでは「xzには存在するけどxzdecには存在しないもの」を列挙しているので、「も」に訂正してみました。 |-(中略)必要となるメモリ総量は、数 10 キロバイト＋辞書サイズです。" |+(中略)必要となるメモリ総量は、数十キロバイト＋辞書サイズです。" 「数10」（同様に「数100」「数1000」なども）に個人的には違和感を覚えるのですが、皆様いかがですか？位取り記数法で「10」と書いてある(＝10の位が '1' であると明記されている)にもかかわらず、その前の「数」という単語が「その桁の値は不定である」という意味だからです。 ちなみにこの部分の英語原文は「a few dozen kilobytes plus …」ですが、英語でも「a few 10s」「a few 100s」とは書かないと思います。後者は「a few hundreds」とアルファベットで書くはずです。 ☆ ☆ ☆ ちなみに今回、気になったけど修正提案を見送ったのが > msgid "Trailing garbage" > msgstr "ゴミデータ" です。ここだけを見ると、まるで gomidator という単語をカタカナ書きしたかのような錯覚に陥ります。 個人的にはここの部分だけ「ごみデータ」としたいところですが、「同じ単語の表記は1種類に統一すべし」という意見が世の中の主流と考え、あえてそのままにしました。 （ちなみに私自身は、日本語の「漢字かな交じり」「分かち書きはしない」という表記特性上、漢字ばかり、あるいは平仮名ばかりが続いて文節境界を認識しにくくなる場合は表記揺れをいとわずに可読性を優先すべし、という立場です。木下是雄著『理科系の作文技術』で「木下先生の個人的な好み」と断った上で紹介されているスタイルです。） ☆ ☆ ☆ 以上となります。 長くなりましたがribbonさん、もういちど精査のほどお願いします。 -- 飯嶋 浩光／でるもんた・いいじま ＠ PC IIJIMA Hiromitsu, aka Delmonta Email <delmo****@denno*****> -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: xz.ja_po.diff.zip 型: application/zip サイズ: 7330 バイト 説明: 無し URL: <https://lists.osdn.me/mailman/archives/linuxjm-discuss/attachments/20220521/602ec6fa/attachment-0001.zip>
Fork