元木です。 古いメールから順に見ています。今日コメントするのはこれだけかな。 誰も返事を書いていませんね。まだ3日前のメールなので仕方ないかもしれませんが。 On Thu, May 27, 2021 at 11:27 AM matsuand <michio_matsu****@yahoo*****> wrote: > > matsuand です。 > > # [JM:02426] からの続きとして > > Linux JM ガイド＞翻訳の指針＞セクション名について、 > http://linuxjm.osdn.jp/guide/translation_guideline.html#id7 > に関する協議提案です。 > > 以下、選定した用語(原語とその対訳)と、その提案を 5 項に > 分けて列記します。これに対する是非をあげてください。 > > > 1. ARGUMENTS 引き数 > > [JM:02417] 以降、ある程度協議が進んているため詳述省略。 > > 提案： > "ARGUMENTS" の対訳は「引き数」でなく「引数」とする。 すでに議論されているので、 +1 しておきます。 > > > 2. EXIT CODES 返り値 > > この "EXIT CODES" という単語だけ見ると訳語が「終了コード」 > になると思います。いろいろ言葉の意義を分析することも必要かも > しれませんが、あまり深く議論するつもりでは考えていません。 > 一つだけ傍証的に例をあげてみると、 > 「返り値はありません」という表現は自然ですが、 > 「終了コードはありません」という表現は不自然に感じます。 > ここに両者の違い、用法の違いのヒントがある印象です。 > 原著者の用法どおりの対訳とするのが自然に思います。 > > 提案： > "EXIT CODES" の対訳は「返り値」でなく「終了コード」とする。 「終了コード」がいいと思います。 同様のものに EXIT STATUS がありますが、 これも「終了ステータス」になると思います。 これらは両方ともコマンドの man pages で使われているはずで、 その場合に返り値は適切ではないというのは同意します。 LDP man-pages man-pages.7 でも、以下のような記載があり、 使い分けられています。翻訳でも使い分けるのに賛成です。 EXIT STATUS [Normally only in Sections 1, 8] RETURN VALUE [Normally only in Sections 2, 3] 既存のものをざっと確認しましたが、 EXIT CODES は「終了コード」と「返り値」がありました。 「終了コード」の方が多かったです。 同様に EXIT STATUS については「終了ステータス」「返り値」「終了状態」が ありました。「終了ステータス」が最多でした。 > 3. HISTORY 履歴 (or 歴史) > > 「履歴」はまだわかりますが、「歴史」は大層な表現すぎて > 不適切に感じます。翻訳の個人的経験からは「開発経緯」とする > のがピッタリ合うと感じます。 > > 提案： > "HISTORY" の訳例として「歴史」は削除する。 > "HISTORY" の訳例として「開発経緯」を追加する。 Yes/No で聞かれれば、No に投票します。 本当に「歴史」の場合があります。いろんな実装での移り変わりを 説明しているのであれば、「歴史」が十分に自然な場合もあります。 例えば、 GNU_findutils/original/man1/locate.1 (JM リポジトリに登録のもの; たぶん findutils 4.4.2) では、HISTORY はまさに「歴史」だと思います。 http://linuxjm.osdn.jp/manual/GNU_findutils/original/man1/locate.1 GNU findutils の中での変更だけなら、開発経緯や履歴だと思いますが、 BSD で登場したは「(開発)経緯」というよりは「歴史」に該当すると思います。 20年前の JM 発足時でも「歴史」に近いものもそれなりにありました。 さらに20年たった現在では「歴史」に該当するものもさらに増えていると思います。 > 4. NOTE 注意 > > "NOTE" を「注意」と訳すことは、翻訳の個人的経験からは > 不適切と思い続けている訳語です。 > > この手の英単語は、 > DANGER,WARNING,CAUTION,NOTICE,NOTE,INFO など、注意喚起 > を促す類似語のうちの１つとして捉えられます。 > precautionary statement と呼ぶ言い方があるようです。 > docbook-xml や sphinx では admonition というカテゴリー > のもとに分類されています。 > > Windows において notepad はメモ帳と訳されています。 > "NOTE" は「メモ」と訳すのが適当と捉えています。 > > もし仮に "CAUTION" が併記された場合に、こちらこそ > 「注意」と訳しそうで、そうなると注意のレベルは、 > どちらが上か下かで迷います(翻訳者の立場)。 > (読者にとっては双方とも注意と訳されると、そこに違い > があることは識別できません。) > > "NOTE" には注意を要するレベルの文面は書かれず、ちょっと > 書き留めておく補記情報などが書かれるものと個人的には > 解釈しています。(どこかにこれを定義する規約などがあれば > よいのですが。) > > 提案： > "NOTE" の対訳は「注意」ではなく「メモ」とする。 「メモ」はあまりに軽すぎると感じました。 実際の利用例を見ると、細かな差異や補足情報が書かれていることが多く、 日本語の「メモ」が与える印象よりは「注意」に近いことが多いです。 （少なくとも LDP man-pages においては、そう思います。） 「注意」をとにかく見直したいという場合、 代替案としては「備考」「注記」「補足」などを候補として挙げておきます。 ＃どれか選べと言われれば「注記」に一票入れます。 > 5. PARAMETERS 引き数 > > ARGUMENTS と同じ観点で「引き数」でなく「引数」とする案が > ここにも適用されますが、それよりむしろ「パラメータ」でよい > と思います。(本心は本当は「パラメーター」..長音付き) > > (厳密に調べていませんが) argument と parameter には明確な > 違いが存在すると思っていて、argument は必須の引数のこと > (たとえばパス指定のように、ファイル実体や文字列実体を表すもの)、 > parameter は任意のオプション指定（-I dir とか、処理制御方法 > を切り替えて/付け加えて利用するもの）のこと、と感じています。 上記の認識に関しては、英語でも required argument, optional argument いう言い方は 普通に出てくるので、必須、省略可能で使い分けられていることは思いません。 私のイメージでは、どちらかというと、 argument は、関数やコマンドラインで渡されるもの、 parameter は、渡された値そのもの、です。 例えば、コマンドラインオプションで -o <file> だと、 <file> やその値を格納した変数を parameter と呼ぶイメージです。 英語のドキュメントを読んでいても、両者の区別は非常に曖昧で 適当に使われていることも多いです。 なお、私は python の用語の使い方にかなり影響されている点は否定しません。 例えば https://www.python.org/dev/peps/pep-3102/ です。 この文書で parameter を argument に読み替えると違和感がある箇所は多いです。 > > 提案： > "PARAMETERS" の対訳は「引き数」でなく「パラメータ」とする > (上記が否であった場合、「引き数」でなく「引数」とする) 理由付けには納得しませんが、提案には賛成です。 対訳としては argument と parameter を区別した方がよい、 区別する場合、それぞれ「引数」と「パラメータ(ー)」が妥当な選択に思える、 というのが賛成の理由です。 以上です。
Fork