351660 - Search UI uses <ShortName> instead of <Description>

Status: RESOLVED WONTFIX

(Firefox :: Search, defect)

Description

[Benjamin Smedberg]

I know this is late for 2.0, but I just discovered a painful inconsistency in the search service that is going to make life very difficult. In each searchplugin, we have <ShortName> and <Description> fields. The <ShortName> is the "key" of the searchplugin, and really should never be displayed in the UI. AFAICT we never use the <Description> in the UI.

This bug is about switching the UI to use <Description> everywhere it currently uses <ShortName>. I'll have a separate bug about an automated process to "fix" the current localized searchplugins which have translated (incorrectly) the <ShortName> field, by putting their translation in the <Description> field.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Why do we want to do this? Is it only because localizers are localizing the wrong field? If so, I'd much rather fix that, or remove the description field from shipped search plugins, than fix this bug - the description field is meant to hold up to 1024 characters of text, which is not a suitable length for display in our search bar.

Comment 2

[Benjamin Smedberg]

Did you see the email I sent? We need an "ID" field that is the same for all the Google searchplugins (and Yahoo, etc), independent of how it's localized. This is so that the searchconfig.properties actually works the way it was intended.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Did you get my reply? :) Searchconfig.properties isn't used anymore.

(In reply to comment #0)
> I know this is late for 2.0, but I just discovered a painful inconsistency in
> the search service that is going to make life very difficult. In each
> searchplugin, we have <ShortName> and <Description> fields. The <ShortName> is
> the "key" of the searchplugin, and really should never be displayed in the UI.
> AFAICT we never use the <Description> in the UI.

ShortName is defined as "A brief name that will appear in buttons, UI controls, etc., that reference this search content provider" (http://opensearch.a9.com/spec/1.1/description/#nametag), which is exactly what we should be using. The fact that it's used as a key in our search service is an implementation detail, and I don't see anything wrong with it - we don't support having multiple engines with the same name, but we never have.

Comment 4

[Benjamin Smedberg]

OK, the fact that the searchengine key is a localized string introduces fragility into the partner build process, but I'm not sure there's much we can do about it now.