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

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

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://wiki.riteme.site/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]

Assuming you understand my intended goal, could you phrase the edit request better? If so, please do, User:Pppery My suggestion was borne out of the linked discussion - if it contains inaccuracies, please tell me how to better phrase my request. Best regards, CapnZapp (talk) 15:59, 10 November 2024 (UTC)[reply]

Maybe it is helpful to clarify that "the links to not hide" refers to User:Xaosflux's comment here: [1], User:Pppery. Here's an example of an editnotice where it would be greatly helpful as a regular user to see links: https://wiki.riteme.site/w/index.php?title=Puzzle_Bobble&action=edit FYI: the notion to make this change for all mainspace edit notices (as opposed to only doing it for {{Refideas editnotice}}), that was a suggestion from User:Sdkb over at Wikipedia talk:Editnotice#adding a backlink to edit notices. CapnZapp (talk) 12:26, 11 November 2024 (UTC)[reply]

Not done (as to the immediate edit request) - this is missing an actionable edit request that is ready to implement. Note, I do support having a link to notices attached to the notice. Please sandbox up your specific change, such that it can be reviewed and tested. When ready, reactivate the edit request. I haven't seen any specific objections to this idea, and we do link to other more-highly visible things such as the v/t/e links on many templates. — xaosflux ^Talk 14:41, 11 November 2024 (UTC)[reply]

@Xaosflux: I don't have the confidence in my technical ability to implement my desired change in functional code. If you believe my edit request is unclear or ambiguous, that's one thing (and I have asked for help in fine-tuning the language, the English language I mean), but please don't interpret "Each request should include a clear, specific description of the desired edit" to mean "Unless you can code it, forget it." That said, I am in no way suggesting that you should feel obligated to work for me - do feel entirely free to just leave the request open until another technical editor with free time to spare comes by. But please reactivate the request if your only objection is that I didn't do the programming. Sincerely, CapnZapp (talk) 08:22, 12 November 2024 (UTC)[reply]

It's more that the edit request queue is an active check against page protection. We need to protect pages sometimes, but it is important that editors can still get their edits through, thus why admins will patrol edit requests. It isn't really a "will someone else do this work for me" system. Discussing of the proposed change is certainly welcome to continue! For example, it seems the user story (how to link to a notice) is only a problem for some classes of notices correct? That sort of fix may need a different approach than an "all notices" approach - I don't think that has even been fully explored yet. — xaosflux ^Talk 10:21, 12 November 2024 (UTC)[reply]

Reactivating, since several days have passed and I haven't gotten any specifics on what I am to do to further "missing an actionable edit request that is ready to implement." I choose to interpret this as the edit request being sufficiently specific to be implemented, but of course, if you (y'all, not any specific editor) think otherwise please do explain.

As for "Discussing of the proposed change is certainly welcome to continue" that doesn't seem helpful. No further discussion has taken place, which: can this be because there is nothing more to be discussed, now it is time to implement?

User:Xaosflux, if you feel "For example, it seems the user story (how to link to a notice) is only a problem for some classes of notices correct?" you need to be the one continuing the discussion, since nobody else seems to share your objections so far. Maybe you ought to bring this up in a more active venue if you really want opinions? (I don't have an opinion and am not even sure what your objection is)

If it helps, I'd like to request we start by showing the links for the {{Refideas editnotice}} to everybody (not just the classes of users actually able to edit it) and leave the "lets treat all templates equally" sentiment for a later stage, since that appears to possibly be a roadblock. I'll gladly start a new edit request if that helps. Posting this assuming we agree that deactivating an edit request followed by silence is probably not the straightest path to get something done around here. Cheers CapnZapp (talk) 08:00, 17 November 2024 (UTC)[reply]

My "objection" to your edit request is that you didn't (and still haven't) specified what edit you are requesting. The edit request process is a check against the protection process - assuming you could WP:BOLDly make this edit, but due to protection you need someone else to do it for you right now - however you didn't do this. What you should be doing is syncing in pages to a sandbox, and making the edits there. — xaosflux ^Talk 11:49, 17 November 2024 (UTC)[reply]

