From 2478a13d479563c23347de222e3da2ed34d71508 Mon Sep 17 00:00:00 2001
From: "timeless%mozdev.org" <>
Date: Fri, 19 Mar 2004 00:21:56 +0000
Subject: Bug 237772 instances of "a terms.bug" should be replaced with
 "terms.abug" also fix the spelling of decipher r=gerv r=kiko a=justdave

---
 template/en/default/pages/bug-writing.html.tmpl | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

(limited to 'template/en/default/pages/bug-writing.html.tmpl')

diff --git a/template/en/default/pages/bug-writing.html.tmpl b/template/en/default/pages/bug-writing.html.tmpl
index 1a228b0c4..c007b043b 100644
--- a/template/en/default/pages/bug-writing.html.tmpl
+++ b/template/en/default/pages/bug-writing.html.tmpl
@@ -31,7 +31,7 @@
 <h3>Why You Should Read This</h3>
 
 <blockquote>
-  <p>Simply put, the more effectively you report a [% terms.bug %], the more
+  <p>Simply put, the more effectively you report [% terms.abug %], the more
   likely an
   engineer will actually fix it.</p>
 
@@ -57,7 +57,7 @@
 
     <li><b>Specific.</b> The quicker the engineer can isolate the 
     [% terms.bug %] to a specific area, the more likely she'll expediently 
-    fix it. (If a programmer or tester has to decypher a [% terms.bug %], 
+    fix it. (If a programmer or tester has to decipher [% terms.abug %], 
     they may spend more time cursing the submitter than solving the 
     problem.)<br>
     <br>
@@ -163,7 +163,7 @@
     <p><b>Assigned To: Which engineer should be responsible for fixing
     this [% terms.bug %]?</b><br>
     [% terms.Bugzilla %] will automatically assign the [% terms.bug %] to a
-    default engineer upon submitting a [% terms.bug %] report. If you'd prefer
+    default engineer upon submitting [% terms.abug %] report. If you'd prefer
     to directly assign the [% terms.bug %] to someone else, enter their e-mail
     address into this field. (To see the list of default engineers for each
     component, click on the Component link.)</p>
@@ -181,7 +181,7 @@
   <blockquote>
     <p><b>Summary:</b> <b>How would you describe the [% terms.bug %], in 
     approximately 60 or fewer characters?</b><br>
-     A good summary should <b>quickly and uniquely identify a [% terms.bug %]
+     A good summary should <b>quickly and uniquely identify [% terms.abug %]
     report</b>. Otherwise, an engineer cannot meaningfully identify your
     [% terms.bug %] by its summary, and will often fail to pay attention to 
     your [% terms.bug %] report when skimming through a 10 
@@ -323,7 +323,7 @@ PowerPC unmapped memory exception at 0B512BD0 NSGetFactory+055F0
     mix a handful of [% terms.bugs %] into a single report, the right people 
     probably won't discover your [% terms.bugs %] in a timely fashion, or at 
     all. Certain [% terms.bugs %] are also more important than others. It's 
-    impossible to prioritize a [% terms.bug %] report when
+    impossible to prioritize [% terms.abug %] report when
     it contains four different issues, all of differing importance.</p>
 
     <p><b>No [% terms.bug %] is too trivial to report.</b> Unless you're 
-- 
cgit v1.2.3-24-g4f1b