| 前のトピックを表示 :: 次のトピックを表示 |
| 著者 |
メッセージ |
山口
登録日: 2003年5月 23日
記事: 2920
    |
 件名: Bugzilla でするべき事としてはいけない事 投稿時間: 2005年1月31日(月) 09:18 |
 |
|
Nobuyuki さんから次の草稿を頂きました。
用語の翻訳で若干自信がないとのコメントもあわせていただいていますので、皆さんのコメントをどうぞよろしくお願いします。 |
|
 |
池田
登録日: 2003年5月 22日
記事: 408
所在地: 東京
|
| 件名: Re: Bugzilla でするべき事としてはいけない事 投稿時間: 2005年2月18日(金) 15:11 |
|
|
Nobuyuki さん、池田です。
放置していて申し訳ありません。
草稿は拝見して、問題点のピックアップも終わっているのですが、
別件で多忙のため、週末までコメントできそうにありません。
もうしばらくお待ちください。
____________________
Mozilla Japan 翻訳部門 和訳アドバイザー |
|
|
Nobuyuki
登録日: 2004年11月 18日
記事: 204
|
| 件名: 了解しました。 投稿時間: 2005年2月18日(金) 23:51 |
|
|
Nobuyuki です
了解しました。
山口さんもまた、お忙しそうですね・・・・・
以上 |
|
|
池田
登録日: 2003年5月 22日
記事: 408
所在地: 東京
|
| 件名: Re: Bugzilla でするべき事としてはいけない事 投稿時間: 2005年2月20日(日) 18:35 |
|
|
Nobuyuki さん、池田です。
| Quote: | | 1. Bugzilla の権限を取得/更新する |
原文 upgrade ですから、更新ではなく、昇格・昇級でしょう。
うまくはまる日本語が思いつかないので、
→ 1. Bugzilla の権限を取得/グレードアップする
| Quote: | | 2. canconfirm 権限を与えられる際の権利と義務 |
原文 having ですので、
→ 2. canconfirm 権限所有者の権利と義務
| Quote: | 3.1. バクを決定する
3.2. バグを検証する
3.4. バグを再設定する |
Bugzilla に関する文書の和訳には、Bugzilla の知識と Bugzilla-jp の知識が必要です。
また、もしまだお読みでなければ 「はじめてのバグジラ ver2.16-ja 編」もお読みください。
これらの知識なしに訳すことは、Mozilla を使ったことのない人が Mozilla 関係の文書を訳すのと同じです。
resolve は「決定」ではなく「解決」です。
verify は「検証」ではなく「確認」です。
reassign は「再設定」ではなく「再割り当て」です。
（個人的には、「再割り当て」よりは「担当者変更」かなんかの方が適切のような気はしますが）
以下、いちいち細かい用語の指摘はしませんが、上記 URL をご参照の上、修正してください。
| Quote: | | この文書はバクの対応優先順位を決めるために Bugzilla の権限の使用をその適応範囲とします |
バグの triage には、優先順位を決める以外にも、バグであるかないかを決めることも含まれます。
また、「適応範囲」は誤りではありませんが、少し固い訳だと思います。
→ この文書は、バクを振り分けるための Bugzilla 権限の使用法についてのものです。
| Quote: | | Bugzilla の権限の取得要件も Gerv's で説明されています。 |
page が抜けてます。
→ Bugzilla 権限の取得要件も Gerv のページで説明されています。
| Quote: | | 上記の 2 つの手引きで説明されていますが、優先付けの工程の完了後、NEW の状態にあるバグは報告されるべきです。 |
→ 上記の 2 つの手引きで説明されている振り分け作業を行なったバグは、NEW として報告するべきです。
| Quote: | | 新しいバグが古いバグより多くの情報（バグ記述クリア機能[草稿訳注：でいいかな？clearer の定訳は？]、すでに当てられたパッチ、すでに CC を送られた多数の人たち等）を含む時以外は、一般的に新規のバグは古いバグの DUPLICATE として扱われるべきです。 |
→ 一般的に新規のバグは古いバグの DUPLICATE として扱われるべきですが、新しいバグの方が情報量が多い場合（バグの記述がより明瞭、パッチがすでに添付されている、多くの人が CC している、等々）は例外です。
| Quote: | | バグ報告の対象となるビルドは過去 2 回以上安定してリリースされており、 |
→ バグ報告の対象となっているビルドが、安定版 2 回以上古いリリースであり、
| Quote: | | 替わりに Tech Evangelism（草稿訳注：技術伝道くらいの意味？) 製品へと移動されるべきです。 |
リンク先の 和訳文書 では「テクノロジー・エバンジェリズム」になっていますが、ここはプロダクト名なので英語のままでいいでしょう。
→ Tech Evangelism プロダクトへと移動されるべきです。
| Quote: | | もう再現されないバグは、単一のチェックインにリンク出来ない限りは、FIXED ではなく WORKSFORME として扱って下さい。 |
→ 再現できなくなったバグは、一つのチェックインに関連付けられない場合、FIXED ではなく WORKSFORME として扱って下さい。
| Quote: | | 通常のバグの優先付け担当（草稿訳注：triager の訳はこれでいいか？）によってバグは WONTFIX と扱われるべきではありません。 |
→ 普通の振り分け担当者は、バグを WONTFIX とするべきではありません。
→ OS やハードウエアの項目
| Quote: | | blocker はまず使われるべきではありません。 |
→ 重要度を blocker としなければならない頻度はほとんどありません。
| Quote: | | Mozilla の開発を妨げるのは数十万のバグがある場合で、これらのバグは普通たちどころに修正されてしまうからです。 |
→ Mozilla の開発を妨げるのは数十万のバグのうちのほんの一握りであり、そういうバグは普通すぐに修正されてしまうからです。
| Quote: | | 重大なセキュリティ乱用（任意コードのリモート実行等）に関する報告は一番の重要性があります。 |
→ 重大なセキュリティ脆弱性（任意コードのリモート実行等）に関するバグ報告の重要度は critical です。
| Quote: | | もしバグが Application Suite に存在するならば、また必ず Application Suite のThunderbird や Firefox のバグをテストし、バグを中核的製品の一つに移動して下さい。 |
→ Thunderbird や Firefox のバグを Application Suite でもテストし、もしバグが Application Suite でも再現したなら、バグをコア・プロダクトのどれかに移動するようにして下さい。
| Quote: | | たとえば、バグが JS エンジンのバグである事を実際に知らないならば、それらを JS エンジン Component へ、移動させないで下さい。そして、記述されている異常が DOM 問題であると知っているならば、バグを JS エンジンへ置かないで下さい。 |
→ たとえば、バグが JS エンジンのバグである事を熟知している場合以外は、JS エンジン・コンポーネントへの移動を行なってはいけません。そして、記述されている異常が DOM 問題であると知っているならば、バグを JS エンジンのまま放置しないで下さい。
コメントは以上です。
以下、個人的な希望です。
今後も和訳作業を続けていただけるようですので、ご自分のウェブスペースをお持ちになって、
草稿をそちらで公開していただけないでしょうか。
無料のウェブスペースは、翻訳部門の FAQ にリンクがあります。
というのも、他の人がコメントを付けた草稿をそのあとに見直す場合、草稿がアップデートされていないと、
コメントを付ける作業に非常に時間がかかるのです。
お手間とは思いますが、ご配慮いただければ幸いです。
____________________
Mozilla Japan 翻訳部門 和訳アドバイザー |
|
|
Nobuyuki
登録日: 2004年11月 18日
記事: 204
|
| 件名: Bugzilla をトライして 投稿時間: 2005年2月21日(月) 23:58 |
|
|
Nobuyki です。
詳細に review をいただきありがとうございました。
細かな誤訳も多く、反省仕切り  です。ご指摘いただきましたように、やはり、前提となる情報をよく理解してかから
ないと、正確な和訳ができないと思います。
その中で、一つ質問ですが、
"resolve a bug" の訳ですが、「バグを解決する」とすると、バグを修正して完全に取り除くという意味にもとれますが、
この文脈では、triage の結果どの種類[INVARID、,FIXED、WONTFIX など]のバグがを決める事を resolve と
言っているようで、むしろ「決定する」に近いかなと思いましたがいかがでしょうか。
また、website の件ですが、ご指摘の点は自分でも不自由さを感じておりました。 そこで、できるだけ速く
トライしてみたいと思います。分からないことも多々出てl来るかもしれませんが、その時はまた教えて下さい。 Try first！
then make it better!, 翻訳も同じですね。
以上 |
|
|
池田
登録日: 2003年5月 22日
記事: 408
所在地: 東京
|
| 件名: Re: Bugzilla をトライして 投稿時間: 2005年2月22日(火) 16:40 |
|
|
池田です。
| Nobuyuki wrote: | その中で、一つ質問ですが、
"resolve a bug" の訳ですが、「バグを解決する」とすると、バグを修正して完全に取り除くという意味にもとれますが、
この文脈では、triage の結果どの種類[INVARID、,FIXED、WONTFIX など]のバグがを決める事を resolve と
言っているようで、むしろ「決定する」に近いかなと思いましたがいかがでしょうか。 |
おっしゃる通りです。
私の前の投稿で、reassign について文句をたれてますが、
実際に行なわれている事を踏まえた上で "resolve a bug" を訳すのであれば
「バグを処理する」の方が適切かもしれません。
ただ、FIXED 以外の resolution が取られるバグは、
実はバグジラで修正方法を検討するべきバグではないもの（仕様とか重複とか操作ミス）であり、
これらを除いた本物のバグの resolution は FIXED が望ましいわけです。
言葉を替えて言えば、FIXED 以外の resolution は、バグではない事を確定するという解決ですし、
それらの resolution が付かないバグは Fix が必要なものという事になります。
そして、そういうバグを RESOLVED, FIXED にするために、
バグジラの関係者は日夜努力しているのです。
ですので、この文書を読むような人にとっては、「バグを解決する」で問題ないと思います。
どうしても「バグを解決する」に違和感があるようでしたら、「バグを処理する」をお勧めします。
____________________
Mozilla Japan 翻訳部門 和訳アドバイザー |
|
|
|
よくある質問
検索
登録ユーザ一覧
グループ
登録
ユーザ設定
ログインして PM を確認
ログイン