Esolang talk:2026 topicality proposal

chinese version here: https://pastebin.com/iE7naJ8j (directly copied from the deepseek API which is very cheap, with only minor changes.) Cleverxia (talk) 11:09, 10 May 2026 (UTC)

Program examples (Category:Examples)

You didn't mention their destiny in the new rules proposal. --Blashyrkh (talk) 12:12, 10 May 2026 (UTC)

I think they should probably be allowed (although with advice that programs that would take up too much space on the page should be abbreviated / written as a description – sometimes people try to write them out in full and they take up nearly all the space on the page). Category:Program forms is a similar case of something that should be allowed but isn't mentioned. I'll try to edit this onto the page the next time I edit feedback into it. --ais523 12:17, 10 May 2026 (UTC)

I totally agree with you. It's in the interest of the wiki to include these pages, because they give examples which can help you get a feel for the esolang outside of just the main page, which may be a stub and only have a very small amount of content. --CodePentuplets48 (talk) 16:43, 10 May 2026 (UTC)

I think most people (including me) are in agreement about what to do here, but there are actually two separate points:

1. sometimes it makes sense to split a page into separate pages, e.g. because it would be excessively long otherwise (Hello world program in esoteric languages (nonalphabetic and A) is a good example), and this should be allowed (within reason) if the larger page would be ontopic;
2. we should explicitly allow lists of examples to be sorted by program-form rather than by language.

I've edited the page to explicitly permit 1., and think that we probably want to permit 2. as well, but I'm still thinking about how to express that in the rules. --ais523 20:16, 10 May 2026 (UTC)

Category:Program forms

I'm guessing that "programs written in esolangs" refers to Category:Program forms as well? the example linked is a redlink so I'm not sure what it is truly referring to —aadenboy (talk|contribs) 16:13, 10 May 2026 (UTC)

Category:Program forms is interesting: I think we probably want to allow most of it, but it's fairly common for people to just create a new idea for a program and add it to Program forms, and I'm not sure that's always desirable, so we might want a rule for what is and isn't allowed within the category. Perhaps we should require the program forms to be implemented in a sufficient number of different esolangs (because these pages are primarily useful for comparing different esolangs or talking about their computational power). --ais523 20:19, 10 May 2026 (UTC)

that's what I had considered and I think would make the most sense. I created the page Calculator (program form) explicitly because it was a commonplace program that was widely implemented yet not documented —aadenboy (talk|contribs) 20:44, 10 May 2026 (UTC)

1. +1 this. excellent proposal miui/User_talk:Miui/🌐🍟20:22, 10 May 2026 (UTC)
2. see proposal miui 21:03, 10 May 2026 (UTC)

Category:Joke languages

if I remember correctly there was some concern in the IRC around the inclusion of joke languages, though the page doesn't mention them directly —aadenboy (talk|contribs) 18:50, 11 May 2026 (UTC)

From my point of view, it matters mostly a) whether the language is actually a language, in the sense that you could determine the behaviour of a given program (even if the behaviour is always uninteresting), b) whether the same (or substantially similar) language already exists (in which case we should merge the pages) – some very-low-computational-power languages (which are generally seen as jokes) have been invented numerous times (like "all programs are quines" or "all programs are no-ops"). Apart from that I don't think it makes sense to draw a distinction: some things have historically been classified as joke languages despite being perfectly usable as "regular" esolangs, and so it makes sense to draw a line using more objective measures like computational power. --ais523 22:35, 11 May 2026 (UTC)

I think it makes sense to have multiple categories for this, although I'm not sure what they should be called. There can be a category for languages that are humorous somehow, and a category for languages which are unimplementable (as in their specification specifies something that cannot be realized or adequately defined). Zip (talk) 00:28, 12 May 2026 (UTC)

Category:Uncomputable does exist. I guess a category like Category:Humorous would be in the ballpark for the former? —aadenboy (talk|contribs) 00:36, 12 May 2026 (UTC)

Pages that are themselves art

