[gentoojp-docs 323] Re: policy.htmlの差分翻訳

[HAGIHARA Yoshiaki <hagi@xxxxxxx>]

萩原です。

いまさら、かもしれないですが、読んでみました。
差分ではなく、全体を。
で、ツッコミを入れてみます。

＃ちなみに、オリジナルのリビジョンが上がってますね。
＃英文は現在公開されているものを参照したので、
＃的を射てないツッコミがあるかもしれません。

=========================================================================

<全体的なこと>

・Portage treeとPortageツリーが混在してしまってます。
  どちらかに合わせた方が良いですよね。
  正直、どっちでも良いと思うので、
  一番ひとの目に触れているであろうインストールガイドに合わせるのが、
  恐らく最善手かなあと思います。
  で、僕は合わせたつもりで、
  これまでずっとPortage treeとしてたのですが(たぶん)、
  いま見たら、「Portageツリー」となってますね。

  というわけで、どうでしょう。
  今後GentooJPなドキュメント(や雑誌の原稿など)では、
  「Portageツリー」で統一するのは。

  とか書きながら思ったんですが、よく考えたら、
  一番ひとの目に触れてるのって、中野さんのLMの連載ですね。
  LMの原稿って、どっちにしてました？
  なんか、そっちに合わせれば良いのかも。

・「開発者」と「デベロッパー」が混在してるのはナニかなと。

・「マスクされた」というのと「maskする」「unmaskする」が混在してます。
  基本的には後者で統一して良いかなと(他のドキュメントも含め)。

<1.一般的なガイドライン>

・「技術的またはポリシーについての質問をシニア開発者に直接することは、自
    由にして構いません。」

  ちょっと日本語として不自然かなと思うので、
  「自由に質問しても構いません」のようにしてはどうでしょうか。

・「もしcommitがそのtreeに〜すぐに修正されるべきです。」

  文脈から行くと「すぐに修正してください」の方が良いのかなと思いました。
  待ってたら他の人がしてくれるようなニュアンスだったんで。

<2.ebuildポリシー>

・「〜ルールに従っていないパッケージがあります、しかしあなたの〜」

  「、」→「。」

・「そのバージョンは1.2や4.5.2のように2、3以上の部分にピリオドで区切られ
    ています。」

  2や3が、個数のことなのか数字のことなのか、一瞬つかめなかったんで、
  「〜のように2つか3つ(またはそれ以上)の部分に〜」
  とか、そんな感じかなと。

・「suffixのどれもすぐ後に正の整数が続く場合があります。」

  「どれも」というのと「場合がある」というのが両立しないような気がして、
  「suffixの後には正の整数が〜」のような感じで良いかなと思いました。

・「これは次のことをを意味しています。」

  「をを」→「を」

  で、「次のことを」より、
  
  「これはパッケージ名が以下のようなやり方でカウントアップされていくこと
    を意味しています。」

  のようにした方が良いかなと。
  原文は"This means that counting goes as follows:"だったので。

・「バージョン、リビジョンアップ」

  「バージョンアップやリビジョンアップ」の方が良さそうです。

・「これまでにcronパッケージをひとつもインストールしていなかった場合に、
    今後virtual/cronへの依存を満足することになります。」

  「依存を満足する」という言い方が、
  あまり聞いたことがないような気がして、
  ＃単に僕が聞いたことないだけかもしれませんが。
  「依存関係を満たす」とか、その方が良いかなと。

  あと、もう少し原文に忠実な感じで、

  「これまでcronパッケージをひとつもインストールしていなかった場合、これ
    でvirtual/cronに依存している全パッケージがその依存関係を満たすことに
    なります。」

  とか、そんなんはどうでしょうか。

・「注意点として、どのタイプのパッケージでもPROVIDEの値を指定することはで
    きます。」

  ・どんなパッケージでもPROVIDEという値を持つことができる
  ・PROVIDEにはどんなパッケージでも指定することができる
  の両方に取れると思うのです。
  あと、「注意点として」と書くと、
  すこし後とつながりにくくなるような気がします。

  ので、

  「注意点がひとつあります。PROVIDEにはどんなタイプのパッケージでも指定す
    ることはできます。」

  とか、そんな感じではないかと。

