Page MenuHomePhabricator

Split up MediaWiki:searchmenu-new-nocreate and give it a descriptive default text
Closed, DeclinedPublic

Description

Author: theevilipaddress

Description:
When you search for a page, and it doesn't exist, there's usually a link where you can create the page. If however, for some reason, you can't create the page, then nothing is shown, only the MediaWiki message [[MediaWiki:searchmenu-new-nocreate]] (empty by default :-(). I believe it should be given some default text so that sites notice that they can customize this part.

Furthermore, I believe that it would be good if the messages could be more informative, possibly by splitting them up. It's not always that clear why it isn't possible: Sometimes you're blocked (might not require a message), the page is protected or the title is invalid. It would be great if the software told me what's the problem about it. If it's protected, then it would probably be good to also add a protection log extract, as it's also widely done elsewhere in the software, and if invalid noting exactly which characters are not valid.


Version: unspecified
Severity: enhancement

Details

Reference
bz26747

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:23 PM
bzimport added a project: MediaWiki-Search.
bzimport set Reference to bz26747.

IMO you're requeting micro-optimisation here. I'm not opposed to creating a default message for what is already there and I am open to suggestions or patches of the part I am not willing to implement.

I change the empty ignored message to the below text in r80746.

'"$1" is an invalid page name or cannot be created by you.'

Closing this bug for now.

'searchmenu-new-nocreate' is deliberately empty by default, and really should rarely if ever actually have content -- see bug 30901.

Recommend revert.

I have reverted r80746 on trunk (r97098) and rel1.18 (r97099). This message should definitely not have default text -- it probably shouldn't exist at all, as it gives non-useful, confusion information.

(That's bug 30900 for the above issue.)

Wontfix per my earlier comment and the revert of an attemPt to resolve.