Some pages on the wiki (for example Tables or Utopia Divine) seem like they would fall under "Pages about art that resembles a description of a programming language", but the art in question is the pages themselves. According to the rules proposition outlined here their respective pages should contain a dry description of the idea behind both pages, but should we look to move the articles as they are currently (the art in question) outside of the wiki? I would be sad to see them moved elsewhere, since it would presumably make them less discoverable and more prone to being lost, and it's not a case of moving art from outside to be hosted on the wiki, the wiki was always a part of the art. On the other hand they clearly contradict the approach outlined in the "Pages about art that resembles a description of a programming language" paragraph, for example using categories meant for actual languages. Olus2000 (talk) 19:15, 11 May 2026 (UTC)

I think it's generally inadvisable for these to be hosted on the wiki, for reasons explained in the current proposal – the wiki format just doesn't work correctly for them (both because the page can't be improved by other people by editing it, which is required for a wiki page, and because people looking for information about the language can't find it because they find artwork instead). For things that have historically been hosted on the wiki, probably the easiest approach is to link to a permalink when writing about them. I guess there might also be the possibility of using a different namespace. (Note that at least for Utopia Divine, it would be fairly easy to write about, especially because the actual "encrypted specification" is on archive.org – the article would presumably mention the possibility that the language never existed and the specification is just random data.) All that said, I think this is the potentially most controversial point in the proposal (and one that I've been thinking a lot about). --ais523 22:31, 11 May 2026 (UTC)

I would argue this is a good scenario for child pages: The main page contains description / discussion fit for a more traditional wiki, and the child page contains the art itself. I argue that with this kind of sufficient disclosure (plus perhaps a new category for the child pages), artlangs can coexist well with more "factual" content. At least from my perspective, many of these artlangs wouldn't exist at all were it not for the medium offered by this wiki, so it would be a shame to stamp them down. RocketRace (talk) 01:36, 12 May 2026 (UTC)

This is an interesting suggestion. One of my main concerns is that this sort of language-mimicking content is easy to produce in large volumes (at least one user has been doing exactly that recently, and LLMs can do it too), and may end up drowning out the rest of the wiki if there aren't at least some limits on it. I guess the problem is that there's an easy solution to actual languages produced in large volumes (you merge closely related languages onto a single page, both to make the more interesting languages easier to find, and so that all of them benefit from discussion about any of them rather than needing to have the same discussion every time), but you can't really apply the same solution to specification-resembling art – and it's quite difficult to draw a borderline for whether this sort of content is sufficiently artistic or not to be worth including! It's very easy to just say "this is a language about subject, and the hello world program is program, and the brainfuck interpreter is program" – Esme is one of the earliest examples of this sort of thing, but it's been happening a lot more recently. There's normally some nonzero artistic value in it, but I think most people don't want a wiki that consists primarily of such pages, and it's hard to draw a borderline between those and the pages that we want to include (which makes life hard for the admins as they have to make apparently arbitrary decisions). Does anyone have suggestions for trying to deal with the conflicting requirements? (This is probably the primary problem that we need to figure out how to solve before we can have new topicality guidelines.) --ais523 05:20, 12 May 2026 (UTC)

The concern is that low-quality pages would flood the wiki, yes? I'm inclined to think that the friction of a) creating a non-stub descriptive main page, and b) categorizing and properly marking a subpage as an art piece acts as a good filter for effort and thus quality. (And of course that is something tangible that can be enforced.) It still kicks the subjective can of "okay but what is actually acceptable content" down the road but it's a more productive question when all the lazier edits are accounted for. RocketRace (talk) 12:28, 12 May 2026 (UTC)

I think this is an interesting idea, but I am worried about what would/should happen if people just create such pages anyway, in violation of the rule. Do we delete them? Do we try to rewrite them in the proper form? (In the latter case, there isn't much effort filter any more.) --ais523 18:55, 12 May 2026 (UTC)

Wouldn't it be fine to leave it to whichever editor finds the rule violating page? If they decide to delete it it shouldn't be a problem since the page shouldn't have been there to begin with, and if they decide to rewrite it then there now is a human who decided the concept is worthy of existence and put in effort to present it properly. What should not happen is simply recategorising the page as "art" or "joke" and leaving it as is. Olus2000 (talk) 06:03, 13 May 2026 (UTC)

Some other cleanup actions an editor could take: combine all art pieces by the same author into one page of their oeuvre, move an art piece to its author's user namespace rather than the main wiki namespace, or merge it into a "themed collection" of similar artwork. If we get a lot of LLM-generated low-effort pieces, they could be combined into a page for LLM-assisted pieces. However, I don't think those merging abilities should hold an editor back from pruning low-quality pages, especially if they fail some procedural test that emboldens the editor. For example if more than one person has contributed to a piece, then it may be of general interest, whereas if only one person (or zero people) have contributed to that piece, then that's a sign that an editor can delete it at their own discretion. IFcoltransG (talk) 21:25, 18 May 2026 (UTC)

How would "esolanging" work after this?

Some people (including myself) come into this wiki to make esolangs from scratch and have it published here--esolanging, as I and others might like to call it--sometimes with no interest in trying to implement them. As a result, these "thin-air" esolangs tend to have this wiki as its sole proof of existence, which is bad for the first (and probably second) reason specified in this section. Given this, how would esolanging work if this policy takes effect?

1. Should users put their new esolangs as drafts? This approach has been practiced by many users here (like myself, with User:Gilbert189/Languages in concept), but it doesn't eliminate the problem that these languages may have no other sources to refer to them than here.
   • Also, wouldn't too much of these drafts cause further problems?
2. Or should we perhaps disallow esolanging here altogether? Not to say that we shouldn't put our languages in this wiki, but rather that it should be documented somewhere else, so that it can be cited here.
3. Maybe something else?

--Gilbert189 (talk) 19:16, 11 May 2026 (UTC)

I don't think the section you linked is concerned with esolanging. The examples in that section are art that references languages but don't describe them in nearly enough detail to consider them to have an actual language behind. Describing a language without implementing it is significantly different in that an actual language is involved, many languages described on the wiki are not implemented. Using drafts makes sense for, well, drafts, but when an idea is complete enough to be called a full language I see no issue with publishing it in its own article (unless it's uninteresting or too similar to another language). Olus2000 (talk) 19:43, 11 May 2026 (UTC)

oh nice, i do this too! art is more like when there isn't actually a real language behind it, like 0 bits, an eight byte emerald 01:32, 13 May 2026 (UTC)

I want to point out that this goal and your point are always going to be misaligned. We could ask for notability or verifiability first: if one don't have a free e.g. Neocities page which documents their language then it might as well not exist. The problem is that a sufficiently-motivated grifter can simply steamroll over public perception by being sufficiently loud; a great example is wikipedia:V (programming language), a relative of Go which was mostly vaporware for half a decade and still doesn't fulfill most of its marketing claims. As nice as it would be to require programming languages to relate to the task of programming a computer, it has become clear that we can't actually define such a requirement.

There may be an irreconcilable difference in opinions here. You're not alone on your side; APL and Lisp are famous examples of languages authored for the blackboard which were not intended for computer implementation but ended up on the computer anyway, defying the expectations of their authors. At the same time, the challenge of implementation (and the fact that the language was defined without one) is sometimes the point, as with But Is It Art? or Sammy. I suppose that the deeper issue, and one that definitely can't be defined, is that many of the thoughtless contributions stubbing vanity articles are fundamentally disinterested in computer science at a theoretical or applied level; they're offtopic in a way that can't be rigorously explained without some sort of demarcation between pseudo-computer-science and computer-science concepts. Corbin (talk) 16:13, 13 May 2026 (UTC)

One correction – But Is It Art? exists mostly to be a counterexample to a wide range of statements people make about programming languages (e.g. it doesn't have anything that corresponds to control flow and doesn't really have commands in the traditional sense). This happens to make it difficult to implement as a side effect, because most guides to implementing languages are based on the language looking vaguely like how languages normally look, but that wasn't the point behind the language. --ais523 22:43, 13 May 2026 (UTC)

I think it's valuable that people can make esolangs from scratch and then post them. I've recently posted both Insercle and Fading Shout, for example, and the page on this wiki was in both cases the first anyone but me knew about them – I definitely want to be able to keep doing that in the future! In my case, I guess the value in the language is that there's something to think about there, plus a potentially useful nontrivial mathematical result (e.g. Fading Shout took me two days to prove Turing-complete, although I worked most of it out today). The ideal, though, would be that it requires actually making an esolang – in the sense of working out a set of components that fit together to make a coherent language that serves some purpose, whether mathematical, practical but not mainstream, or artistic – rather than just renaming the commands of an existing language or producing a set of commands that are chosen arbitrarily rather than with logic behind them. Now I'm wondering whether a good criterion would be something like "you can say something about the language that's unique to the language and isn't obvious by looking at the specification" – because that's the minimum that you'd need to be able to write an article, rather than just copy the specification. --ais523 22:41, 13 May 2026 (UTC)

Behaviour vs. Content

It's not so much about the content, but behaviour. Many of the points on the page are good common sense guidelines, but could still be the subject of nit-picking in practice. High frequency or persistent "low quality" edits are just disruptive to a wiki. The "low quality" is subjective, but it's the persistent or frequent part that makes it a problem. Polite warnings and helpful suggestions for how to be more constructive would be appropriate, followed by temporary, then permanent, bans if ignored.

For esolangs, we should indicate that the community is unlikely to be interested in:

• every thought or idea an editor has leading to a new wiki page
• near repetitions of concepts that exist elsewhere on the wiki, likely better expressed
• poorly communicated ideas that cannot easily be reviewed or utilised by other editors (as either technical, or artistic references)
• any kind of meta wiki-gaming activity like earning achievement-badges for edit quantity and pages created (I've seen many users behave like this was a goal, and some user pages seem to explicitly state it)

For the esolanging mentioned above: making up esolangs is part of the hobby, but we should make it clear somewhere that not every hobbyist's language needs to be documented on the wiki. Esolanging doesn't have to happen entirely on wiki. Most long term regulars here have many languages they created but aren't documented, as they were stepping stones to learning, or making something else that is worth documenting. Most people's "my first esolang" is unlikely to be that good (sorry!), but it doesn't mean you shouldn't make one. You can make one without adding it to the wiki too. Many people probably do this already.

It's a bit subjective, but I personally think users who demonstrate an unwillingness or inability to write interpreters for their own languages, or for others on the wiki, in 'normal code' or other esolangs are skipping a large part of the hobby. Programming is a large part of esoteric programming, and avoiding it entirely to focus on wiki editing feels more in line with "low quality" contributions, and is unlikely to lead to any kind of improvement; in personal coding skills, or generating better content anyone cares to consume.

The basic content of the topicality page seems good, and represents current norms AFAICT, but for all the many ambiguous cases (where we get the problems) perhaps there needs to be a recognised way to challenge the content on the talk page? Is this a programming language? Contradictions? Potentially interesting ideas, but needs some work to be comprehensible, More detail required etc. Some older pages have records of this kind of interaction, but with more recent high-frequency edits no one can be bothered to even challenge or interact with them. Talk-page templates with links to a help-page section might make these guidelines more effective? Even art pages should have some standards, and if the creator can't be bothered to provide a sentence or two to clarify or justify it's presence on the wiki: burn it.

Another idea to speed-bump behaviour: new users' first new page goes through a draft review process. No idea how awkward mediawiki make this to configure, or if there's any appetite to perform peer-reviews (not suggesting reviewers should be admin at all!). That is maybe overkill. Having clear on-topic guidelines makes it easier to point out egregious violations; Necessary, but maybe not sufficient.

Specific areas of content I question (which may not be fully reflected on the current page):

• Those 'badly translated' language pages annoy me because there is nothing that can be done with them. I considered critiquing them since they barely fit into any definition of programming or formal language theory, but was worried that taking the premise seriously would end up justifying them somehow.
• Category:User_Edited: The concept is not necessarily terrible, but the naming is. Whatever the point of those pages is, it seems ill-defined and ill-managed, and tends towards 'meta wiki-gaming' which isn't a goal here. However, working collaboratively isn't bad, so maybe there's a way to make it work.
• Clarifying language sub-page use: I've seen them used appropriately for public domain interpreter listings, proofs, common constants, algorithms, and maybe character encodings related to a language, but am not sure where this is documented or how much it is standardised.
• one extra: Why are Categories even user editable? It's almost a running joke: new users to the wiki must create a category without discussion. Can we have a category creation template that states in giant red warning letters that whatever category is being created is probably a terrible idea, hasn't been sufficiently thought about, and will never help anyone locate anything of value in the way the creator was hoping, and it's only the edge case which don't fit neatly in-or-out of your new category that are interesting anyway? Salpynx (talk) 07:24, 12 May 2026 (UTC)

Those badly translated pages annoy me, too. They clog up the random page results with nothing esolanglike that can really be gleamed from them aside from 「yeah that's weird I guess」RocketRace (talk) 08:38, 12 May 2026 (UTC)

Unpopular opinion here. I think the best option might be to split this wiki in two. This wiki, esolangs.org, will be repurposed for primarily documenting esolangs. A new wiki (likely on a subdomain of esolangs.org, please don’t put it on Fandom) should be created for esolang creation. User-edited languages should be moved to the second wiki, and so should some joke languages. hotcrystal0 16:57, 12 May 2026 (UTC)

there's alternatives to Fandom like Miraheze —aadenboy (talk|contribs) 17:04, 12 May 2026 (UTC)

I know, but I still think it should go on a subdomain of esolangs.org. hotcrystal0 17:11, 12 May 2026 (UTC)

I don't think "just put them somewhere where I don't have to see them" is an effective response to content that is not topical. At that point why not just delete the offending pages? A separate namespace/subdomain makes sense if the group of pages stand out on their own terms. As it is, this would just be a soft deletion (for visibility purposes). RocketRace (talk) 18:24, 12 May 2026 (UTC)

Regarding any potential mass deletions

I do not want to see any mass deletions following whatever is the consensus here without any advanced warning. If any category of page or specific pages are going to be deleted, please give a grace period of 7 days for anyone interested in such pages to move those pages off-site. hotcrystal0 16:57, 12 May 2026 (UTC)

The wiki should not be a primary copy or repository for anybody's work. Make your backups now. Corbin (talk) 17:25, 12 May 2026 (UTC)

Correct, however it is still likely that users wouldn’t make backups until they’re properly warned. That is why I suggested a warning 7 days before a mass deletion in the first place. hotcrystal0 17:27, 12 May 2026 (UTC)

I can see an argument for having some sort of template with a name like {{offtopic}} that can be used both as a method of flagging offtopic pages for admins, and as a warning that the page might be deleted (you would mark the page as offtopic first, then delete it after a week). --ais523 18:51, 12 May 2026 (UTC)

I was going to suggest the same, but hesitated because it means a shitload of job for admins (hunting down bad pages etc...). But since an admin offers it, well... --Blashyrkh (talk) 21:31, 12 May 2026 (UTC)

It’s better if there’s one warning on the front page combined with the {{offtopic}} template. A user might not realize that their page needs to be moved until it’s too late. hotcrystal0 19:14, 12 May 2026 (UTC)

as far as I'm aware, such kind of functionality isn't available up-front unless we use the user's talk page. there's also a good chance they simply won't check the wiki within the one week —aadenboy (talk|contribs) 19:17, 12 May 2026 (UTC)

Deleted pages are backed up, so they can be retrieved by admins if necessary. --ais523 21:39, 12 May 2026 (UTC)

is Esolang:Wiki_dumps up to date? if so, that can be used -- somefan (talk | contribs) 19:25, 12 May 2026 (UTC)

How does one request a deletion of one's own page? I would like Oragami to be deleted it isn't an esolang. Miui (talk) 16:10, 13 May 2026 (UTC)

You can either add it to esolang:candidates for deletion, ping an admin on their talk page, or wait for the process we're currently discussing to conclude and add it to the list of pages for this process to delete. That said, I have two questions. First, why did you contribute a non-esolang-related article to the wiki? Second, why do you think that the article cannot be repaired by other editors? Corbin (talk) 16:17, 13 May 2026 (UTC)

A) sadly it was difficult to tell at first. B) that would be amazing and oragami got convoluted to me, I wanted ultimately to understand Shakespeare Program. The tag program can be power-queued rather than wholly "array changed" and I can not fix that page, but I do have an idea I can come back with which is more holistic. Miui (talk) 16:23, 13 May 2026 (UTC) (p.s. sorry I'm bad at wikistuff)

Adding to this — a few suggestions on how to make the deletion process less disruptive than it might otherwise be:

• 30 days, not 7. Many editors don't visit weekly, and the original author of an at-risk page may not be a regular at all. A month is long enough for occasional contributors to notice and rescue work; a week mostly catches the people who are already paying attention.
• Notify the original creator on their user talk page when their page is tagged offtopic, in addition to the page banner. Watching banners on the front page assumes a level of engagement that many of the affected authors won't have.
• Public archive, not just admin-side backup. "Deleted pages can be retrieved by admins if necessary" still functionally removes them from the community — non-admins can't read, link, or learn from them. Consider an Archive: namespace (deindexed, clearly marked as historical) for pages removed under the new rules. The proposal itself argues that abandoned esolangs are more worth preserving, not less; a hard delete contradicts that.
• List affected authors in the deletion announcement so they can rescue their own work even if they've forgotten which pages they wrote. Ramonchis (talk) 20:24, 15 May 2026 (UTC)

this message seems AI generated —aadenboy (talk|contribs) 20:27, 15 May 2026 (UTC)

An Archive: namespace completely defeats the point of the mass deletions... please tell your AI to keep that in mind. But seriously, I guess a 7-14 day grace period could work well and notifying the page creator on their user talk page what pages will be deleted is generally a good idea. But the wiki is NOT AN ARCHIVE, for that look at The Esoteric File Archive or the Wayback Machine. Also I just scrolled up and apparently, deleted pages ARE backed up so you can probably ask an admin to retrieve any of your deleted pages. raiseafloppafan3925 【mag-usap tayo (talk)・投稿】【▼(°v°)▼】 23:08, 15 May 2026 (UTC)

Which (if any) of these points do you personally agree with? The whole point of a discussion like this is to gather opinions and try to form a consensus. If you ask an LLM about the page, it will present a list of opinions that other people have held in the past in similar contexts, but that doesn't make it clear whether or not anyone actually agrees in the current context (especially as some of the points made above are missing context specific to this wiki, e.g. "watching banners on the front page" is irrelevant to the current discussion) – and pasting LLM output has the effect of making it very hard to determine what the poster thought, as the LLM tends to drain all the originality out of what you originally wrote. Additionally, anyone else could put the text into an LLM and get a similar list, so reposting the output it produced when you did that is not useful. --ais523 01:38, 16 May 2026 (UTC)

Merging pages

The policy proposal page lists Unary, Lenguage, and Ellipsis as examples of a language reinvented multiple times and suggests that they be merged. Another wiki I’m on has a system where related concepts to a certain concept that are notable enough to be documents but not notable enough to deserve their own page should be put on the page of the notable one. I think that similar to that, all the less interesting trivial BF substitutions should be merged into the trivial BF substitution page. hotcrystal0 17:38, 12 May 2026 (UTC)

I agree with this (or maybe there are enough to have both a page about the concept of a trivial BF substitution, and a separate list of trivial BF substitutions), although I think it's already envisaged by the current wording of the page. A list would be more useful than the current separate pages, because I sometimes need to find a BF-equivalent with a specific set of commands, and a list would make it much easier to check whether it already exists than trying to check every page in the category. --ais523 18:53, 12 May 2026 (UTC)

Collaborative languages

I think a policy section on collaborative languages should be something like this:

It is okay to document a language meant to be collaboratively edited by users, as long as there is a definable point or consensus where the language is considered “complete”. This doesn’t mean its specifications cannot be changed after it’s “complete”, it just means that it’s a point where there will be no further major updates to it.

I suggest listing CAPI as an example of allowed collaboration and user-edited languages as one that’s not.

Additionally, if a new wiki for “esolanging” is not created, I suggest to move all extant user edited esolangs to a new User Edited:[title] namespace as well as permanently protect them to freeze them as permanent records.

hotcrystal0 19:23, 12 May 2026 (UTC)

No. Please sign up for a git forge and collaborate with git repositories; there are many free options. The wiki is not a free website host. Corbin (talk) 21:05, 12 May 2026 (UTC)

I'd considered "esolanging" a broader concept than setting up a public bulletin board and asking for command submissions one by one. This sounds like a language-creation game that maybe should be documented once on wiki, with notes on how the computational power is undetermined until a certain threshold is reached, then it (generally?) can't decrease, how versioning makes it unlikely an interpreter could be usefully written, unless contributions were made via a public code repo, and a pointer on where and how to play (off-wiki!). It needs a better name to indicate the restricted scope. Eso-quisite Corpse? It's not a great way to design a good language though, and "esolanging" should be more than that.

I think the current / proposed rules prohibit collaborative creation, but permit collaborative discovery. A rudimentary, but in some sense sufficient, spec is posted and the community collaborates to find its computational limits and details that satisfy the definitional constraints. I can see how CAPI gets closer to that second definition, but I'm sure there are better examples; it feels borderline. Those linked user created concept pages (x-complete) also need a higher threshold of relevance or usefulness than language articles. Salpynx (talk) 21:54, 12 May 2026 (UTC)

No. You got “esolanging” completely wrong. “Esolanging” here refers to making an esolang from scratch and posting it somewhere. The term has been used before here. hotcrystal0 00:23, 13 May 2026 (UTC)

We seem to be using the same word but thinking it means something different? I don't see a problem with "making an esolang from scratch and posting it somewhere", I agree that this is an appropriate use of the wiki, although 'posting it' should be 'creating an article about it' in a wiki context, which is always collaborative.

Just looking at some User Editable category pages: Mystery, Guess, ∫∫∫∫∫∫∫∫∫∫∫∫∫, they seem to fail because they don't appear visually or functionally to be articles about topics, which is what I'd expect for a main subject namespace on a wiki. Those pages + their talk feel like wandering into the middle of a conversation with no context. Edit histories show non-article like patterns of behaviour like moving staging content to other pages. There might be a way to convert these pages into articles about the languages named in the title. Having wiki language pages in the form of articles that can be understood, edited, or improved by any wiki user sets a pretty low bar that efghij, a language article that describes some "user editable" characteristics, easily passes. The danger with these other pages is editing them into a decent article format appropriate for the wiki would likely destroy the primary source of information, which is a reason to prevent them in the first place. A language spec can be contained within an article, but wiki pages really need to function as articles first and foremost for other users to understand how to interact with them. Salpynx (talk) 03:19, 13 May 2026 (UTC)

The big problem

There is a big problem with this. If these changes are made, then it is likely that esolangs will become way less friendly to beginners. While I know this proposal is made in good light, I wouldn’t proceed with it unless someone actually does the work to set up a new esolanging wiki. hotcrystal0 10:53, 13 May 2026 (UTC)

Why don't you go do that work? At any rate, we don't have good introductory paths for new editors or newbies in computer science, I agree. We could do better. However, I don't think that a lack of introductory material is the reason why people make low-quality contributions. Rather, I think that people make low-quality contributions because they have been told by others that this wiki is a good spot to make such contributions; there is a perception of no quality control. This has always been an illusion because every page is a collaboration and a low-quality page only stays that way when it has no external references or connection to the wider world of computing. Corbin (talk) 16:00, 13 May 2026 (UTC)

Less friendly to beginner authors - maybe. Less friendly to beginner readers or programmers - certainly not. Current average material quality may frighten newcomers, especially ones with serious intents. --Blashyrkh (talk) 21:47, 13 May 2026 (UTC)

As much as I want to, unfortunately I can't. I'm pretty busy in real life with stuff. hotcrystal0 23:30, 13 May 2026 (UTC)

A few smaller points on the proposal text

Some suggestions that don't fit cleanly into the existing threads:

• LLM rule needs an evidence standard. "LLM-generated descriptions are not allowed" is the right rule, but the proposal doesn't say how authorship is established. Without something concrete (self-disclosure, admission on the talk page, or specific textual markers), this becomes a vector for accusing anyone with a verbose or formal writing style of using an LLM. Suggest adding language to the effect that detection should rely on author admission or clear textual evidence, not stylistic suspicion alone.

• Reconsider calling inaccurate edits "vandalism". The current wording treats edits that don't match how a language is specified/used as vandalism. That's too strong for what is often a good-faith misunderstanding, and it'll chill participation from newer editors who are still learning. Suggest "such edits should be reverted as inaccurate," reserving "vandalism" for clearly intentional damage.

• Soften the user-subpage rule. Requiring subpages to be "on-topic as an article" except when unfinished is tighter than how subpages actually get used in practice (sandboxes, working notes, drafts of proofs that may or may not pan out). Suggest "must be plausibly working toward on-topic content."

• Templates section could be perceived as dismissive. "This wiki only covers a single subject, so any useful templates are likely to have been created already" undersells what's still useful — language infoboxes, paradigm/category navigation, and citation templates are all areas where new templates could legitimately help. Reframe as "new templates should be discussed on the relevant talk page first" rather than "almost never needed."

• Merging requires a process for non-obvious cases. The Unary/Lenguage/Ellipsis example is uncontroversial, but messier merges will be. I would suggest adding non-obvious merges should be proposed on a talk page first, and the resulting redirects should preserve attribution back to the original page histories.

Ramonchis (talk) 20:28, 15 May 2026 (UTC)

You might not realize it, but generative chatbots are bad writers and their voices are easy to recognize as distinct styles. Moreover, we can often guess which bot was used to produce a hunk of text. If you couldn't be bothered to write it, we shouldn't be bothered to edit and maintain it.

Our definition of "vandalism" is the same as wikipedia:vandalism on Wikipedia. It's true that the majority of vandalism is benign, but also true that the weight of vandalism can ruin a wiki.

User pages are not personal property. They are public-domain content, same as the rest of the wiki, held to the same policies. The fact that user pages have sprawling subpages and multiple sandboxes, in defiance of policy, is an instance of wikipedia:normalization of deviance which we shouldn't tolerate further.

Don't paste chatbot output here again, please. Corbin (talk) 21:07, 15 May 2026 (UTC)

We already have infobox proglang for language infoboxes. Category navigation templates already exist for the year categories, and Esolang:Categorization exists as a central directory for all categories. Also correct me if I'm wrong but MediaWiki does have built-in citations, just look at a Wikipedia article or some of the more formal articles like the brainf**k article, so citation templates would be redundant. We really do not need any more templates.

About user subpages, most of the examples you mentioned (sandboxes and drafts of proofs) are most likely considered on-topic. Also as an offender of this rule, you really do not need more than one sandbox, since you already have Special:MyPage/Sandbox. But what do you mean by "working notes"? If you mean something like Scratch's "What I'm Working On" section in your profile, then I guess that's not allowed since the wiki wasn't meant to be a social media site. If you mean a "to-do list" then that is likely not allowed either, since the wiki is not a general-purpose webhost.

Also, LLMs are not that good at writing complex sensible factual texts, which is exactly what a good article is. They tend to "hallucinate" (fabricate information) a lot or be inconsistent across longer texts. RaiseAfloppaFan3925 【mag-usap tayo (talk)・投稿】【▼(°v°)▼】 22:57, 15 May 2026 (UTC)

Deadline?

Is there any ETA when the new proposed rules are put into effect? --Blashyrkh (talk) 10:41, 18 May 2026 (UTC)

Not a specific point in time – it's based partly on how well the discussion is going / how well people agree with each other, and partly on making sure everyone who wants to contribute has had a chance to do so. (It is possible that the new rules won't all be enforced simultaneously: if some are uncontroversial it makes sense to start enforcing those first.) --ais523 11:18, 18 May 2026 (UTC)

An edge case for user-edited languages

There seems to be an edge case for user-edited languages: ones where the language’s dialects are made by different people, but each individual dialect specification is constant and not fluid, for example ™. Should these fall under the proposed rules on user-edited languages or not? hotcrystal0 21:06, 29 May 2026 (UTC)

This isn't really a user-edited language, but lots of similar languages on the same page (which is a good way to represent similar languages). --ais523 21:33, 29 May 2026 (UTC)