・「Gentoo Linuxのvirtual機能の実装は第2のコンポーネントがあります。」

  ここは「もうひとつの特徴があります」ぐらいで良いのかなあと。
  「特徴」が変なら「構成要素」とか。

・「Portageはこのような状態で、profileディレクトリ/etc/make.profileにある
    virtualsという名のprofile-specific virtual mappingファイルを使用する
    ことによって解決します。」

  あまり自信がないのですが、-specific以降って、
  その前の"a profile"の説明ではないかと。

  とすると、

  「Portageはこのような場合profile機能を利用して解決します(profileディレ
    クトリトリ/etc/make.profileに存在する、各virtualには何を割り当てるの
    かが書かれたvirtualsファイルを使用します)。」

  とか、そのような感じではないかいなと。

・「このファイルの1行目は、virtual/lprに依存しているパッケージをインスト
    ルールするとき、まだvirtual/lprが存在しない場合にnet-print/cupsがイ
    ンストールされることを、示しています。」
   
  「インストルール」→「インストール」

  で、修飾(？)する順番を変更して、

  「このファイルの1行目は、まだvirtual/lprが存在しない場合にvirtual/lprに
    依存しているパッケージをインストールすると、net-print/cupsがインスト
    ールされることを示しています。」

  のような感じでどうでしょう。

・「だから、今後virtual/lprへの依存は満足されます。」

  「だから」というのは、突然フレンドリーすぎるかなと。
  あと、やっぱり「満足されます」より、
  「依存関係が満たされます」の方が良いような気がします。

・「この文はデベロッパー向けのガイドラインです。」

  「この文」→「以下の文」もしくは「次の文」

・「新しいvirtualを開発者に情報を長し続けることは、彼らが統一して使用する
    ことを確実にすることになります。」

  「長し」→「流し」

  で、ちょっと読みにくいような気がして、

  「開発者に新しいvirtualについての情報を流し続ければ、使用方法を統一して
    もらうことができます。」

  のような感じではないかと。

・「CVS tree」

  Portageツリーに統一するなら、CVSツリーの方が良いと思います。

・「このタイプのCVS ebuildを以下では"CVS snapshot ebuilds"と呼びます。」

  その後では「スナップショットCVS ebuild」と呼んでいて、
  そっちの方が良いかと思うので、「スナップショット〜」に統一が良いかと。

・「スナップショットCVS ebuildは"live" cvs.eclassよりも大きく好まれます。」

  大きく好まれます、というのがアレかなと思ったので、
  以下のような感じでどうでしょう。

  「スナップショットCVS ebuildの方が、"live" cvs.eclassよりも段違いに歓迎
    されます。」

・「スナップショットCVS ebuildは、CVS スナップショットにソフトウエアに必
    要なよく知られたバグフィクスが含まれている場合、またはCVSバージョンが
    普通のリリースバージョンよりも単純に"良好に動く"場合に許可されます。」

  「スナップショットにソフトウエアに」は「に」が続くので、
  「スナップショット上のソフトウエアに」とか、そういう風でどうでしょう。

  あと、原文だともうひとつ場合があって、
  「あるソフトウエアのCVSバージョンがよく知られている場合」
  もアリの模様です。

・「"live" CVS ebuildや"snapshot" CVS ebuildも、あなたはデベロッパーとし
    て正しく動くことに責任があります。」

  ebuildが正しく動くことに責任があるのか、
  デベロッパーとして正しく行動する責任があるのか、
  ちょっと曖昧だと思うので、

  「〜CVS ebuildであっても、あなたはデベロッパーとしてそのebuildが正しく
    動くことに〜」

  とか、どうでしょうか。

・「しかしこれは"live" CVS ebuildに関しては明白な理由で格段に難しいです。」

  「明白な理由で」というよりは、「当然ながら」ぐらいの方が良いかと。