Well, we could just not hide the links, if someone wants a change they can easily open an edit request. Know who made this suggestion? You did, User:Xaosflux. I followed your advice and here we are - I opened an edit request asking for the code to "just not hide the links". I didn't think you (or whoever decided to act upon this edit request) needed more guidance than that, honestly, but I'll ask for help "syncing the sandbox" whatever that means back on the talk page if you want someone else to make the code change and you only want to be the one bypassing the page protection. CapnZapp (talk) 23:38, 18 November 2024 (UTC)[reply]

I have synced the sandbox with live template, but the template uses a module. If you are brave enough to try editing Module:Mainspace editnotice/sandbox, you could do so in order to show in the testcases page what the change might look like. If not, that is understandable; one thing you might do is copy and paste the relevant section of this template's output as it currently renders in an example, then copy and paste it again but make changes to the sections that you want to see changed. – Jonesey95 (talk) 00:53, 19 November 2024 (UTC)[reply]

Isn't the problem with the type of notice you are specifically asking about that we aren't "hiding" links at all, it is that they are not there at all? If it is hiding, you should be able to point to a specific class, id, etc - and/or a css rule. — xaosflux ^Talk 02:24, 19 November 2024 (UTC)[reply]

It sure would help if I was a competent Wikipedia programmer, but I'm not. I relied on the talk comment Well, we could just not hide the links, if someone wants a change they can easily open an edit request which at least to me indicated the link functionality was there, just conditional upon being someone who could actually do stuff with the links. My contribution to this is thus: "how about changing the thinking here and seeing value in providing the links for everybody?"

If it helps, let me copy the instructions over at Wikipedia:Editnotice:

“

They are links to the group and page editnotices of the page. Users with administrator, template editor, or page mover permissions always see both links, even if the notices have not yet been created, since they can create and edit the editnotices. Other users generally don't see them at all, except on their own user and user talk basepage, where they only see the red "Page notice" link, since they can create and edit such notices. They also see blue links to group and page notices if they already have been created, so they can find and view the source of the notice. But they still can't edit those notices, except the ones in userspace.

”

Let's just ignore how confusing the multiple conditional conditionals must be to a non-technical reader for now. If this doesn't happen for the kind of "mainspace" editnotices we're talking about here, I suggest we add it. The links that is, without the code to sometimes hide them, I mean.

Or, at the very least, a short link to Wikipedia:Editnotice. Something, anything, that clues you in to the fact that what you're watching is something called an "edit notice", and also - a starting point for where to go to find out more (or as in my case, where you can ask for an edit notice to be turned off). You very well can't ask for an edit notice to be turned off if you don't even know it is an edit notice you're looking at...

tl;dr: no edit notice at all should ever be displayed without some link to explain what you're seeing ("how can this page take over my page, I see none of its text when I edit the page??"), especially to non-expert users. I guess there can be exceptions when you for instance warn a user, and not cluing in that user how the warning is produced is a feature rather than a bug.

If you believe this should be discussed elsewhere, please just point me there, because this is starting to wear me down... CapnZapp (talk) 15:06, 19 November 2024 (UTC)[reply]

@CapnZapp: As explained above by Xaosflux, edit requests should not be of the form "Here's what I want this page to do, could you figure out how to write that?" See WP:EDITXY. Nevertheless, here are some options:

Backlinking to Template:Editnotices/Namespace/Main

Mainspace editnotice

There is a draft of this article at Draft:Template talk:Editnotices/Namespace/Main.

You are editing Wikipedia right now!

"Editnotices/Namespace/Main" is today's featured article.
You are editing it, and if you press Publish changes, your changes may be publicly viewable immediately. Constructive changes are welcome, but please do not attempt to damage the article.

Use the sandboxyour sandbox for test edits, or go to Template talk:Editnotices/Namespace/Main to make comments or suggestions. See our introduction on how to get started editing. We are excited to have you contribute! Thank you.

v • d

There are suggestions on this article's talk page for references that may be useful when improving this article in the future. (See the box that begins "The following ...".)

