When entering a bug I need to select the "Platform" (For instance the Platform is PC on this page), when I go to view an existing bug the "Platform" is now shown as "Hardware" it is also listed as "Hardware" on the advanced search page. For consistancy if I enter a "Platform" in the new bug page when I try to look it up the other pages should show the entry as "Platform". So for consistency all the entries for this field should be either "Hardware" or "Platform" not a mix of both. Believe it or not I found this confusing when I tried to find the "Platform" field on the other pages mentioned. This seems to be an issue on all versions including this 2.19.1 installation, I am just using 2.18rc3 at work so I am reporting the bug as such Thanks

I have also noticed when you click on the Hotlink in the new bug page for "Platform" it takes you to a help page telling what a "platform" is. When you click on the "Hardware" link on the advanced search page, it also takes you to the help which shows what a "Platform" is. This is also inconsistant. Finally, when viewing a bug-> You can the "Hardware" field does not have a hyperlink to the help description. Since a help description is available the "Hardware" tag should be hyperlinked to it.

Tiago, interested in taking this bug? You did a similar work about owner/assignee already. And I agree with the reporter, it's confusing.

Comment on attachment 186845 [details] [diff] [review] v1: hardware instead of platform. platform is more generic and will thereby be better suited for more customers than hardware. personally i want this word to live in $terms

Comment on attachment 186922 [details] [diff] [review] v3: missing a word. >Index: docs/xml/administration.xml >- As a guide, on reasonably old hardware, mozilla.org began needing >+ As a guide, on reasonably old platform, mozilla.org began needing > <quote>shadowdb</quote> when they reached around 40,000 Bugzilla > users with several hundred Bugzilla bug changes and comments per day. this change is wrong :). >Index: template/en/default/bug/edit.html.tmpl >@@ -149,7 +149,7 @@ >- <b><u>H</u>ardware:</b> >+ <b>[% terms.Platform %]:</b> > [% PROCESS select selname => "rep_platform" accesskey => "h" %] add (and use) terms for $terms.Platform_withaccesskey and $terms.platform_accesskey >Index: template/en/default/global/variables.none.tmpl >+ "Platform" => "Platform" >+ "Platforms" => "Platforms" >+ "platform" => "platform" >+ "platforms" => "platforms" >Index: template/en/default/pages/fields.html.tmpl >@@ -254,12 +254,12 @@ available priorities range from <b>P1</b >+ <li>All (happens on all [% terms.platforms %]; cross-platform [% terms.bug %])</li> add term for $terms.cross_platform >Index: template/en/default/search/form.html.tmpl >@@ -384,7 +384,7 @@ function doOnSelectProduct(selectmode) { >- <th align="left"><u>H</u>ardware:</th> >+ <th align="left">[% terms.Platform %]:</th> > [% PROCESS select sel = { name => 'rep_platform', use terms for $terms.Platform_withaccesskey and $terms.platform_accesskey

timeless, Can I ask for approval?

Comment on attachment 187062 [details] [diff] [review] v4: some fixes >Index: template/en/default/bug/edit.html.tmpl >@@ -149,9 +149,9 @@ >+ <b>[% terms.Platform_accesskey %]:</b> i wish this term was different Platform_w_accesskey or something >+ [% PROCESS select selname => "rep_platform" accesskey => "l" %] imo this "l" should be terms.platform_accesskey >+ "cross_platform" => "cross-platform" >Index: template/en/default/pages/fields.html.tmpl >@@ -254,12 +254,13 @@ available priorities range from <b>P1</b >+ <li>All (happens on all [% terms.platforms %]; [% terms.cross_platform %] >+ [% terms.bug %])</li> probably should be "a cross-platform bug" for English...

Comment on attachment 187062 [details] [diff] [review] v4: some fixes Please don't make API modifications to bugzilla-submit. Real places use it and you'll break them. Also, despite what the field is named on the back-end, I'd rather we went with "Hardware" as the consistant term in the UI. Platform is too ambiguous. (Windows is a platform, and so is Linux, but neither of those are the type of information that field is looking for)

ccing some people whose opinions will be worthwile as this has come up again in irc.

This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2. This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

Fixed by bug 458436 a long time ago (Bugzilla 3.4).