Wikipedia talk:Template index/User talk namespace

Uw-ai alternative for uw-ai-image

Hello, is there any interest in rephrasing uw-ai to also reference AI generated images? I would assume we want to have a quick way to tell users that AI generated images do not add value or may have an underlying copyright that makes them not reasonable on Wikipedia. Not sure all the policies yet on this beyond no LLM use in editing. --Engineerchange (talk) 18:00, 10 June 2026 (UTC)

I use {{uw-image1}} and add a short note mentioning WP:AIGI or WP:AIUPSCALE as appropriate. A {{uw-aiimage}} template that already included that for me would certainly be useful. Belbury (talk) 18:11, 10 June 2026 (UTC)

@Engineerchange and Belbury: There are a couple different ways you could go with this. One is to have a whole, new template, or to modify either {{uw-ai}} to mention images, or {{uw-image1}} to mention AI. I've mocked up a quick sandbox version to give you an idea what it might look like:

Illustration of a modified version of {{uw-image1}}     (two examples)

These two examples are from the wording in sandbox rev 1359623276.

1. This example was substed, but you can test it in sandboxes transcluded or substituted.

{{subst:Uw-image1/sandbox|ai=yes}} ⟶

Hello! Your image was inserted successfully but because it appeared to be irrelevant to the article or violated the image use policy on AI-generated images, it has been reverted or removed. Please use the sandbox for any tests you want to do. Take a look at the welcome page if you would like to learn more about contributing to our encyclopedia. Thank you.

---

2. substed example with param1 present:

{{subst:Uw-image1/sandbox|Underwater basket-weaving|ai=yes}} ⟶

Hello! Your image was inserted successfully on the page Underwater basket-weaving, but because it appeared to be irrelevant to the article or violated the image use policy on AI-generated images, it has been reverted or removed. Please use the sandbox for any tests you want to do. Take a look at the welcome page if you would like to learn more about contributing to our encyclopedia. Thank you.

More illustrations of {{uw-image1/sandbox}}     (three examples from sandbox rev. 1359878988)

New wording as suggested below @09:10, 17 June et seq.; from sandbox rev 1359878988.

1. Default wording (no params); note: the wording in sentence one is re-ordered from live: the action ('reverted or removed') now appears before the reason ('because it appeared to be...' )

{{subst:Uw-image1/sandbox}} ⟶

Hello! Your image was inserted successfully but it has been reverted or removed because it appeared to be irrelevant to the article or violated the image use policy. Please use the sandbox for any tests you want to do. Take a look at the welcome page if you would like to learn more about contributing to our encyclopedia. Thank you.

---

2. With param 1 (article name) only (no ai param):

{{subst:Uw-image1/sandbox|Underwater basket-weaving}} ⟶

Hello! Your image was inserted successfully on the page Underwater basket-weaving, but it has been reverted or removed because it appeared to be irrelevant to the article or violated the image use policy. Please use the sandbox for any tests you want to do. Take a look at the welcome page if you would like to learn more about contributing to our encyclopedia. Thank you.

---

3. With param 1 (article name) and param ai=yes:

{{subst:Uw-image1/sandbox|Underwater basket-weaving|ai=yes}} ⟶

Hello! Your image was inserted successfully on the page Underwater basket-weaving, but it has been reverted or removed because it appeared to violate the image use policy. Except in AI-related topics, articles should generally avoid AI-generated or substantially AI-altered images, especially of named individuals or scientific subjects. Where AI alteration has occurred, the original image is preferred. Please use the sandbox for any tests you want to do. Take a look at the welcome page if you would like to learn more about contributing to our encyclopedia. Thank you.

The language could easily be altered to whatever you want for the |ai=yes case, so feel free to make suggestions or just modify Template:Uw-image1/sandbox directly. Thoughts? Mathglot (talk) 08:19, 16 June 2026 (UTC)

@Mathglot: Your example with the |ai=yes param meets all of my needs. Thank you, --Engineerchange (talk) 10:48, 16 June 2026 (UTC)

Engineerchange, I'm glad. But in theory at least, one shouldn't use the sandbox version yet at a User talk page, as it could change at a moment's notice, and also is not a live version with consensus. We should wait a bit to see if anyone else chimes in to offer alternate wording, or to object to the change. If there's nothing in say, a week, then we can move it to live. Would you mind tracking this and then pinging me in a week if it looks like we can release it? Thanks, Mathglot (talk) 19:46, 16 June 2026 (UTC) P.S. I added another example above showing use with param1=article name. Mathglot (talk) 20:07, 16 June 2026 (UTC)

@Mathglot: Can do! Thanks, --Engineerchange (talk) 23:35, 16 June 2026 (UTC)

@Mathglot: Been a week. Can push for another week if you think there's still dialogue here. --Engineerchange (talk) 13:06, 23 June 2026 (UTC)

