275573 - Platform and Hardware are used interchangeably on various pages

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect, P2)

Description

[Mark McCraley]

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

Comment 1

[Mark McCraley]

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.

Comment 2

[Frédéric Buclin]

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 3

[Tiago Mello [:timello]]

Attachment: v1: hardware instead of platform.

Comment 4

[timeless]

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 5

[Tiago Mello [:timello]]

Attachment: v2: platform using $terms

Comment 6

[Tiago Mello [:timello]]

Attachment: v3: missing a word.

Comment 7

[timeless]

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

Comment 8

[Tiago Mello [:timello]]

Attachment: v4: some fixes

Comment 9

[Tiago Mello [:timello]]

timeless, Can I ask for approval?

Comment 10

[timeless]

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 11

[Dave Miller [:justdave]]

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)

Comment 12

[Majken Connor [:Kensie]]

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

Comment 13

[Frédéric Buclin]

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".

Comment 14

[Max Kanat-Alexander]

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.

Comment 16

[Frédéric Buclin]

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.

Comment 17

[Frédéric Buclin]

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