Template talk:Uw-draftnocat

Use of USERNOCAT regardless of param

Feedback from my talk page about wrong *NOCAT link usage:

...the template seems to be currently worded to cite WP:USERNOCAT as the applicable policy regardless of whether I've set spaces= to sandbox or draft, so that I had to make a followup edit to change USERNOCAT to DRAFTNOCAT.
— User:Bearcat 14:57, 21 March 2026 (UTC)

The bug can be seen at User talk:Rosebud1244#Drafts. Mathglot (talk) 19:02, 21 March 2026 (UTC)

This is definitely a bug. I am envisioning a solution that will both fix this, as well as making things easier for you at the same time by reducing or obviating the need to use the |space= parameter at all (or perhaps only in unusual circumstances). A few different approaches are possible, and I am mulling over the best way to do this.

The easy fix, and definitely the first step imho, is to just fix the current template to link the right guideline depending on the value of the |space= param. That should be no problem, and that should be done soon. But, there are better ways, that are however a bit more involved.

One is the wrapper template approach. It goes like this: we create a wrapper template called {{Uw-usernocat}}, with very little code in it, basically it just invokes the other one, passing |space=sandbox to it. So, that's one less param you would have to fill in each time; you just call {{Uw-draftnocat}} when it involves draft space, and {{Uw-usernocat}} when it is in user space. (As it would be a wrapper, the |space= parameter would still exist, and you could still optionally use it to 'override' the template name.)

It is slightly tricky, as the wrapping template would also be always-subst, so we'd have one always-subst template calling another, but I don't think it should be a problem, as that is one of the whole points of safe substing. This is imho the better solution, but will take a little longer.

One corollary of this is that the 'space' param, which currently has two possible values drafts and sandbox, should probably be changed to have values drafts and user. For two reasons: this brings it more in line with the concept of namespace, which is really what it is about, and secondly, a user can user their sandbox, but they can also use a user subpage and it seems awkward to have to say |space=sandbox when it isn't a sandbox, but a user subpage. So, I propose that we make that change, so that next time, you can say |space=user instead of |space=sandbox. I'll keep 'sandbox' as an undocumented alias value, so it will still do the same thing in case you forget; I'll also keep the doc page up to date so it reflects any changes to the parameters.