Engineerchange, yes, let's. (Thanks for the reminder.) I did sandbox versions for them, but will need to redo two of them (4 and 4im) partly for technical reasons as they are structured differently internally. Also, I am creating test cases for all of them so you and others can view them side-by-side with the originals; it would be too much to do all that in this discussion. You can look at 2 and 3 now, at Template:Uw-image2/testcases and Template:Uw-image3/testcases (in particular, test 5a and 5b), but there's no explanation of the tests or any new template doc yet. Templates 4 and 4im need to be redone, with new test cases. The main thing to note is that param 2 overrides the new AI param, so if you have |2=, then |ai=yes is ignored (because if you are writing your own text, then you are writing your own text; can't have it both ways). Mathglot (talk) 00:55, 24 June 2026 (UTC)

Mathglot About another week, so sending a reminder. Happy to test when you find the time. I'm in no rush, just want to keep the thread alive. And what you say about the 2nd param not working makes sense to me? I feel like as long as it doesn't override param 1, it's not a concern in my view. --Engineerchange (talk) 04:08, 2 July 2026 (UTC)

I think we can drop because it appeared to be irrelevant to the article or if we know that the template is being added because of the AI issue. It may also save some time and questions if we gave the user a short summary of WP:AIGI in the text of the template, something like Unless the article is about an AI-related subject, Wikipedia articles should generally not use images generated or substantially altered by AI, especially when depicting named individuals or scientific subjects. Where an image has been altered by AI, the original version is preferred. Belbury (talk) 09:10, 17 June 2026 (UTC)

That seems like a good goal. Can we tighten it up/shorten it a bit thus:

Except in AI-related topics, articles should generally avoid AI-generated or substantially AI-altered images, especially of named individuals or scientific subjects. Where AI alteration has occurred, the original image is preferred.

I don't think that loses anything essential in your version; what do you think? Mathglot (talk) 19:49, 17 June 2026 (UTC)

Sure, good one. Belbury (talk) 19:52, 17 June 2026 (UTC)

Please see "More illustrations..." above, in the dusky green collapse bar, with new wording per recent suggestions. There is also an additional mod to sentence 1 for more natural flow of action because reason, unrelated to the ai wording discussion. Mathglot (talk) 21:06, 17 June 2026 (UTC)

Looks good.

Having just had a user question this sentence in uw-image, on their talk page, Please use the sandbox for any tests you want to do. actually doesn't seem relevant when talking about AI images, so maybe it's worth losing it here. Belbury (talk) 16:23, 18 June 2026 (UTC)

You mean, drop it only in the ai=yes case, right, or in both versions? Mathglot (talk) 19:18, 18 June 2026 (UTC)

• Listed at: Wikipedia talk:Artificial intelligence and Wikipedia talk:Image use policy. Mathglot (talk) 19:57, 16 June 2026 (UTC)

Engineerchange, one other thing: if this does get approved, then it raises the question what, if anything, to do about {{Uw-image2}}, {{Uw-image3}}, {{Uw-image4}}, and {{Uw-image4im}}. I had a look at them, and assuming the users receives the level-1 warning first with |ai=yes, I'm not sure it needs to be repeated again for levels 2 and higher. Have a look, and see what you think. If you think we do need ai=yes versions for those as well, it's really n.b.d., but in that case, please suggest what the wording should be for each one. Thanks, Mathglot (talk) 08:11, 17 June 2026 (UTC)

@Mathglot: My suggestions (all wikilinks remain the same as normal):

• {{Uw-image2}} Please do not add inappropriate images to Wikipedia; it is considered vandalism. Please see the image use policy for appropriate use of AI-generated images in Wikipedia. Thank you.
• {{Uw-image3}} Please stop. If you continue to add inappropriate images, you may be blocked from editing. Unencyclopedic images, including AI-generated images, may be added to the bad image list to prevent them from being displayed.
• {{Uw-image4}} You may be blocked from editing without further warning the next time you add an inappropriate image. Unencyclopedic images, including AI-generated images, may be added to the bad image list to prevent their display if used persistently for vandalism.
• {{Uw-image4im}} This is your only warning; if you add an inappropriate image to Wikipedia again, you may be blocked from editing without further notice. Unencyclopedic images, including AI-generated images, may be added to the bad image list to prevent their display if used persistently for vandalism.

Namely just adding a simple note that AI-generated images are what is unencyclopedic for 3, 4, and 4im. Also, added an additional clarifying policy point to 2. IP and new users need this type of repetition in these warning messages, in my experience. But very open to edits here. --Engineerchange (talk) 14:32, 18 June 2026 (UTC)

Revised the above given the sandbox statement further above. --Engineerchange (talk) 16:29, 18 June 2026 (UTC)

@Engineerchange and Belbury:, sorry, I've been busy, but I think we may have it, now. The changes are too numerous to include tests here, so you can either test the sandbox pages at {{Uw-image2/sandbox}}, {{Uw-image3/sandbox}}, {{Uw-image4/sandbox}}, and {{Uw-image4im/sandbox}} in your sandbox or at Special:ExpandTemplates, or look at the test case pages for Uw-image2, Uw-image3, Uw-image4, and Uw-image4im. This wasn't conceptually difficult, there's just a lot of little details to keep track of all over, and it would be easy for me to have missed something somewhere. So please be an extra set of eyes, and make sure everything looks good, and if you spot anything fishy, please lmk. If it all looks good, then if we wait a few more days for any additional comment, we can release them. Mathglot (talk) 02:23, 22 July 2026 (UTC)

Oops, sorry; found a systematic problem to fix. Don't bother testing yet; I'll let you know. Mathglot (talk) 02:28, 22 July 2026 (UTC)

Actually, the problems only concern 3, 4, and 4im which transclude {{Uw3}}, {{Uw4}}, and {{Uw4im}}, whereas 1 and 2 emit the messages directly, and they are both fine, afaict. If you don't see a downside to releasing the new AI messaging-capable versions in two batches (i.e., a: 1 and 2; and b: 3, 4, and 4im), then we can do 1 and 2 now, assuming you are good with the outputs. In that case, please see the test case pages for Uw-image1/testcases and Uw-image2/testcases, and do whatever additional checks you like, and if you are on board, I will release those two. (Tests #5a – 5d are the ones to watch; the sandbox versions produce the new messaging; the live versions produce the old messaging.) Those two templates constitute the overwhelming majority of all warnings from the series anyway: there are 213 placements of 1 and 2 so far in 2026, and only 63 so far for 3, 4, and 4im combined. Thoughts? Adding @Engineerchange and Belbury:. Mathglot (talk) 21:34, 22 July 2026 (UTC)

@Mathglot: Apologies for my delay. I concur that 1 and 2 are good to go. Personally, I'm less concerned with 3 and 4 overall. I think 1 and 2 are necessary to restate policy. 3 and 4 are more for "you ignored 1 and 2 above, please revise or face consequences". Engineerchange (talk) 19:31, 22 August 2026 (UTC)

 Done. @Engineerchange and Belbury:, this has now been completed and the changes for new param |ai=yes are now live for templates {{uw-image1}} and {{uw-image2}}. The documentation has been updated for both. Please have a look and ensure it is doing what we described, and that the documentation is clear and properly represents the new functionality. Thanks, Mathglot (talk) 22:51, 24 August 2026 (UTC)

Thanks, all good. Sorry I never saw and replied to your Please use the sandbox for any tests you want to do. question above: I meant dropping it in just the ai=yes case, but it's not a big deal. Belbury (talk) 12:50, 9 September 2026 (UTC)

MoS warning

The {{uw-mos1}} series are pretty useless without an explanation of what the users is doing wrong. The MOS is simply too vast for new users to understand, and it's easy for newer RC patrollers to give this template out in a bitey fashion. I suggest we make 3 changes to how these templates work:

1. The 'additional text' should be displayed in a new paragraph (indented similar to how NPP messages are displayed), so that it becomes more obvious
2. The template documentation should discourage giving it out without any arguments (I would do this boldly if I could more easily figure out where this text lives)
3. In Twinkle, users should be given a reminder when they try to submit this warning without additional text.

In solidarity, —Femke (talk) 🐦 10:15, 16 August 2026 (UTC)

Agreed; it is way too vague. It means this template is highly liable to abusive usage, with the person placing it able to intimidate or threaten another user, and the person receiving it having no idea 1) what they did wrong, 2) what they have to do to repair the supposed damage; and 3) how to avoid falling into exactly the same problem in the future. I would support WP:DELETION of this template series as unhelpful and contrary to the spirit of WP:WARN. There are thousands of placements of {{uw-mos1}} in 2026 alone; see if you can figure out exactly what the supposed MOS violation was, in any of these 4,700 examples.

