565300 - Update category names to match those from the design document

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a5pre) Gecko/20100511 Minefield/3.7a5pre ID:20100511030640

On bug 557240 we switched back to the category naming for older releases. Given by the design documents we will have to use the new names at some point. This bug should track that work.

Category names right now are:
* Get Add-ons
* Languages
* Search Engines
* Extensions
* Appearance
* Plugins
* Updates

Adding uiwanted to make sure we will get the final list of category names.

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

There's been a lot of discussion specifically about the naming of the "Get Add-ons"/"Discover" pane. I'll summarize:

* "Get Add-ons" is seen as more descriptive, and potentially a lot easier to understand for people who won't know much about addons
* "Discover" conflicts with addons that provide discovery services
* There have been troubles localizing "Get Add-ons" - whereas "Discover" is seen as an easier phrase to localize while keeping its meaning

Comment 2

[Jennifer Morrow [:Boriss] (UX)]

Marking dup of Bug 553473.  As Blair said, we're keeping "Get-Addons" now

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This bug is not only about "Get Addons" vs. Discover. Bug 553473 is definitely a part of it and I was aware of that bug when I have filed this one. Comparing the current design docs with the implemented category names shows a difference for the Themes vs. Appearances panel name. The other ones look fine but would need a clear definition we can work with.

Comment 5

[Dave Townsend [:mossop]]

Needed by string freeze

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

The only string change needed here is "Themes" -> "Appearance" (but it needs changed in 2 places). 

Sadly, changing the entity name in extensions.properties is painful/not sanely possible while the appearance pane is implemented by the list view (since it determines the entity name programatically). Thankfully, this is changing (by work done in bug 520124), so once that's done, this will be trivially easy.

Comment 7

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Er, and by "painful", I mean without special casing it. Its not possible to do it *nicely*.

Comment 8

[Dave Townsend [:mossop]]

Well I was actually making that change in bug 520124 so I might as well just own this for now.

Comment 9

[Dave Townsend [:mossop]]

Now that we aren't making the new appearance pane do we still want to name it Appearance or do we stick with Themes?

Comment 10

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #9)
> Now that we aren't making the new appearance pane do we still want to name it
> Appearance or do we stick with Themes?

Its still about changing the appearance, and not solely about normal themes. The purpose hasn't changed, just the UI for it. So I'd say keep it as Appearance.

Comment 11

[Dave Townsend [:mossop]]

Attachment: patch rev 1

Well now the header text is gone this is somewhat easier to do anyway.

Comment 12

[Dave Townsend [:mossop]]

Landed: http://hg.mozilla.org/mozilla-central/rev/7c33210d1052

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with builds on all platforms like Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b6pre) Gecko/20100902 Firefox/4.0b6pre