Finally, the ultimate approach I envision is based on param 1. By parsing param 1 (if provided), we ought to be able to determine the correct guideline to link, and it may be possible to ultimately get rid of the space parameter entirely (or just keep it as an override.

That brings up the question about whether param 1 should be required, but I don't think it should, for consistency of approach with other user warning templates. If it were only up to me, I would make param 1 obligatory in all warning templates, as I always find it annoying to see a {{uw-vandalism1}} or some other template on a user talk page, with no article link in it. For many active users, this must make it almost impossible to react to the message, as they may have touched ten or fifty articles in the last 24 hours. Nevertheless, param 1 is never obligatory in user warning templates, so I think we have to adhere to that here. Mathglot (talk) 20:27, 21 March 2026 (UTC)

Regarding the values of the |space= param, there are now three: draft, sandbox, and subpage, and I don't think getting rid of it is advisable at this point. The easy fix (linking to the right guideline depending on the value of the |space= param) is in, and working. Since there are three values for the space param, if we wanted just one wrapper template, then the base template would have to be Uw-usernocat (which would have two space param values: sandbox and subpage) and the wrapper would have to be Uw-draftnocat; if we did it the other way, there would have to be two wrappers (e.g., Uw-sandboxnocat, and Uw-subpagenocat), and that's a non-starter. Mathglot (talk) 02:48, 24 March 2026 (UTC)

Here's sample wrapper code:

{{#invoke:Template wrapper|wrap|_template=Uw-draftnocat|_include-positional=yes|space=subpage}}

It goes "the wrong way", but is just an example. Mathglot (talk) 05:13, 24 March 2026 (UTC)

Hidden text delims remain in substed wikicode

From my talk page about hidden text delims remainiing in the substed wikicode:

...when I did that it had left the blank hidden comment between "so long as it is outside mainspace" and the level-switching code in as part of the substituted text. (Not the switching code itself, just the <!-- --> part.
— User:Bearcat 14:57, 21 March 2026 (UTC))

Same location. Mathglot (talk) 19:02, 21 March 2026 (UTC)

I knew about this and left it in anyway, as it isn't visible to the user on the rendered page, only in the wikicode. It is an artifact of my trying to write maintainable code, as template code can get unbelievably squirrely and unreadable with no indentation or newlines. So, there is a conflict involved: those delims enhance the experience for template editors (likely just me for the time being) but make the experience slightly worse for editors who want to look at or modify the substed code on the user's Talk page. I agree it's a problem and should be fixed, but given more serious issues as described in other sections, I prefer to put this off for now. If others see this as more serious than I do, we can adjust the priority higher. Alternatively, there is always the Dilbert approach to priority adjustment. Mathglot (talk) 20:49, 21 March 2026 (UTC)

Enhancement: update default heading

I propose we change the default to '{{{1}}}'. Currently, the default heading is {{{1}}}, overridable via param |headtext=. We should probably change this. There are three likely locations for a user to be developoing a prospective article:

1. in their sandbox, i.e., User:Example/sandbox
2. in draftspace, e.g., Draft/Underwater_basketweaving
3. in a userspace draft, e.g., User:Example/Underwater_basketweaving

The current default heading is really only applicable to #1.

There are a couple of ways the default could be improved. One takes advantage of the polysemy of the word draft, as their sandbox is also a draft, and so is a "userspace draft", which uses the word right in the name. And obviously, pages in Draft space are also drafts. So, simply changing the default heading to Your draft (or, Your draft article) could cover all three cases.

Another way, a bit trickier but doable, is to use the value of parameter 1 (if provided) and parse it to figure out which one of the three it is, and then alter the default heading to one of 1) 'Your sandbox', 2) 'Your draft', or 3) 'Your userspace draft'. In case of no param 1, it would just fall into the other logic and use 'Your draft article' or whatever we decide on.

The last approach would be the most time-saving for volunteers placing the template and should be the goal imho, but it is more involved. I'd like to just do a quick fix first, and change the default heading to 'Your draft article' as a first step. That would be the sole default for all three cases, but it will still be overridable using param |headtext=. How does that sound, or is there a better choice? Mathglot (talk) 20:29, 21 March 2026 (UTC)

Hidden params recapitulation

Note to self: it may be useful during the early dev phase to know what params were used in substed placements. These could be added in an additional hidden comment just before the template id at the end, and may help debugging and enhancement. See Module:Params#list_values. Mathglot (talk) 21:16, 21 March 2026 (UTC)

Default level, and single or multi-level template?

Should this be a single-level or a multi-level warning template? This template was initially designed as a single-level template. Parameter |level= provides a way to make the wording gentler or stronger, and provides a kind of halfway house between a single-level and a multi-level template, while the wording and design of the template is being worked out. If there is consensus for it, this template could be converted to a multi-level template series to host warnings of increasing severity.

Currently, the default wording comes across as a pretty strong, with mentions of both WP:DISRUPTion and WP:BLOCKing. This sounds similar to level 3 severity in a multiple-level template with four levels. For example: in the series of warning templates about unsourced edits, which violate Wikipedia's core WP:Verifiability policy and thus are extremely important and *must* not be ignored, blocking is not mentioned until level 3: {{uw-unsourced3}}. Levels 1 and 2 are more gentle.

Editors making improper categorization edits are probably doing it in good faith (at least, that is the assumption) and especially for newer editors, the default wording here sounds very biting. The concern here is that starting off with a very strict message may alienate newer users especially, who may find the whole Wikipedia environment scary and initimidating, and have negative impact on editor retention, which is a serious problem at Wikipedia. There is evidence of this already in some of the response by newer users receiving this type of message.