The uw-mosN series should be replaced by (one or more) templates targeting specific parts of the MOS, if there is a specific need for it. There is already precedent for this: we have {{uw-pronouns1}} targeting MOS:GENDERID; {{uw-color}} targeting MOS:COLOR and MOS:ACCESS; {{uw-euphemisms1}} targeting MOS:EUPHEMISM; and so on. If we need more of those, fine; let them be created for necessary cases. Meanwhile, the entire {{uw-mos1}} series should be deleted as causing way more harm than good. Mathglot (talk) 10:14, 17 August 2026 (UTC)

Femke, I sort of expected we would get some feedback by now; kind of surprised we haven't. I have a better idea of how to handle the vagueness issue in the template, though. Having lots of different templates for different aspects of MOS as I proposed above is not the right way to go; that would quickly get unmanageable. We should instead just keep the original template, and add an optional new parameter specifying what the MOS issue involved is; call it |issue=, or |concern=; where you could add the MOS shortcut, like MOS:DASH, or MOS:COLOR, or MOS:NUM or whatever to the template call. The placement might look something like this:

{{subst:uw-mos1|ArticleName|Add'l optional text|issue=DASH}}

The template could unwind the shortcut into a sentence via a simple config table, so for the example above, we might have this added to the message emitted by the template:

To ensure the consistent and clear use of dashes in Wikipedia, please see the [[MOS:DASH|Manual of style]].

I think this would be sufficient for users receiving the template to have a better idea of what they did wrong, and how to reach the right MOS page that explains it. (As a template editor, I know how to implement this, and it is quite easy in principle. It is also easily expandable; that is, we could start simple at first with just, say, DASH, NUM, and COLOR (or whatever) in a simple config file that anyone could edit (no scary template code; maybe just a bullet list of shortcut + sentence), and then we could just add more to the list as they were needed, so it would grow organically.)

To spur some additional feedback, I determined the top ten users of {{uw-mos1}} based on the first 2k results from this list and sorted by frequency of use:

@Augmented Seventh, Jessicapierce, Materialscientist, Peaceray, CodeTalker, JeffSpaceman, Cadddr, Adakiko, Jackjd0, and Salmon of Knowledge:

I'd like to hear your rationale for using {{uw-mos1}}. My guess is the obvious one: the user receiving the message violated some principle of MOS; duh. However, MOS is huge, and it may leave the user guessing what they did wrong; it could be any of dozens of things; unless the placement is accompanied by a second edit; but that takes more time.

My question to frequent users is this: if you had an additional param available that would provide a shortcut link to the MOS page in question, along with a sentence or two of explanation in the message, is that something you would see as an improvement? If it were available, would you use it? Thanks, Mathglot (talk) 00:50, 25 August 2026 (UTC)

I agree that {{uw-mos1}} is too vague to be used on its own. When I've used it, I think I've almost always included additional text, usually starting with "Specifically, ..." (e.g., ). I would definitely find what you're describing useful. Cadddr (talk) 01:42, 25 August 2026 (UTC)

oh I would absolutley use this if it was available in twinkle and have had the same thought, because its so broad as to give basically no meaningful information. generally I try to either fix it first or add clarification but its still a lot of extra steps to go find the proper MOS section (because I'm gonna be so real, the mos is a bit confusing to navigate), so even a little menu in twinkle that lets us link to specific sections (tone, WL, structure, etc.) would be great

Jackjd0 (talk) 01:52, 25 August 2026 (UTC)

When I give uw-mos warnings, I always add at least a sentence saying "See MOS:XYZ" pointing to the specific section that has been violated. It sounds like what you're proposing is a more formalized or built-in mechanism to achieve the same effect. If this were implemented, I would probably use it, although it's not clear to me how much easier it would be than just typing the sentence as I do today.

If it were integrated into Twinkle, I would definitely use it, and would find it more convenient than what I do now. By "integrated into Twinkle", I mean that selecting a MOS warning template would then provide a drop-down list or something like that, listing MOS sections to select from, and selecting one would automatically add the appropriate text to the warning. I have no idea how feasible it would be to add such a feature to Twinkle. CodeTalker (talk) 01:54, 25 August 2026 (UTC)

Yes,I would love to be able to customize this! I find the MOS template useful as a general "hey, we've got rules" notice, and I get the occasional reply saying "thanks, I had no idea." Anything more specific, I have to add on, as others have done. I'd love a way to streamline this, and to direct people to sections of the dauntingly huge MOS. Jessicapierce (talk) 01:56, 25 August 2026 (UTC)

I do not think that I ever post any of the {{uw-mos#}} warnings without linking to the section(s) of the manual that was violated. I agree by themselves, the templates would be too vague to be useful. However, I am not sure what we would substitute, since there are so many different portions of the MOS that apply to their own circumstance. Do we create a different template for MOS:PEACOCK, MOS:SEEALSO, MOS:TRIVIA, MOS:ALLEGED, MOS:SECTIONHEADING, MOS:BIB, MOS:OVERLINK, MOS:UNFORTUNATELY, MOS:LEADSENTENCE, MOS:BADDATE, MOS:PMC, & MOS:CONTENTIOUS? I have linked to each of those in MOS warnings within the last month or so.

Perhaps the {{uw-mos#}} warnings need to have an additional field that prompts for a link to the particular MOS guideline, similar to {{uw-username}}, which has a prompt Username violates policy because... & a field to enter the reason. Peaceray (talk) 04:46, 25 August 2026 (UTC)

Peaceray: Re, "Do we create a different template for... [a, b, c, and d]]": no, just a single template, with one additional parameter, |issue=, which will grab the appropriate text from an anybody-can-edit config file having twelve items to cover your examples, with items named MOS:PEACOCK, MOS:SEEALSO, and so on, where the value of each item would be a sentence or so grabbed from the MOS page and copied into the config. Your second paragraph was closer to the mark. I will try to mock this up tomorrow, so you can see what I mean. Mathglot (talk) 04:59, 25 August 2026 (UTC)

Peaceray, just for fun, this link will show you all your uses of uw-mos1 in 2026, in case you want to check them out (or this one). Cheers, Mathglot (talk) 05:48, 25 August 2026 (UTC)

Greetings,

I feel that some of my uses of mos warning templates while editing with Interceptor read as vague, especially to the new editor.

Quickly fixing the punctuation errors or infobox niggles, rather than reverting with the mos template, would not directly inform the new editor of their small grammar or punct errors, yet the mos template is too vague for the borderline-case purposes for which I've been using it.

Following. Augmented Seventh (talk) 18:21, 25 August 2026 (UTC)

@Mathglot: Thanks for the ping! I'm so sorry for my late reply; I really should've gotten back to you sooner. To answer both of your questions, insofar as my memory can be trusted, I seem to remember only using the template in exceptional circumstances such as with obviously disruptive or improper stylistic changes (though if anyone wishes to scrutinize that statement, by all means)—if not, then that's at least what I think should be done when using it. I think I was cognizant of the issues brought up in this thread when I first saw the template as an option in Twinkle's dropdown menu, to wit, the fact that on its own, the template would've been too vague and generic to have served its purpose of sufficiently warning a user for them to avoid making the same mistakes in the future. I mention this because I don't know whether that's a shared intuition across all of the users of this template (or at least among those who use the template the most frequently) given the responses by the other users who've responded hitherto seeming to indeed share it.

On that point, I'd broadly support the changes proposed here. That is to say, I don't know enough about templates or even Wikipedia to support or oppose a specific resolution to this problem, but I would probably support any one insofar as it's a true solution with no practical constraints in implementation, so just about any solution that may be proposed at all. If I had to give my thoughts on the problem itself, I identify extempore three reasons for warning a user, all related to and influenced by each other: first, to notify them of wrongdoing; second, to inform them why that is; and third, to have them not repeat it. If a warning is too generic, it would fail to fulfill its latter two purposes, thus necessitating the need for change. Like I said, though, I don't know enough about templates to comment on the changes that are being proposed, but if they truly provide what can be considered a solution with no obvious downsides, I can't see a good reason not to support its implementation. By all means, if that's the case, go full steam ahead, and I'll be cheering behind you, whatever non-trivial effect that has on it notwithstanding.

On your second question, I would certainly see a feature allowing me to specify what that wrongdoing was as an improvement. I find it difficult not to; something that comes at no detriment to me but provides much more functionality all the while would surely be an improvement in the purest sense of the word. This lack of a reason to object aside, I can only think of one reason why someone would object to it—not the broader idea of a solution to this generic template, but the specific implementation of a solution—which is that it would be difficult to do the remembering of all the MoS required to use the additional parameters. But in identifying a violation of the MoS and subsequently choosing to warn a user for it, it's assumed you're already familiar with at least the section of it you find pertinent, so I don't see that as an issue. Or perhaps someone might be worried about the functionality of such a comprehensive set of parameters for a template, but I can't personally speak on that, not knowing about working with templates. None of these concerns I feel too strongly about myself, so I rest my case. All the best! Salmon of Knowledge (talk) 01:41, 28 August 2026 (UTC)

Mockup and examples

A mockup of what I am proposing is now available in {{uw-mos1/sandbox}} for testing and commentary. There are two new parameters available in the sandbox: parameter |issue=, and parameter |longissue= (alias: |long=). The examples below walk you through the possibilities. In particular, parameter |longissue= uses the configuration subpage at Template:Uw-mos1/reasons. This config page was created as a mash-up of the examples given by Cadddr and Peaceray, along with my attempt to (rather quickly, and not too carefully) derive a single-sentence explanation for each MOS issue in question. The sandbox template lacks documentation for the moment, but with the examples below and the explanatory hatnotes, I hope it will become clear. You are more than welcome to add additional sections to Template:Uw-mos1/reasons to support your use cases. Your suggestions and comments on this mockup are welcome and encouraged. Examples:

Eight examples showing how this might work (moved here)

Examples moved to: Template:Uw-mos1/sandbox#Examples.

I only used three shortcuts in these examples, but you can use any shortcut you want with param |issue=, and any shortcut appearing as a section name in {{uw-mos1/reasons}} for param |longissue= (and you can expand or modify the reasons file).

What do you think? Is this (or something like it) something you would like to see added to the functionality of {{uw-mos1}}? Thanks, Mathglot (talk) 09:29, 26 August 2026 (UTC)

Thank you for doing this! I previewed it on my talk page. It looks good & seems to function well. I will add more reasons & descriptions to {{uw-mos1/reasons}}, probably starting late tomorrow. Peaceray (talk) 16:40, 26 August 2026 (UTC)

What do you think about the possibility of Twinkle integration? I almost always issue warnings using Twinkle. Is there any existing way to add the issue= parameter when using Twinkle (ideally as a dropdown, otherwise just by typing in the MOS:xxx shortcut name)? Or if not, how hard would it be to add it? CodeTalker (talk) 17:59, 26 August 2026 (UTC)

Hi, CodeTalker. Tl;dr: you can't use Twinkle for it now, and I don't know how hard it would be to add it, but we should find out at some point.

We are probably several steps away from Twinkle integration. First step: see if there is a consensus to have a feature like this added to uw-mos1. If so, work out the design: are folks happy with having these two parameters, and how they act; what should the param names be; 'reasons' page design, and so on. Create a testcases page to test the functionality (e.g., here's one for a different template). If all tests pass, move the sandbox to live and update the doc page. Get some experience with users using the new feature, to shake out any bugs, or comment on any difficulties or enhancement requests. Wait for it to stabilize. At that point, your Twinkle question gets to the top of the list.

Tbh, I know very little about Twinkle, but afaik, it's a piece of software that mimics the functions of various templates, and when new templates are created or old ones are changed, someone has to go update Twinkle. I think there are very few people doing that (maybe only one or two?) there may be a backlog, or maybe a template change requires a certain level of use or approval before it gets included in Twinkle; I'm not really sure how that works, but I know it's not automatic. Someone needs to take the time to make it happen, and it's a significant demand on scarce volunteer time. So at a minimum, I think we'd want to wait until we have something stable that users are generally happy with before we ask for it to be ported to Twinkle, because if we can make it happen at all, we probably just get one shot at it, so we should make sure we get the Twinkle request right the first time.

I understand that it would be way easier if users could access it via Twinkle, and I think it's an important question, and when we get to the right point in the process, we should raise this again. Maybe someone who knows more about Twinkle than I do can comment. Mathglot (talk) 18:59, 26 August 2026 (UTC)

Should 'issue' be made a required parameter?

Refactoring note: the first comment below was originally a reply in the § Mockup and examples subsection above.

It makes sense, but: if we integrate this into Twinkle, we should likely make it impossible to add the template without issue. In those examples, the template works with the shortissue as well: do we ever want that? The longissue is what I'd like to see. When we expand the useful text if the template with the options (e.g. an explanation about caps), we should significantly shorten the preceding text like the welcome page reference. In solidarity, —Femke (talk) 🐦 19:28, 26 August 2026 (UTC)

Anything we would ultimately want in Twinkle, should be implemented here first. The sandbox can certainly be modified to force use of |issue= (or |longissue=) as a required parameter. If we do that, what should happen if a user attempts to use the template without it? Should we emit a red error message, something like, Missing required param 'issue'? If there is precedent for what to do with missing required params in other WP:WARNing templates, we should be consistent, and do whatever they do. Does anyone have an example? Mathglot (talk) 19:43, 26 August 2026 (UTC)

I was looking at Wikipedia:WikiProject User warnings/Design guidelines, section § Parameters, which says:

Nearly every parameter should have a default value, such that misuse does not break the template.

There appears to be a tiny bit of wiggle room in that word nearly to permit a required parameter like 'issue' without a default, but if we want to do it that way, there should probably be a strong consensus in favor in order to give some weight to why we are going against the spirit of the design guideline in this case. (On the other hand, this is just a wikiproject subpage with at most WP:LOCALCONSENSUS; it does not have the force of a Wikipedia:Guideline.) Again, examples of some existing warning templates that have a required param would be very helpful. I tried searching for some, but haven't found any so far. Mathglot (talk) 20:17, 26 August 2026 (UTC)

Twinkle isn't the only tool which uses this template. Extra parameters is a great idea, but if those extra parameters are required then it really should be a new template so as not to break existing workflows. Something like {{uw-specificmos}} or similar. Otherwise any additional parameters should be optional unless enforced by the tool or desired by the user. TonySt  20:40, 26 August 2026 (UTC)

Coming back to the point raised by Femke about the welcome message sentence in the template, here is what it says now:

Please take a look at the welcome page to learn more about contributing to this encyclopedia.

I agree that this sentence is pretty useless. But it seems like keeping it or eliminating it is a separate question that can be decided on its own, regardless what happens with the proposal to add a specific MOS issue link or longer explanation to the message. Or does anyone see the two questions as linked somehow? I would support a new, top-level section on this page called #Uw-mos1 proposal: drop the welcome-page sentence. Mathglot (talk) 21:15, 26 August 2026 (UTC)

Reboot

Hi again, all. I've gotten the sandbox to a point where I think we have something that is viable as a possible update to the live template if there is support for it. I've also beefed up the documentation in the sandbox quite a bit, so I hope it is self-explanatory. (If not, please lmk.) I hope you won't mind if I ask for your feedback once more, to see how you like it now, and what changes or improvements you would like to see, as well as your opinion on whether we should release this sandbox version of Uw-mos1 to live. Pinging: @Augmented Seventh, Jessicapierce, Materialscientist, Peaceray, CodeTalker, JeffSpaceman, Cadddr, Adakiko, Jackjd0, and Salmon of Knowledge:.

Probably the best starting point is just having a look at the documentation in the template sandbox at {{uw-mos1/sandbox}}; skip down to Template:uw-mos1/sandbox §§ Parameters​ and Examples sections. Apologies for the additional ping, but please try it out and let me know your thoughts. Is this ready for prime time? Mathglot (talk) 04:08, 30 August 2026 (UTC)

this looks good to me but im not super knowledgeable on templates and tbh, i wont be able to properly evaluate until it's live on twinkle or redwarn cuz those are generally how i do temps. also, im absolutley going to use the List_of_MOS_issues page for my own reference when editing cuz thats super helpful. thank u for all this work and feel free to ping me again once its live Jackjd0 (talk) 04:27, 30 August 2026 (UTC)

Hi, Jackjd0, and thanks. Yes, there have been a few mentions of the advisability of getting it into Twinkle. There's a bit of a catch-22 involved: it can't get into Twinkle until it goes live, *and* has a certain amount of usage after going live to show that it is popular enough to merit the work involved to add it to Twinkle. And if people never use it because they are waiting for it to be in Twinkle, that will likely never happen if nobody uses it. So, let's take it one step at a time, try to take it live, and hope that some users will use it and then we can go to the next step. Hopefully you can try it out a couple of times even before it gets into Twinkle. Thanks again! Mathglot (talk) 07:22, 30 August 2026 (UTC)

I think the work so far looks great. However, I too will find it awkward to use before it's integrated into Twinkle. It will add a lot of manual work and typing to the process of sending a warning, which is currently done with a couple of button clicks. I understand the chicken-and-egg problem of getting sufficient usage to make a convincing case to add it to Twinkle. However I will try to make use of it at least sometimes to facilitate that step. As far as using it in the immediate future, is your idea that we should wait for it to be integrated into the live uw-mos1 template, or should we use it directly from its current sandbox location? If the latter, what is the exact syntax to do that?

Also, is it intended that similar changes will be made to the uw-mos2, uw-mos3 and uw-mos4 templates? If so, hopefully they will use the same list of reasons and not have the reason list duplicated 4 times. CodeTalker (talk) 18:01, 30 August 2026 (UTC)

CodeTalker, what do you think, should similar changes be made to the uw-mos2, 3, and 4? It would be easy enough, as the code for it would be identical, or nearly so, and all would use the same config file for the |longissue= reasons. If we do, though, probably the best strategy is to just release it for {{uw-mos1}} first, and see how much it gets used, and fis any issues that may arise. At that point, we should revisit the issue of expanding it to 2, 3, and 4. Mathglot (talk) 10:19, 1 September 2026 (UTC)

I don't see any reason that this change would be applicable only to uw-mos1. If I wish to warn someone with uw-mos2, uw-mos3 etc., there's some reason for it; that is, there is some part of the MOS that they have violated, and I would want to point them to that part. It might be a different MOS section than the one that they were warned about in an earlier uw-mos1 warning, so it's useful to be able to specify it separately in each warning. CodeTalker (talk) 16:53, 2 September 2026 (UTC)

Thanks; makes sense to me. I'm just trying to cater to what you and other editors with the most experience with this template find optimal. Mathglot (talk) 19:11, 2 September 2026 (UTC)

Concur. Augmented Seventh (talk) 17:43, 30 August 2026 (UTC)

Looks good to me! I look forward to having this in place & eventually having it expanded to the other uw-mos#s. Peaceray (talk) 05:12, 30 August 2026 (UTC)

Hi, Peaceray, thanks. Happy to add more mos's. Can you add a list of them below? If there are more than 25, maybe add them to a subpage instead, or in a message on my Talk page. Thanks, Mathglot (talk) 08:00, 30 August 2026 (UTC)

Oh, I think I misunderstood you. At first I thought you meant more mos shortcuts (there's no telling how many more there are; maybe more than a hundred?) but now I think you meant the other level templates – uw-mos2, 3, and 4? Both would be a good idea. Mathglot (talk) 18:26, 30 August 2026 (UTC)

@Mathglot: The diligence you and other editors have displayed here should be applauded! This is some impressive work that's been done both quickly and well. A very large improvement to this very popular template indeed, and one whose improvements will be seen to a great extent, no doubt. Looking at the documentation page and thinking of how I would use the template as I already do, I can identify three issues I'd like to comment on. It's difficult to make such statements before actually using the template and gaining some experience with it, so I want to emphasize that these concerns are just those I had thought up on the spot. I also want to emphasize that this will be a quick and sloppy write-up of those thoughts, so please bear with me while I make all of the potential oversights and digressions present hereinafter.

First, I usually use the {{Uw-mos}} templates not actually to address violations of specific guidelines listed in the MoS, but as a quick way to warn users who have made egregious stylistic errors, as I stated in my other reply in this thread. While that may seem unimportant because of the |2= and |longissue= parameters, which allow me to simply type up whatever grievances I have about a user's edits, it manifests in ways that make it difficult to apply any of the template's existing features without having to resort to either the bare template, incurring all of the problems this thread was created for, or a custom message, incurring all of the annoyances templates were created for.

To illustrate what I mean, consider the following examples: (1) a user uses extraneous markup when piping a link, thereby cluttering up the page; (2) a user uses Markdown instead of Wikitext to format their edits, preventing their formatting from displaying to readers; and (3) a user uses a predefined Unicode character as a substitute for an accepted string of characters, disabling both humans and bots to search for that string. In all of these cases, I'd want to reference the MoS, but even though their problems are stylistic in nature, they extend beyond the scope of our MoS. To mention this again, I realize the |2= and |longissue= parameters provide a solution to this when using the {{Uw-mos}} templates, but because this thread was started because of the problem with the intended usage of the template, not the actual usage of the templates, I thought this might've been important to mention regardless.

Second, in many cases, I want to reference multiple parts of the MoS being contravened. If a user uses in one edit, let's say, both "USA" in place of a conventional "US" and "$US" in place of the correct "US$", I'd want to be able to point to both MOS:NOTUSA and MOS:CURRENCY without having to engage the custom text parameters. Because of my unfamiliarity with templates, I don't know whether this annoyance can already be circumvented, but I thought I'd mention it anyway, like what I did with my first concern. With this one, though, I might be able to suggest a change in a similar vein as my first: if the goal is to have users avoid biting new editors by warning them about behavior they have no knowledge about, perhaps it'd be useful to mention the potential ability to circumvent or otherwise address the occurrence of multiple style guide violations in the template's documentation so issuers of the template can at least have an avenue to be cognizant of it.

Third, the specific wording of the template as it's existed may be problematic with respect to the spirit of this thread, a problem shared in part with the other two concerns. In particular, I'm concerned about the third sentence of the template and how it seems to predicate a user's awareness of the MoS. While I get the tacit consensus is probably that this issue isn't of note because the introduction of the MoS on its own should be tantamount to an explicit disclaimer of it, I'm putting myself in the shoes of a completely new editor, just-as-completely unaware of the practices here, staring at that template placed on their talk page and wondering why they seemed to be implicated of violating this "Manual of Style" about which they have no knowledge. When I do so, I feel I'm reading a loaded and slightly circuitous message that's probably from some editor too familiar with their community to relate to the uninitiated few. Yes, this is a largely intuitive argument, but I think if you try to replicate it, you may come to agree with me.

I'm aware these concerns relate to how well the template can be used as a way to warn editors about any stylistic problem at all and the problems that arise as a result of that shortcut rather than the specific implementation of a solution to that problem you're asking for feedback about, but because that's what I've identified as the reason for this thread's creation, I feel it's appropriate to mention them nonetheless. I have no specific solutions to this and can't even affirm that they're actually problems significant enough to warrant solutions; like I said in the first paragraph of this reply, it's one I wrote rather hastily, so I apologize again for any faults with it. I just thought I'd pay the courtesy of giving some reply rather than none. Thanks! Salmon of Knowledge (talk) 05:45, 30 August 2026 (UTC)

Salmon of Knowledge, good feedback, thanks. Regarding this part:

I'd want to be able to point to both MOS:NOTUSA and MOS:CURRENCY without having to engage the custom text parameters.

I presume you got the part about being able to use parameter |issue= to enter your own text, so you could always do something like this:

• {{subst:uw-mos1/sandbox|issue=Please also have a look at MOS:NOTUSA and MOS:CURRENCY.}}

and that would append that line to the message, as is. But I think you meant that you wanted to include the longer descriptions from Template:Uw-mos1/reasons from both sections, namely Template:Uw-mos1/reasons §§ MOS:NOTUSA​ and MOS:CURRENCY, that would be possible as an enhancement down the road. In the meantime, you could just copy & paste that material out of /reasons into your message in a second edit for now. If there is a demand for having param |longissue= be able to support more than one shortcut, that can definitely be done eventually. But let's get the simple version approved first, so we can get some experience with it shake out any bugs first, and then come back to your idea as an enhancement. I definitely think it warrants a look, and would not be excessively hard to do. But let's start with the basics, and then evolve in that direction. Does that make sense?

As for differences between intended and actual usage of the template, that merits additional consideration, but I have to acknowledge not being very familiar with the issue. Mathglot (talk) 09:03, 30 August 2026 (UTC)

@Mathglot: I'm sorry for the late response yet again; hopefully, you hadn't taken it as indifference toward your reply. But on your question, yes, that makes perfect sense. I'm not knowledgeable about the lifespan of a newly-proposed template, which would involve the process by which it becomes approved for regular use, so if you decide for it to be simpler to pass through that process easier, I personally wouldn't be able to oppose it in any meaningful sense. To provide what I can, I made the proposal because it would be slightly laborious to copy and paste several items back-and-forth, but I (as well as, I suppose, many other users of the template as it was) have been doing that to a greater extent since I joined Wikipedia and first sought to use the template anyway, so it wouldn't make much of a difference whether I had to make a few clicks for a few more months. Salmon of Knowledge (talk) 03:08, 3 September 2026 (UTC)

Everything seems to be ready and working as designed. We can wait a few more days to see if there is any more input, and then I think we can go live with it if there are no objections. I think the suggestion to remove the 'Please take a look at the welcome page...' sentence is worth a look as it seems out of place there, especially if a MOS link or text is provided using the new params, but let's take that up in a second discussion after this one is settled. Mathglot (talk) 10:24, 7 September 2026 (UTC)

Planning on launching tomorrow. Here's a first example of what it will look like live; this was the result of {{subst:uw-mos1/sandbox|long=MOS:LINK}}, and I think it looks pretty good. (Except for that 'welcome page' sentence, which I think really has got to go.) Thanks, Mathglot (talk) 01:39, 11 September 2026 (UTC)

Launch!

The upgrade to {{uw-mos1}} has been launched and is now live with the two new parameters |issue= and |longissue= we have been discussing. Here's the last set of pings (I promise!) :

@Femke, Augmented Seventh, Jessicapierce, Peaceray, CodeTalker, JeffSpaceman, Cadddr, Adakiko, Jackjd0, and Salmon of Knowledge:

Please try it out! Feedback encouraged; please let me know how you like it, including any pain points in the template, or anything that is unclear or could be improved on the doc page. Thanks all for your participation; I am really looking forward to seeing the new features in use! Mathglot (talk) 10:34, 12 September 2026 (UTC)

This looks excellent. Thank you! Jessicapierce (talk) 14:21, 12 September 2026 (UTC)

Thank you! Peaceray (talk) 15:21, 12 September 2026 (UTC)

Looks good! I use Huggle and need to implement it, or something like it, in my .js Thanks again. Adakiko (talk) 19:40, 12 September 2026 (UTC)

Publicity

First-time pings for users who have been frequent users of the {{uw-mos1}} template this month, and who have not been pinged before:

@Mreatwashacked, Frost, Bungle491, Ednxa, AriuCH, Streetr4, EndTheWikiEditor, Binksternet, Maayaaaaa, and Sigma440:

These pings represent the top ten users of template {{uw-mos1}} out of about 250 placements so far this month (e.g., Sept. 1 to Sept. 12).

Hello! If you were just pinged, this message is just to let you know about a major improvement to {{uw-mos1}} which has been long in the making, which now allows you to specify exactly what MOS issue is involved when using the template. The documentation has details about how to use the two new parameters in order to achieve this. Here's a teaser:

Using an invocation like:

{{subst:uw-mos1|longissue=MOS:APOSTROPHE}}

will emit the standard text of the uw-mos1 message, along with the summary text from a config page inserted at the end of the message, right before the Thank you. An example:

Example showing result of {{subst:uw-mos1|longissue=MOS:APOSTROPHE}}:

{{subst:uw-mos1|longissue=MOS:APOSTROPHE}} → Welcome to Wikipedia, and thank you for your contributions. Although everyone is welcome to contribute constructively to the encyclopedia, please note that there is a Manual of Style that should be followed to maintain a consistent, encyclopedic appearance. Deviating from this style disturbs uniformity among articles and may cause readability or accessibility problems.

Use straight apostrophes ('), not curly apostrophes (’). Do not use accent marks or backticks (`) as apostrophes. For further style guidance about apostrophes see MOS:APOSTROPHE. For usage of the possessive apostrophe, see MOS:POSS. Please take a look at the welcome page to learn more about contributing to this encyclopedia. Thank you.

I hope you find this new feature useful. Feedback welcome! Mathglot (talk) 21:34, 12 September 2026 (UTC)

I'm very surprised but honored to be in the top 10! That looks great, I'll give it a try instead of just hitting the Interceptor button. Thank you so much! End (talk) 22:33, 12 September 2026 (UTC)

Thanks for letting us know about this. However, I think most of the people you pinged, myself included, are using user scripts to place the {{uw-mos1}} template series. So, perhaps it would be a good idea to ping the creators as well. Maayaaaaa (talk) 22:40, 12 September 2026 (UTC)

Hi, Maayaaaaa, and thanks for the feedback. I am not particularly knowledgeable about user scripts; can you elaborate? There has been some discussion previously about Twinkle use; is that what you meant? The upshot of that, in brief, iirc was that there are very few maintainers of Twinkle, and in order to get a template change implemented there, it seemed like one needed to demonstrate a certain level of interest and usage of the template in direct usage (i.e., outside Twinkle), leading to the Catch-22 that if everyone uses it only via the script, the new feature will never get added to it. (However, this is only speculation, as it isn't clear, at least to me, how to get something added to Twinkle.) Also, someone mentioned Huggle above. Or, did you mean something else? Mathglot (talk) 22:52, 12 September 2026 (UTC)

Some people use Twinkle, but there's also Huggle, RedWarn, Ultraviolet, Interceptor, AntiVandal, etc. Maayaaaaa (talk) 01:54, 13 September 2026 (UTC)

Do you know if those require an update when a template is updated? I know that Twinkle does. Mathglot (talk) 02:04, 13 September 2026 (UTC)

Yes, the scripts need to be updated to be able to support the new parameters you've created for the template. Ideally, this could be a new drop down menu that allows the user to pick the MOS issue, or something like that. Maayaaaaa (talk) 02:21, 13 September 2026 (UTC)

Do you think we should wait and see how it goes with these changes first before saying anything (in case there are changes based on feedback), or just notify them right away so they can follow along, and implement or not as they prefer? How is it usually done? Mathglot (talk) 02:29, 13 September 2026 (UTC)

Usually on WT:Twinkle, WT:Ultraviolet, WT:Huggle, etc Maayaaaaa (talk) 02:37, 13 September 2026 (UTC)

I believe Interceptor in particular is being updated right now to include a wider range of warning templates. With the current interface, I feel like it would be a tad difficult to add in, but it could be worth contacting the users who run it at WT:Interceptor. End (talk) 03:53, 13 September 2026 (UTC)

Thanks; mentioned at WT:Interceptor#Update to Template:Uw-mos1. Mathglot (talk) 04:25, 13 September 2026 (UTC)

Hi Mathglot, thanks for the ping and for improving template {{uw-mos1}}. Best, AriuCH (talk) 23:24, 12 September 2026 (UTC)

Thanks for the ping, great feature :) Streetr4 (talk) 10:53, 13 September 2026 (UTC)

Template-protected edit request on 7 September 2026

−

Hello, I'm [[User:Jimbo Wales|Jimbo]]. I noticed that you added or changed content in an article, but you didn't provide a [[Wikipedia:Reliable sources|reliable source]]. On Wikipedia, it's important that article content be [[Wikipedia:Verifiability|verifiable]]. If you'd like to resubmit your change [[Wikipedia:Citing sources|with a citation]], your edit is archived in the page history. If you have any questions, you can leave me a message on [[User talk:Jimbo Wales|my talk page]]. Thank you.

+

Hello, I'm [[User:Jimbo Wales|Jimbo]]. I noticed that you added or changed content in an article, but you didn't provide a [[Wikipedia:Reliable sources|reliable source]]. On Wikipedia, it's important that article content be [[Wikipedia:Verifiability|verifiable]]. If you'd like to resubmit your change [[Wikipedia:Citing sources|with a citation]], your edit is archived in the page history. To add a citation in the VisualEditor, use the {{VisualEditor cite button}} button. If you have any questions, you can leave me a message on [[User talk:Jimbo Wales|my talk page]]. Thank you.

{{VisualEditor cite button}} renders as Cite. Velocifyer (talk) 19:50, 7 September 2026 (UTC)

This template isn't only for VE users. Mathglot (talk) 21:13, 7 September 2026 (UTC)

 Not done: This is not just for people using the visual editor. Zackmann (^{Talk to me}/_{What I been doing}) 03:18, 8 September 2026 (UTC)

I think this is a good idea in principle. Maybe you could add a switch for if the person used the VisualEditor to make the edit? Otherwise, it will show instructions in the old-school wikitext editor. I think one of the biggest barriers for people to create citations is that it's bit intimidating at first if you don't know how to do it. Maayaaaaa (talk) 22:49, 12 September 2026 (UTC)

The message already contains a link to WP:Citing sources, which is pretty detailed. Probably overly detailed for a newcomer, but the lead on that page contains links to Help:Referencing for beginners and Help:VisualEditor#Editing references, which contain simpler instructions for the Wikitext editor and Visual Editor respectively. Perhaps the message can be improved somewhat, but I think any improvement should just point to existing documentation pages rather than trying to cram instructions on how to create references into a sentence or two. CodeTalker (talk) 23:01, 12 September 2026 (UTC)

I think it would be much more helpful to link directly to Help:Referencing for beginners. This is because, the WP:CITE page can come off as overly technical, and it doesn't even describe how to create a citation until you've read very deep into the page. Most of the time, it would be better if users can create any citation, even if it's improperly formatted, because it's a lot easier to fix a broken citation than to manually trace what source an uncited statement may have come from. Maayaaaaa (talk) 02:04, 13 September 2026 (UTC)

I agree with this. CodeTalker (talk) 02:36, 13 September 2026 (UTC)

We can do this instead maybe:

−

Hello, I'm [[User:Jimbo Wales|Jimbo]]. I noticed that you added or changed content in an article, but you didn't provide a [[Wikipedia:Reliable sources|reliable source]]. On Wikipedia, it's important that article content be [[Wikipedia:Verifiability|verifiable]]. If you'd like to resubmit your change [[Wikipedia:Citing sources|with a citation]], your edit is archived in the page history. If you have any questions, you can leave me a message on [[User talk:Jimbo Wales|my talk page]]. Thank you.

+

Hello, I'm [[User:Jimbo Wales|Jimbo]]. I noticed that you added or changed content in an article, but you didn't provide a [[Help:Referencing for beginners|reliable source]]. On Wikipedia, it's important that article content be [[Wikipedia:Verifiability|verifiable]]. If you'd like to resubmit your change [[Wikipedia:Citing sources|with a citation]], your edit is archived in the page history. If you have any questions, you can leave me a message on [[User talk:Jimbo Wales|my talk page]]. Thank you.

Maayaaaaa (talk) 02:48, 13 September 2026 (UTC)

In theory, linking Help:Referencing for beginners should be the right thing to do here, and I would support it if that page were a decent page for beginners, but it really isn't. It starts right out with an error in the first section:

Inline citations are usually small, numbered footnotes like this.

Very muddy usage; that superscript [1] is not an inline citation, it is a mediawiki software-generated footnote marker created from the actual inline citation, which could be a ref-tag, or an {{sfn}}, or other things. Wikipedia:Citing sources explains properly what a citation is in the first sentence, while Help:Footnotes#Footnotes: the basics explains what the footnote marker is, and how it gets there. That said, in a 'X for beginners' article, we don't need to (and shouldn't) go into as much detail as those two pages do, but the Help:Referencing for beginners—which has the perfect title—lacks decent content, and imho we shouldn't send beginners there while it is in its current state.

What I'd like to see, is a volunteer willing to rewrite Help:Referencing for beginners the way it ought to be, and then I would totally support your proposal. But not at this point; that Help page just doesn't measure up for what a beginner needs. The other problem with it is the mirror image of the problem in the OP: this page is only for the wikisource editor.

P.S., I think you might have a spurious unbalanced <noinclude> right before your sig at 02:48. Mathglot (talk) 04:07, 13 September 2026 (UTC)

The page already links to the VisualEditor instructions at the top. So, this shouldn't be much of an issue. That said, I did fix the issue that you mentioned. If you see other things that need to be cleaned up with the Help page, feel free to knock yourself out. Maayaaaaa (talk) 11:32, 13 September 2026 (UTC)

Template-protected edit request on 8 September 2026

Description of suggested change: "...your username is a blatant violation of Wikipedia's username policy, meaning that it is..." should be changed to "...your username is a clear violation of Wikipedia's username policy, meaning that it is...", because using that language feeds trolls, and other username-related block templates have also swapped out the same or similar wording. BooksBooksBooks3 (talk) 01:51, 8 September 2026 (UTC)

 Not done for now: please establish a consensus for this alteration before posting an edit request. Zackmann (^{Talk to me}/_{What I been doing}) 03:18, 8 September 2026 (UTC)

BooksBooksBooks3, this is a dead letter for now. For next time, though, please remember to link the template you are talking about so people don't waste their time hunting around, trying to guess what you meant. I assumed you were talking about {{uw-username}}, so I went ahead and looked that one up—but no luck; the wording you quoted is not used there. Cheers, Mathglot (talk) 03:51, 8 September 2026 (UTC)

Spam on user page warning example

Hello! I don't know if this is common, but some of my mentees spam the same questions over and over again until they get an answer, and it gets annoying fast. I was thinking that there should be a single issue warning on this. EXAMPLE: Hello! I'm <Username>, and I've noticed that you were spamming massages on <Users talk page>. This may violate Wikipedia:Spam. Please be patient. this is a example and may be edited to better state the warning. WXchaser (talk) 13:50, 9 September 2026 (UTC)

WXchaser (talk) 14:34, 9 September 2026 (UTC)

WXchaser I don't know if it's common either. Regarding the specific issue that sparked your question, presumably you are referring to the seven recent questions about tone revision at your Talk page placed by user Ainigushenzouanxiang. Checking their contributions, they have made eleven edits to ten mainspace articles, adding citations, links, and even revising tone (thrice), so they appear to be here for the right reasons, namely, to build the encyclopedia. I am not sure how to interpret their repeated questions at your Talk page, but the simplest answer may be that they never saw the responses by a third party on your page because they were not pinged. In the one case where they were pinged, they responded.

Another possibility, is, assuming good faith, is that they may be asking about what 'revise the tone' means in a particular context. It's interesting that none of their three tone revisions (diff1, diff2, diff3) involved a question on your page, and more significantly none of those three actually revised the tone in those articles; not even sure they are improvements at all. Perhaps their native language isn't English, or perhaps they don't really know what 'tone' means and they need specific wording suggestions rather than a link to WP:TONE.

Either way, it doesn't look to me like a spam situation, and a warning message on the Talk page of a new user who is trying hard and asking questions, maybe making mistakes along the way, could be pretty discouraging. Only a tiny percentage of new users ask even one question; I'd hate to make it easier to warn the ones that do ask—maybe too much—by creating a template for it. It seems more like a situation where either the new user never hears back and assumes that their mentor never got the message (remember: they are not writing at your Talk page, they are writing from a module on their homepage) so they just ask again, or they don't know what 'tone' is and need specific instruction, or both. Seems like this is more of a mentor–mentee communication issue than a spam issue; have you tried asking at the WP:Mentorship noticeboard? Mathglot (talk) 19:53, 9 September 2026 (UTC)

By coincidence, I got a mentee question today on my Talk page about revising tone, and it sounds like a case where they don't quite know what that means. I responded at their Talk page. Mathglot (talk) 18:58, 13 September 2026 (UTC)

I have WT:Twinkle in my watchlist and so I'm here from the original post there. WP:SPAM is more about spam issues in article mainspace than editor communication issues. I don't think a standardised user warning can fit a wide variety of editor communication issues, perhaps the editor isn't aware their messages are going through, perhaps they're just really eager/enthusiastic? Seems like a personalised message would work fine to help clarify the situation. If that doesn't work, then cross the bridge of additional warnings and possibly ANI later. Fork99 (talk) 14:16, 14 September 2026 (UTC)