[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

中野です
# 大変遅くなりました…。一ヶ月以上あいている。

http://gentoojp.dip.jp/chk/data/20030824012955.html です。

> ＃ちなみに、オリジナルのリビジョンが上がってますね。

翻訳1.19に合わせました。なので、またつっこみを頂けると嬉しいです。

原文の差分
https://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/policy.html.diff?r2=1.19&cvsroot=gentoo&r1=1.16&diff_format=l

ちょっと質問なのですが、萩原さんの作業的に、ただ「修正しました」の場合
にはばっさりカットしてしまった方がいいですか？それとも今回のようにした方
がいいですか？

では、内容に入ります。

> <全体的なこと>
> 
> ・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ファイルを使用します)。」
> 
>   とか、そのような感じではないかいなと。

ちょっと違うように解釈しました。その上で一文だと読みにくかったので、
以下のようにしてみました。どうでしょうか？

    Portageはこのようなときに、各virtualには何を割り当てるのかが書かれ
    た<path>virtuals</path>という名前のファイルを使用します。このファ
    イルはprofileディレクトリ<path>/etc/make.profile</path>に保存され
    ています。

> ・「このファイルの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.パッケージの移動>
> 
> ・「最初に内部のメーリングリストで、他の優れた解決方法があるかもしれない
>     ので議論すべきです。」
> 
>   順番を変更して、
> 
>   「他の優れた解決方法があるかもしれませんから、まずは内部のメーリングリ
>     ストで議論すべきです。」
> 
>   とかどうでしょう。
> 

修正しました

以上です。
萩原さんの指摘はいつもすごく勉強になります。
ありがとうございました。