Last modified: 2014-02-12 23:35:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 43935 - Info action's "search engine status" language could use tweaking
Info action's "search engine status" language could use tweaking
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: easy, i18n
Depends on:
Blocks: messages
  Show dependency treegraph
Reported: 2013-01-13 19:42 UTC by MZMcBride
Modified: 2014-02-12 23:35 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description MZMcBride 2013-01-13 19:42:26 UTC

Looking at this page, it currently reads:

Search engine status: Not indexable

I think "Not indexable" is a bit misleading here. The page can still be indexed by search engines (including internal search engines), the page just happens to be marked in such a way that (external) search engines that opt to voluntarily follow the "noindex" directive will not publicly index the page.

Other software packages such as WordPress now use language such as "Search engines discouraged," which I think is more accurate.
Comment 1 MZMcBride 2013-01-13 22:04:54 UTC
Restoring the "easy" keyword following discussion with Krinkle. Bugs marked with "easy" do not need to be explicitly spelled out about how to move forward (e.g., "go to path/to/file.php and change this line"). They just need to be straightforward in the goal.

We can add a separate "thoughtless" or "trivial" category if people would like. I think Nemo is beginning to question the value of the keyword altogether. He may be right, though I like the idea of having an index of easy bugs for people to get involved with. Maybe this would be better served by [[mw:annoying little bugs]].

"Easy" in keywords currently means "this would be a good bug for a new developer to take a stab at." In this case, a new developer might come along, do some thoughtful consideration (as is sometimes required with bugs), and say "what about X or Y?" in a Bugzilla comment or perhaps in a Gerrit changeset. Then we can move forward.
Comment 2 Nemo 2013-01-13 22:13:22 UTC
See URL: I recently had to improve /qqq given the little clarity of the message, but I'm not sure I did it so well.
Comment 3 Richard Guk 2013-01-15 15:36:09 UTC
Assuming that the output relates to robots.txt status (not to internal search), I suggest changing the text to:

"External search: Allowed/Disallowed"


- if the status is based on robots.txt and is not always identical to the internal search indexing, then "External" would be more accurate;

- "status" usually refers to the outcome of a process, which is misleading here because the info is about a setting;

- "Disallowed:" is the standard wording used in robots.txt, so using "Allowed" and "Disallowed" is more consistent and makes the technical meaning more obvious.

Though "Discouraged" would be slightly more accurate for non-technical users, the word is still ambiguous and fails to reflect the robots.txt wording. If you think that "Allowed/Disallowed" are still too confusing, then "External search:" could be linked to or to the article at [[Robots exclusion standard]].
Comment 4 MZMcBride 2013-01-16 01:07:35 UTC
(In reply to comment #3)
> Assuming that the output relates to robots.txt status (not to internal
> search), [...]

The output has no relation to robots.txt, as far as I'm aware. It's related to the noindex value of the meta element's content attribute. For example:

<meta name="robots" content="noindex,follow" />

This HTML element can be controlled per-page on non-content namespaces using the __INDEX__/__NOINDEX__ magic words or per-namespace using global configuration variables.
Comment 5 Richard Guk 2013-01-16 09:57:44 UTC
Well at least I've demonstrated that the current wording is confusing. :/

There are at least four confusable tests:

- robots:noindex meta tag (reported)
- __NOINDEX__ behavior switch (sets meta tag in non-article space)
- robots.txt status (not reported; set independently)
- internal search status (not reported; always true?).

So, to reflect the robots meta value more closely, how about:

"External search: Index / No index"

Stilted grammar, but makes it easier to see that it corresponds to the noindex meta tag.

And, given the potential for confusion, there's a strong case for linking "External search" to an explanatory page such as [[WP:NOINDEX]] or the [[noindex]] article.

(See also bug 42867 for an inconsistency in the reported search status depending on how a page is specified in the URL.)
Comment 6 Gerrit Notification Bot 2013-08-09 18:36:12 UTC
Change 78413 had a related patch set uploaded by Nemo bis:
Clarify info action's "search engine status"
Comment 7 Gerrit Notification Bot 2013-08-10 12:28:01 UTC
Change 78413 merged by jenkins-bot:
Clarify info action's "search engine status"
Comment 8 MZMcBride 2013-08-10 14:28:58 UTC
I'm not sure switching to allowed/disallowed resolves this bug.

Indexing directives are optional. I think using "discouraged"/"encouraged" is a bit clearer here and gives less of an illusion of control. However, nobody else seems to agree, so I'll leave this bug alone for now.
Comment 9 Nemo 2013-08-10 14:36:10 UTC
(In reply to comment #8)
> I'm not sure switching to allowed/disallowed resolves this bug.
> Indexing directives are optional. I think using "discouraged"/"encouraged"
> is a
> bit clearer here and gives less of an illusion of control. However, nobody
> else
> seems to agree, so I'll leave this bug alone for now.

Everything is optional, except law, and almost no web standard are made into laws, so I hope people understand. If you manage to find some other language which is used by anyone but us, it could be borrowed; I agree with you but couldn't find anything better.

"Encouraged" is also not really correct, as merely not disallowing something doesn't mean encouraging it.
Comment 10 MZMcBride 2013-08-10 14:40:10 UTC
External search engines: [discouraged | allowed]

Comment 11 MZMcBride 2013-09-10 01:43:02 UTC
(In reply to comment #10)
> External search engines: [discouraged | allowed]

Sorry, I've been thinking about this bug for nearly a month and I don't agree that it's resolved. I'd really like to see us not use "disallowed" here. I think "discouraged" would be much more accurate, if even if it doesn't have perfect symmetry to "allowed". This imperfect symmetry (discouraged/allowed) best matches reality, I think.

Note You need to log in before you can comment on or make changes to this bug.