Template talk:Editnotices/Namespace/Main

This is the talk page of the namespace notice for the Main space.
Template:Editnotices/Namespace/Main can only be edited by administrators. All editnotices (except those in userspace) are protected via MediaWiki:Titleblacklist, so the "protection" status as set by the protection tab is mostly irrelevant.

Lowercase all parameters?

{{editprotected}}

Wouldn't it be best to lowercase all the parameters in this template, so that capitalization isn't an issue? Since Template:TFA title/June 19, 2010 uses "choral symphony" when {{PAGENAME}} will return "Choral symphony"? Gary King (talk) 19:06, 16 June 2010 (UTC)[reply]

Good catch!
I'll ask the Anomie first whether he can get the page names into a canonized form, so that all other users of the template get the clean title as well.
FWIW, ignoring capitalization would be a bit too much, but wrapping it like {{FULLPAGENAME:{{TFA title}}}} would canonize most titles.
Thanks, Amalthea 19:16, 16 June 2010 (UTC)[reply]

Protected edit request on 8 March 2016

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Add {{#ifexist:{{FULLPAGENAME}}||{{#ifexist:Draft:{{FULLPAGENAME}}|{{Hatnote|There exists a draft for this article at [[Draft:{{FULLPAGENAME}}]]}}|}}}}. The message would be displayed whenever someone is creating an article for which a draft already exists. Such a message is already shown on MediaWiki:Noarticletext (see edit request) but I think this is required here too because whenever a registered user clicks on a red link or enters the name of an inexistent article into the search box, they are directly taken to the page creation interface; they never pass through MediaWiki:Noarticletext at all. Ultimately, the aim is to improve the discoverability of existing drafts.

103.6.159.68 (talk) 14:04, 8 March 2016 (UTC)[reply]

Tweak: Good rationale, but, pending discussion at Template talk:No article text over the phrasing, I'd prefer this use the simpler "is" rather than "exists" and that (regardless of whether "is" or "exists" is chosen) the two messages match. {{Nihiltres |talk |edits}} 15:37, 8 March 2016 (UTC)[reply]

Good idea. It won't deal with all the cases, but it will help somewhat. I think there's agreement to use the simpler "is" DGG ( talk ) 19:17, 8 March 2016 (UTC)[reply]

Done. The effect can be seen at Gian Francesco di San Giorgio Biandrate Aldobrandini. I would prefer to put the message in {{fmbox}} rather than {{hatnote}} for consistency with other edit notices. — Martin (MSGJ · talk) 09:10, 9 March 2016 (UTC)[reply]

Template-protected edit request on 26 February 2017

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

REQUEST: Display an edit notice to all new/unconfirmed users editing a page. I think it's a good idea to display an edit notice to registered, unconfirmed users that they are, in fact, editing Wikipedia. This will reduce the amount of test edits and unconstructive additions by new users. I've made a draft of this template at Template:Notice newuser. I also proposed this at the Village Pump; User:Xaosflux said that with some "CSS hacks" it could be rendered invisible for autoconfirmed/confirmed users. (I don't know where to ask about getting those into place, possibly at the "Technical" village pump.) MereTechnicality ⚙ 03:55, 26 February 2017 (UTC)[reply]

Note: the .css hacks have NOT been built yet! (c.f. MediaWiki:Group-autoconfirmed.css, MediaWiki:Common.css) — xaosflux ^Talk 04:46, 26 February 2017 (UTC)[reply]

This is a good idea, but there are a few things to consider before implementing this. We should be especially careful to encourage good faith users to edit, discouraging bad faith users to edit is secondary. Template:Notice Anti-vandalism was designed for pages with a long history of vandalism, so for a small subset of articles. In contrast, this would apply to all articles. Currently it is too long and emphasizes vandalism too much. This should be closer to Template:TFA-editnotice. We should also probably use a different wording on pending changes protected pages as the edit will not actually go love immediately. I'll make the necessary technical modifications and suggest wording changes. Cenarium (talk) 08:27, 26 February 2017 (UTC)[reply]
I've made the technical changes and brought the wording closer to that of the TFA editnotice, let me know what you think. Cenarium (talk) 09:02, 26 February 2017 (UTC)[reply]
I think it looks good. You're right about it accidentally discouraging new users, the wording change is a lot less bitey. MereTechnicality ⚙ 16:28, 26 February 2017 (UTC)[reply]

So what now? Should I ask for consensus? And if so, where? MereTechnicality ⚙ 22:01, 26 February 2017 (UTC)[reply]
Since this will affect a lot of people, I think we should be careful and wait to see if there are still improvements to be made. You could post a notice at WP:VPR asking for people to comment here. I'll also ping MusikAnimal and Kaldari who worked on the new page creation notice in case they have suggestions. Cenarium (talk) 16:09, 27 February 2017 (UTC)[reply]

Another proposition: a special edit notice for new page creation by unconfirmed users, saying that page creation is hard and to direct them to the article wizard as well as relevant guidelines (like BLP, notability, verifiability). MereTechnicality ⚙ 22:11, 26 February 2017 (UTC)[reply]
There is already one, see Template:Newarticletext-unconfirmed. Cenarium (talk) 16:09, 27 February 2017 (UTC)[reply]
Didn't know we had that. Okay. MereTechnicality ⚙ 19:05, 27 February 2017 (UTC)[reply]
I think this is quite nice, but mind you we have an edit filter that warns about common test edits. If you see "hi", "test" among other obvious test edits the user may have been intentionally adding them. On that note maybe MediaWiki:Abusefilter-warning-test-edit should be rewritten to be more prominent, in case they miss it (many ignore plain text edit notices). Finally, don't forget these edit notices aren't shown on mobile, so if you're see edits with the tag "mobile web" it's not going to help them :( — MusikAnimal ^talk 17:56, 27 February 2017 (UTC)[reply]
- I think if we did implement such a universal notice, rather than a targeted edit filter, it would be best to implement it as a controlled A/B test to see if there is an effect on the rates of editing or reversion. It would also be good to suppress the notice if we are already displaying Template:Newarticletext-unconfirmed. Pinging Whatamidoing (WMF) to get input from editing team. Personally, I like the idea of beefing up the edit filter better. Kaldari (talk) 18:10, 27 February 2017 (UTC)[reply]
  - I'll ask around and see if anyone has any strong views. The formatting makes a long notice (like this one) difficult to read in VisualEditor and for users with narrow screens (in every editing environment). Volker had been thinking about ways to deal with that problem. Template:Newarticletext-unconfirmed has the same problem.
    The main problem with an A/B test, of course, is that someone has to collect and review the data. I don't know of anyone who can do that right now. Whatamidoing (WMF) (talk) 18:31, 27 February 2017 (UTC)[reply]

Protected edit request on 10 April 2019

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Add a line at the top of the mainspace editnotice linking to Wikipedia's core content policies, like so:

Core content policies: Neutral point of view · Verifiability · No original research

This would remind all editors to follow the core content policies while editing articles in mainspace. Qzekrom 💬 ^they_them 17:47, 10 April 2019 (UTC)[reply]

Not done part of this (Verifable) is redundant with MediaWiki:Editpage-head-copy-warn that is already at the top of every edit page, and that may be a better place to add some more links as well. In any case, this would be a hugely visible change so please propose in a discussion at a larger forum such as WP:VPR. — xaosflux ^Talk 18:38, 10 April 2019 (UTC)[reply]

Protected edit request on 1 March 2021

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Change {{TFA-editnotice}} to {{TFA editnotice}}. I'm standardizing the naming of all editnotice templates, and this is one of them. {{TFA editnotice}} currently redirects to {{TFA-editnotice}}, so after the change, {{TFA-editnotice}} should be of course moved to {{TFA editnotice}}. Thanks! Elliot321 (talk | contribs) 20:21, 1 March 2021 (UTC)[reply]

Done. — The Earwig (talk) 03:13, 14 March 2021 (UTC)[reply]

Protected edit request on 1 October 2021

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Per Wikipedia:Village pump (technical)#Draft notice for redirects and other existing pages, replace

{{#ifexist:{{FULLPAGENAME}}||{{#ifexist:Draft:{{FULLPAGENAME}}|{{There is a draft for this article}}}}}}

with

{{#ifexist: {{PAGENAME}} 
| {{#if: {{#invoke:Page|isRedirect}} 
  | {{#ifexist: Draft:{{PAGENAME}} | {{There is a draft for this article}} }} 
  | {{#if: {{#invoke:Disambiguation|isDisambiguationPage|{{PAGENAME}}}} 
    | {{#ifexist: Draft:{{PAGENAME}} | {{There is a draft for this article}} }}
    }}
  }}
| {{#ifexist: Draft:{{PAGENAME}} | {{There is a draft for this article}} }} 
}}

Currently, {{there is a draft for this article}} message is shown when:

current page doesn't exist but draft exists

The edit makes the message also show up when:

current page is redirect, and draft exists ~~and is not redirect~~
current page is disambiguation page, and draft exists

– SD0001 (talk) 06:28, 1 October 2021 (UTC)[reply]

Note that Module:Disambiguation is not a completely reliable way of detecting disambiguation pages as lots get missed. There is some discussion on Module talk:Disambiguation and tracking at Category:Disambiguation pages not detected by Module:Disambiguation — Martin (MSGJ · talk) 08:39, 1 October 2021 (UTC)[reply]

Okay – having the message shown on most of the eligible pages is still better that not showing at all. I see there's an open edit request at Module talk:Disambiguation that would likely make it more reliable. (I'm assuming there's no perfect way of telling apart disambig pages using template/module – because if there's a way Module:Disambiguation should use that.) – SD0001 (talk) 10:45, 1 October 2021 (UTC)[reply]

Yes, okay, agree with that. One question: could the {{#if:{{#invoke:Page|isRedirect|page=Draft:{{PAGENAME}}}} check be better moved into Template:Draft at because you would not want to link to a redirect in draft space in any case? — Martin (MSGJ · talk) 11:14, 1 October 2021 (UTC)[reply]

Not sure. If we do that, we'd probably also have to add the #ifexist check there, for the same reason. – SD0001 (talk) 12:46, 1 October 2021 (UTC)[reply]

I would assume that a redirect in draft space points somewhere relevant, though. BD2412 T 03:10, 3 October 2021 (UTC)[reply]

That's a fair point. Also there was a bug in the code above (for one condition it wasn't checking if draft exists before checking if it's a redirect). Fixed this by removing the isRedirect check for draft – as it isn't necessary and properly handling it makes the markup too scary. – SD0001 (talk) 10:15, 3 October 2021 (UTC)[reply]

Done. Thanks to SD0001. Please check this is behaving as expected. — Martin (MSGJ · talk) 10:26, 4 October 2021 (UTC)[reply]

Yes. The effect can be seen on Paint mixing (redirect) and Dramatization (disambig). – SD0001 (talk) 15:12, 4 October 2021 (UTC)[reply]

Double display redux: revisiting the edit of 8 November 2021‎

I've noticed some unintended problems with recent edits to this template, first reported and identified in this discussion. There are actually two separate problems in that discussion, so to keep things simple, I'll summarize the problem that needs to be addressed first now, and once that's resolved, I'll move on to my original issue.

The problem that the 8 November 2021‎ edit was intended to resolve was reported here. In that discussion, a double display of {{Draft at}} was reported. The source of the double display was identified, but the solution taken was to remove the test from here rather than at {{New page DYM}}. The result of that decision was to have the same test invoked from two different hooks at two different times, with unexpected results.

To demonstrate, click on the following redlink: FAO Money and Medals Program. You will notice the pink warning banner {{Draft at}} is displayed. Now click "Show preview". The banner disappears. @SD0001 has kindly located the source of this behavior. The initial display invokes MediaWiki:Noarticletext, which in turn invokes {{No article text}}, which in turn invokes {{New page DYM}}. This chain is only invoked when you first click on a redlink, and not invoked when you "Show preview", which is why the warning disappears.

Before the 8 November 2021‎ edit, this template would generate the {{Draft at}} warning when the page being edited did not exist (it was the "false" of #ifexist: {{PAGENAME}}). That, combined with the {{New page DYM}} test, resulted in the double display.

I would like to propose the following edits:

at {{New page DYM}}, remove:

{{ #ifexist: {{ns:Draft}}:{{#invoke:String|replace|source={{FULLPAGENAME}}|}}<!-- draft page -->
 | {{There is a draft for this article|{{ns:Draft}}:{{#invoke:String|replace|source={{FULLPAGENAME}}|}}}}
}}

at this template, revert the edit of 8 November 2021‎. (i.e., restore the line |{{#ifexist: Draft:{{PAGENAME}} | {{Draft at}} }})

My rationale for removing the test from {{New page DYM}} and including it here, instead, is:

The tests should be consolidated into one piece of code rather than split between two. (This is how the double display problem originated. Editors of one template may not be aware of the effect on the other.)
Draft articles are moved into mainspace and in no other namespace. Draft articles are not moved into Template: or Category: or File:, for example. The test is nonsensical when applied to other namespaces. {{New page DYM}} tests are applied to all namespaces.
(Granted, A draft could be moved into User: space, but only as a subpage of User:username. Applying the test to User: space is also nonsensical. You would be checking to see if a username happens to be the same as the name of a draft article.)
Good design in both articles and code should meet the principle of least astonishment. The magic vanishing banner behavior demonstrated above is, well ... astonishing.

To verity the validity of my requested edits, I suggest that after you make the {{New page DYM}} edit, you can click on my redlink (FAO Money and Medals Program). The {{Draft at}} banner should no longer display, as we just removed that code. Then, after making the revert to this template, clicking on the redlink should display the banner again. Next, hitting "Show preview" should (amazingly) also display the banner. If so, we should be good to go. Thanks for your time and consideration. PoundTales (talk) 13:39, 11 January 2022 (UTC)[reply]

P.S.: Perhaps at the same time, would it be good to add a hook for a /doc subpage?

<noinclude>
{{Documentation}}
</noinclude>

Thanks. PoundTales (talk) 17:49, 11 January 2022 (UTC)[reply]

I've just discovered a case that doesn't quite behave as expected. Putting this request on pause pending further research out of an abundance of caution. PoundTales (talk) 12:21, 12 January 2022 (UTC)[reply]

Withdrawing request entirely. The root inconsistency apparently has to do with the system messages themselves. There may be better hooks on which to hang this test, but that would require a better understanding of the PHP code and system messages / hooks than I presently have. Best to leave this issue for a more experienced editor. PoundTales (talk) 14:50, 13 January 2022 (UTC)[reply]

Interface-protected edit request on 6 February 2024

This edit request to Template:Editnotices/Namespace/Main and MediaWiki:Common.js has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Based on the discussion at MediaWiki talk:Common.js#Removing magic editintros, we can drop the "magic editintros" and implement them in the editnotice in a not-so-magical way. I have created Module:Mainspace editnotice combining the existing notices with the ones from Common.js. Conversion to lua helps avoid redundant compute and improve performance. It has testcases at Module:Mainspace editnotice/testcases.

Please apply protection on Module:Mainspace editnotice.
Replace Template:Editnotices/Namespace/Main with {{#invoke:Mainspace editnotice|main}}<noinclude>{{documentation}}</noinclude>
Remove magic editintros (lines 144 to 174) in MediaWiki:Common.js.

(If you see the BLP/disambig notice showing up twice just after making the edits, that would be because of the startup module cache and should get fixed in a few minutes.) – SD0001 (talk) 10:45, 9 February 2024 (UTC)[reply]

Done * Pppery * _{it has begun...} 18:53, 9 February 2024 (UTC)[reply]

Opened an RM for renaming the BLP/Disambig templates to more correct titles based on this – Template talk:BLP editintro#Requested move 10 February 2024. – SD0001 (talk) 03:59, 10 February 2024 (UTC)[reply]

Templates suppressing links to Page notice

There is a problem with some templates which are auto-added to articles suppressing the link to that article's Page notice. See Template talk:BLP editnotice#Suppresses link to Page notice. A few knowledgeable folks have been looking into this, but no solution has yet been found. It is thought that maybe someone here can work out what causes the suppression, and so be able to fix it. SilkTork (talk) 12:57, 30 May 2024 (UTC)[reply]

Protected edit request on 7 November 2024

It is requested that an edit be made to the fully protected template at Template:Editnotices/Namespace/Main.
(edit · history · last · links · sandbox · edit sandbox · sandbox history · sandbox last edit · sandbox diff · transclusion count · protection log)

This template must be followed by a complete and specific description of the request, so that an editor unfamiliar with the subject matter could complete the requested edit immediately.

Edit requests to fully protected pages should only be used for edits that are either uncontroversial or supported by consensus. If the proposed edit might be controversial, discuss it on the protected page's talk page before using this template. Consider making changes first to the template's sandbox before submitting an edit request. To request that a page be protected or unprotected, make a protection request. When the request has been completed or denied, please add the |answered=yes parameter to deactivate the template.

Please add a link from edit notices to the page containing the respective edit notice. Even if editors can't edit them, it will help them understand what this text is, why it appears and where it is coming from (so if they want to discuss or change the phrasing, they know where to have such a discussion).

I'm no expert, but it appears the change could be phrased as "we could just not hide the links" (for regular users) as discussed over at Wikipedia talk:Editnotice#adding a backlink to edit notices.

Regards, CapnZapp (talk) 22:16, 7 November 2024 (UTC)[reply]

FYI there are no links to not hide here - even as an admin I don't see a pointer to {{BLP editnotice}} at https://en.wikipedia.org/w/index.php?title=John_D._Smith&action=edit for example. Not a decline of this request, just a statement of fact. * Pppery * _{it has begun...} 16:31, 9 November 2024 (UTC)[reply]