Lowercase all parameters? edit

{{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 edit

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 edit

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 edit

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 💬 theythem 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 edit

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 edit

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‎ edit

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:

  1. 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.)
  2. 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.)
  3. 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 edit

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.

  1. Please apply protection on Module:Mainspace editnotice.
  2. Replace Template:Editnotices/Namespace/Main with {{#invoke:Mainspace editnotice|main}}<noinclude>{{documentation}}</noinclude>
  3. 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