diff options
Diffstat (limited to 'extensions/BMO/template/en/default/pages/etiquette.html.tmpl')
-rw-r--r-- | extensions/BMO/template/en/default/pages/etiquette.html.tmpl | 42 |
1 files changed, 21 insertions, 21 deletions
diff --git a/extensions/BMO/template/en/default/pages/etiquette.html.tmpl b/extensions/BMO/template/en/default/pages/etiquette.html.tmpl index 281057eeb..8bccaea9d 100644 --- a/extensions/BMO/template/en/default/pages/etiquette.html.tmpl +++ b/extensions/BMO/template/en/default/pages/etiquette.html.tmpl @@ -21,15 +21,15 @@ #%] [% INCLUDE global/header.html.tmpl - title = "Bugzilla Etiquette" + title = "$terms.Bugzilla Etiquette" style = "li { margin: 5px } .heading { font-weight: bold }" %] <p> There's a number of <i lang="fr">faux pas</i> you can commit when using - Bugzilla. At the very + [% terms.Bugzilla %]. At the very least, these will make Mozilla contributors upset at you; if committed enough times they will cause those contributors to demand the disabling of your - Bugzilla account. So, ignore this advice at your peril. + [% terms.Bugzilla %] account. So, ignore this advice at your peril. </p> <p> @@ -47,14 +47,14 @@ <li> <span class="heading">No pointless comments</span>. Unless you have something constructive and helpful to say, do not add a - comment to a bug. In bugs where there is a heated debate going on, you + comment to a [% terms.bug %]. In [% terms.bugs %] where there is a heated debate going on, you should be even more inclined not to add a comment. Unless you have something new to contribute, - then the bug owner is aware of all the issues, and will make a judgement - as to what to do. If you agree the bug should be fixed, vote for it. + then the [% terms.bug %] owner is aware of all the issues, and will make a judgement + as to what to do. If you agree the [% terms.bug %] should be fixed, vote for it. Additional "I see this too" or "It works for me" comments are unnecessary unless they are on a different platform or a significantly different build. - Constructive and helpful thoughts unrelated to the topic of the bug + Constructive and helpful thoughts unrelated to the topic of the [% terms.bug %] should go in the appropriate <a href="http://www.mozilla.org/about/forums/">newsgroup</a>. </li> @@ -63,8 +63,8 @@ <span class="heading">No obligation</span>. "Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but the only person who has any - <i>obligation</i> to fix the bugs you want fixed is you. Therefore, you - should not act as if you expect someone to fix a bug by a particular date + <i>obligation</i> to fix the [% terms.bugs %] you want fixed is you. Therefore, you + should not act as if you expect someone to fix a [% terms.bug %] by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact and interest in your suggestions. @@ -80,17 +80,17 @@ <i>things</i>, not <i>people</i>. Examples of things include: interfaces, algorithms, and schedules. Examples of people include: developers, designers and users. <b>Attacking a person may result in you being banned - from Bugzilla.</b> + from [% terms.Bugzilla %].</b> </li> <li> <span class="heading">No private email</span>. - Unless the bug owner or another respected project contributor has asked you + Unless the [% terms.bug %] owner or another respected project contributor has asked you to email them with specific information, please place all information - relating to bugs - in the bug itself. Do not send them by private email; no-one else can read + relating to [% terms.bugs %] + in the [% terms.bug %] itself. Do not send them by private email; no-one else can read them if you do that, and they'll probably just get ignored. If a file - is too big for Bugzilla, add a comment giving the file size and contents + is too big for [% terms.Bugzilla %], add a comment giving the file size and contents and ask what to do. </li> </ol> @@ -99,19 +99,19 @@ <ol> <li> - <span class="heading">No messing with other people's bugs</span>. - Unless you are the bug assignee, or have some say over the use of their + <span class="heading">No messing with other people's [% terms.bugs %]</span>. + Unless you are the [% terms.bug %] assignee, or have some say over the use of their time, never change the Priority or Target Milestone fields. If in doubt, - do not change the fields of bugs you do not own - add a comment + do not change the fields of [% terms.bugs %] you do not own - add a comment instead, suggesting the change. </li> <li> <span class="heading">No whining about decisions</span>. - If a respected project contributor has marked a bug as INVALID, then it is + If a respected project contributor has marked a [% terms.bug %] as INVALID, then it is invalid. Someone filing another duplicate of it does not change this. Unless you have further important evidence, do not post a comment arguing that an - INVALID or WONTFIX bug should be reopened. + INVALID or WONTFIX [% terms.bug %] should be reopened. </li> </ol> @@ -129,7 +129,7 @@ <p> If you see someone not following these rules, the first step is, as an exception to guideline 1.4, to make them aware of this document by <em>private</em> mail. - Flaming people publically in bugs violates guidelines 1.1 and 1.3. In the case of + Flaming people publically in [% terms.bugs %] violates guidelines 1.1 and 1.3. In the case of persistent offending you should report the matter to <a href="mailto:gerv@mozilla.org">Gerv</a>. </p> @@ -141,7 +141,7 @@ <p> Other useful documents: - <a href="page.cgi?id=bug-writing.html">The Bug Writing Guidelines</a>. + <a href="page.cgi?id=bug-writing.html">The [% terms.Bug %] Writing Guidelines</a>. </p> [% INCLUDE global/footer.html.tmpl %] |