・「〜永遠に~[arch]キーワードで」

  原文は"for their lifetime"なのと、永遠ってのもナニかなと思うので、
  「ずっとマスクされたままかもしれません」ぐらいで良いのかなと。

・「ユーザーが特に"live" CVS ebuildを要求した場合に、あなたは追加すること
    ができます。」

  もう少し原文に忠実な感じで、

  「どうしても必要だというユーザーがいるようなら、"live" CVS ebuildを追加
    しても良いでしょう。」

  とか(書いてみたらそんなに忠実じゃなかったですが)。

・「もう一度確認すると、これは"live" cvs.eclassを要求する場合にのみ〜」

  ここも、「〜を要求するユーザーがいる場合にのみ〜」かなと。

・「一般ユーザー登録ebuild」

  これは「一般ユーザーが登録したebuild」で良いんじゃないかと。

・「多くのrsyncされるユーザー提供ebuildファイルには、不正なヘッダー行が含
    まれています。」

  「多く」が"rsync"にかかっているように見えるので、

  「rsyncされるユーザー提供ebuildファイルには、不正なヘッダー行が含まれて
    いるものがかなり多いです。」

  とか如何でしょうか。

・「一般的に、あなたがユーザー提供のebuildをきれいにしたいと思う場合以外の
    場合、ebuildを標準のレベルに達っするように変更することをユーザーに要求
    してください。」

  なんとなくなんですが、

  「〜きれいにしたいと思う場合は別として、〜達っするようにユーザー自身に変
    更してもらってください。」

  のような感じかなあと(ただの趣味かもしれません)。

・「ユーザーが自分の間違いから正しいebuildの記述を学習し〜」

  「自分の間違いを元に」の方がわかりやすいかなと。

<3.QAポリシー>

・QAというと、Q&Aのように思えないかなと。
  ので、「品質保証」とした方が読みやすいように思います。

・「Portage管理者だけがmaskやunmaskedすることによって、〜」

  「Portage管理者だけがmaskしたりやunmaskすることによって、〜」

  かなと。

・「そしてそれを行なったら、その緊急の修正はアクセス可能なすべてのデベロッ
    パーの協力によって、〜」

  「そしてそれを行なったら」は、「そしてその際は」とかかなあと。
  あと、「アクセス可能な」は、
  原文のように一応「オンラインでアクセス可能な」の方が良いと思いました。

・「"一人だけ"でするべきではありません。」

  原文のニュアンスを活かすと、

  「"ひとりぼっちの突撃隊状態で"するべきではありません。」

  とか、そんな風かなと。
  あえてそうする必要も無いとは思いますが。

・「〜Portage treeへ~ARCH KEYWORDSで入る前にとてもテストが必要な場合に使
    用されます。」

  「とてもテストが必要」→「充分なテストが必要」、かなと。

  あとここ、原文だと"badly"とかあるんで、
  「残念なことに充分なテストが必要」とか、
  そんな風なのかもしれません。

<4.変数>

・「そしてまた重要なことはバイナリ.tbz2パッケージをインストールする際には、
    RDEPEND依存だけが満足されていれば良いということです。」

  「そしてまたバイナリ〜いれば良いということも重要です」
  の方が読みやすいかなと一瞬思いました。

・「virtual/fooのようにvirtualパッケージへの依存は、複数の異ったパッケー
    ジがvirtual/fooといった同一のインターフェースを持っているときに有効で
    す。」

  元の英文がそもそも読みにくいような気がするんですが、

  「virtual/fooをPROVIDEする複数の異なったパッケージが同一のインターフェ
    ースを提供している場合のみ、virtual/fooのようなvirtualパッケージへ依
    存することができます。」

  とか、そんな感じかなと思いました。

<5.パッケージの移動>

・「最初に内部のメーリングリストで、他の優れた解決方法があるかもしれない
    ので議論すべきです。」

  順番を変更して、

  「他の優れた解決方法があるかもしれませんから、まずは内部のメーリングリ
    ストで議論すべきです。」

  とかどうでしょう。

=========================================================================

-- 
萩原佳明(hagi@xxxxxxx)