こんばんは 又吉です。 パート4です。これで最後です。 査読よろしくお願いします。
-------------------- Cc: Who else should receive e-mail updates on changes to this issue? List the full e-mail addresses of other individuals who should receive an e-mail update upon every change to the issue report. You can enter as many e-mail addresses as you'd like; e-mail addresses must be separated by commas, with no spaces between the addresses. Cc:他の誰がこの issue の最新の変更に関する電子メールを受け取りますか? issue 報告のあらゆる最新の変更に関する電子メールを受け取る他の完全な電子 メールアドレスをリストアップしてください。あなたは好きなだけ多くの電子 メールアドレスを入力できます。アドレスの間には空白を挟まず、コンマ(,)で 区切ってください。 What else can you tell the engineer about the issue? あなたはこの問題に関してエンジニアに伝えることが他にありますか? URL: On what URL did you discover this issue? If you encountered the issue on a particular URL, please provide it (or, them) here. URL:どんな URL でこの問題を見つけましたか? あなたが、特定の URL で問題に遭遇するならここにそれを(もしくはそれらを) 入力してください。 Summary: How would you describe the issue, in approximately 60 or fewer characters? A good summary should quickly and uniquely identify an issue report. Otherwise, developers cannot meaningfully query by issue summary, and will often fail to pay attention to your issue report when reviewing a 10 page issue list. 要約: あなたは60文字以内でどのように問題を説明しますか? 良い要約は、 issue 報告を早く、そして、ユニークに特定できなければなりま せん。でなければ、開発者は、問題要約によって意味のある質問を行えず、しば しば１０ページの issue リストを再検討するときあなたの issue 報告に注意を 払うことができないでしょう。 A summary of "Abort trying to install on RedHat 7.0, Kernel 2.2.14" is a useful title. "Software fails" or "install problem" would be examples of a bad title. タイトル"RadHat 7.0 の Kernel 2.2.14 上でインストール中に失敗"は良い要約 です。"ソフトウェアは失敗","インストールの問題"は悪いタイトルです。 Description: What else can you tell the engineer about this issue? Please provide as detailed of a problem diagnosis in this field as possible. A precise step-by-step description is the best way to do it. For crashing issues it might help to have additional information in case you're able to provide that: 説明:あなたはこの問題に関して他のエンジニアに伝えることがありますか? このフィールドには、可能ならばその問題点の詳細をできる限り入力してくださ い。正確に段階ごとに説明するのが一番良いでしょう。 クラッシュの問題の場合、下記の追加情報を提供できれば役立つかも知れません。 Target Milestone: Think of it as a deadline; targets are "not determined" or "next build"--for most issues, stipulate "not determined." 目標のマイルストーン: それを最終期限と見なしてください。目標は "not determined"(未定)もしくは、 "next build"(次のビルド) -- ほとんどの問題に は、 "not determined"を指定してください。 Attachments. It may be the case you need to add an attachment(s) to an Issue, either the one you file or another one. You can do it; the limit is 10MB, but please keep any attachment small, as most people use 56K connections. Attaching a file to an issue is a two-step procedure and is not obvious. You must first submit the issue or locate the issue to which you wish to attach the file. Then, you can add the file as an attachment to that issue. There will be a link in the issue body that reads: 添付。あなたが issue に添付を必要とするケース(あなたのファイルか他人の ファイル)。限界は10MBですが、ほとんどの人が56Kの接続を使用するので添付は 小さくしておいてください。 issue にファイルを添付するには2段階の手順が必 要で明白ではありません。最初に issue を登録するか、またはファイルを添付 したい issue を見つけなければなりません。そして、あなたは issue に添付で きます。それは issue の本文にリンクとして加えられるでしょう。 Create a new attachment (proposed patch, testcase, etc.) 新しい添付(提案パッチ、テストケース、その他)を作成してください。 Note: You cannot add OpenOffice.org files natively. They must be added as "binary" files. This is a temporary problem. 注意: あなたは最適化された OpenOffice.org のファイルを加えることができま せん。それはバイナリファイルとして加えなければなりません。これは一時的な 問題です。 Hints: Reduce the size of your file as much as possible. And, if you are uploading an HTML document, be sure to compress it first (Zip or tar it), otherwise it gets corrupted when others try to download it. ヒント:ファイルのサイズをできるだけ減らしてください。それが、HTML文書な らば先に圧縮してください(Zip または tar)。他の人がダウンロードするときに 壊れます。 You're done! After double-checking your entries for any possible errors, press the "Commit" button, and your issue report will now be in the IssueTracker database. これで終わりです。考えられるあらゆる間違いのためにあなたの記入を再確認し た後に、"Commit"(訳注:課題の実行)ボタンを押してください。そうすれば、あ なたの issue 報告は IssueTracker データベースにあるでしょう。 (These Bug Writing Guidelines were originally written for Mozilla by Eli Goldberg. Thanks to Claudius Gayle, Peter Mock, Chris Pratt, Louis Suarez-Potts, Tom Schutter, and Chris Yeh for contributing to this document. Constructive suggestions and feedback is welcome. In this case just post your suggestions to the d...@qa mailing list.) (これらのBug Writing GuidelinesはもともとはMozillaのためにEli Goldbergに よって書かれました。この文書に貢献してくれたClaudius Gayle, Peter Mock, Chris Pratt, Louis Suarez-Potts, Tom Schutter, and Chris Yehに感謝しま す。有益な意見とフィードバックを歓迎します。この場合 ...@qa メーリング リストにあなたの提案を提示してください。) -------------------- 以上です。 かなり多いですが、査読をよろしくお願いします。 -- --------------- N.Matayoshi --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