Notice about sources

This article must adhere to the biographies of living persons policy, even if it is not a biography, because it contains material about living persons. Take extra care to use high-quality sources. Material about living persons should not be added when the only sourcing is tabloid journalism; see more information on sources. Never use self-published sources about a living person unless written or published by the subject; see Wikipedia's guidelines on self-published sources and using the subject as a self-published source.

Contentious material about living persons that is unsourced or poorly sourced must be removed immediately from the article and its talk page, especially if potentially libellous. If such material is repeatedly inserted, or if you have other concerns, please report the issue to this noticeboard. If you are connected to one of the subjects of this article and need help, see this page.

This is not an article; this is a disambiguation page, for directing readers quickly to intended articles. For a quick guide, see disambiguation dos and don'ts. For more details, see the complete disambiguation page style guideline.

Some noteworthy differences from articles:

Generally only one navigable link (blue link) belongs in each bulleted entry.
Keep descriptions short, and organize long lists in sections.
The full article name should be visible; do not pipe entry names.

Backlinking to each editnotice

Draft at

There is a draft of this article at Draft:Template talk:Editnotices/Namespace/Main.

TFA editnotice

You are editing Wikipedia right now!

"Editnotices/Namespace/Main" is today's featured article.
You are editing it, and if you press Publish changes, your changes may be publicly viewable immediately. Constructive changes are welcome, but please do not attempt to damage the article.

Use the sandboxyour sandbox for test edits, or go to Template talk:Editnotices/Namespace/Main to make comments or suggestions. See our introduction on how to get started editing. We are excited to have you contribute! Thank you.

v • d

Refideas editnotice

There are suggestions on this article's talk page for references that may be useful when improving this article in the future. (See the box that begins "The following ...".)

BLP editnotice

Notice about sources

This article must adhere to the biographies of living persons policy, even if it is not a biography, because it contains material about living persons. Take extra care to use high-quality sources. Material about living persons should not be added when the only sourcing is tabloid journalism; see more information on sources. Never use self-published sources about a living person unless written or published by the subject; see Wikipedia's guidelines on self-published sources and using the subject as a self-published source.

Contentious material about living persons that is unsourced or poorly sourced must be removed immediately from the article and its talk page, especially if potentially libellous. If such material is repeatedly inserted, or if you have other concerns, please report the issue to this noticeboard. If you are connected to one of the subjects of this article and need help, see this page.

Disambig editnotice

This is not an article; this is a disambiguation page, for directing readers quickly to intended articles. For a quick guide, see disambiguation dos and don'ts. For more details, see the complete disambiguation page style guideline.

Some noteworthy differences from articles:

Generally only one navigable link (blue link) belongs in each bulleted entry.
Keep descriptions short, and organize long lists in sections.
The full article name should be visible; do not pipe entry names.

SilverLocust 💬 01:38, 21 November 2024 (UTC)[reply]

I guess thank you for that, User:SilverLocust, though I genuinely have zero idea what to do with those. Seems like some kind of standardized draft suggestions? But I've already spent way too much time and effort trying to get what I feel should have been an obvious point across; that edit notices are directly unfriendly to new users in that they don't explain themselves, they just appear on pages as if by magic, something I feel is directly contradictory to the fundamental philosophy of the Wikipedia project. I am definitely bowing out of even more procedural matters. If somebody actively doesn't want to see my simple and obvious point, it doesn't matter how many forms I fill out. I hoped people would instantly go "yes, old Zappster has a point, let me fix that for everyone's benefit". Since that's not happening, I'm out. CapnZapp (talk) 11:16, 24 November 2024 (UTC)[reply]

@CapnZapp: I wrote two ways to do the thing you're suggesting. The point being for you (or anyone else) to comment on whether you prefer one or if you would prefer something else. SilverLocust 💬 14:43, 24 November 2024 (UTC)[reply]

My 2c is that I prefer 2 over 1 if we implement this change. Sohom (talk) 16:41, 26 November 2024 (UTC)[reply]

Done. SilverLocust 💬 21:44, 28 November 2024 (UTC)[reply]