My thoughts now are to continue evolving the wording of the template, and take advantage of the |level= param to start off with gentler versions where possible. When the template stabilizes to an extent. I hope to use this section to brainstorm alternate wording for three or four levels. In the meantime, should we change the default level from 2 to 1? This would eliminate the last part of the last paragraph, dropping links to WP:DISRUPT and WP:BLOCK, and maybe soften some of the other language with pleases and thanks, and so on.

I recognize that one of the problems in having three levels, is you can't always get to a user the first time they miscategorize, because there is just so much of it, and because there is limited time to leave messages, so having to skip the first occurrence until it gets really severe the third time they try it, and by then, the ante is upped and it seems like maybe they deserve a strongly worded message. But if they are new, this may be the first they've heard of it, and users repeatedly inserting categories are likely *still* doing it in good faith, because they don't know about reverts yet, so to them, it just looks like their edit disappeared for some unknown reason – maybe they forgot to hit Save, or made some other mistake, or the system, new to them, did something mysterious. So they sipmly insert it again, completely innocently—we've all been there on other websites, redoing a click or send—and then they end up with the bitey message, and then get scared away.

One of the central goals of this template is to make leaving messages for the user much easier and faster, and stop the cycle described above by getting to the user much earlier in the process than the third or fourth time they do it. If we can get to them the first time, it is much more likely they won't make the same mistake the second or third time. But for this, we need gentler wording the first time.

Another way to interrupt the cycle and deal with miscats earlier on, is to get Twinkle involved. Twinkle is able to automate a sequence of multiple steps involving different pages, such as when an article is nominated for deletion. I will raise this in a different section on this page later, but we should brainstorm a desired Twinkle process such as fixing an improper categorization in a draft or sandbox, and notifying the user simultaneously with a level 1 warning (upgraded automatically to the next level if warranted, based on previous warnings on their Talk page). That would free up editors monitoring for miscats to just pull up Twinkle, check a box or too, pick a canned summary or enter one, and press the button, and then Twinkle will take care of all required steps and notifications. This should massively increase the productivity of patrolling editors in this area. Mathglot (talk) 22:28, 21 March 2026 (UTC)

I agree – when I saw the draft I assumed it was for a higher severity warning. It seems over the top for a good-intentioned editors who mistakenly included a category link. They need to know it’s a serious problem, so definitely a mistake to avoid in future, but the point could be made more gently for a first offence. --Northernhenge (talk) 21:48, 22 March 2026 (UTC)

Regarding the severity warning, here is how it is described at § Multi-level templates for disruptive editing:

• Level 1 – A notice – Assumes good faith. Generally includes "Welcome to Wikipedia" or some variant.
• Level 2 – Caution – No faith assumption; just a note.
• Level 3 – Warning – Assumes bad faith; cease and desist. Starts with "Please stop".
• Level 4 – Final warning – Starts with "You may be blocked from editing the next time...".

The current version has aspects of 2 (no faith assumption), and 4 (mentioning block possibility), but not 3 (it doesn't really assume bad faith, just lack of awareness) so it's kind of a mix. Do we want to have multiple levels? In theory, if it's going to be a standard, multi-level template series, it should look more like the recommendation. Otoh, with one principal user so far, there doesn't seem to be a need for it (yet?). Mathglot (talk) 21:41, 5 April 2026 (UTC)

Just noticed template {{Uw-upincat}}, which is pretty much like a level 1 of this one, very brief. Mathglot (talk) 23:49, 5 April 2026 (UTC)

Spaces

Users also sometimes file their userpages in mainspace categories, either because the "sandbox" draft was posted to their main userpage instead of a subpage or because it's a proper userpage but they categorized themselves, so there needs to be an option added to this template to handle actual userpages as well as userspace subpages. Bearcat (talk) 04:56, 4 April 2026 (UTC)

Signature

I've noticed that while this template normally adds an automatic signature to the end of the post without my having to manually tilde it out, that doesn't happen if I'm making the first post to a user's previously empty talk page. In that situation, I do have to type out the tildes myself if I want the post to be signed. Bearcat (talk) 22:23, 23 April 2026 (UTC)