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'll be concrete then: Crazy J and examples' subpages (Crazy J/Truth-machine, Crazy J/QUINE etc...): are these ok? --Blashyrkh (talk) 12:55, 10 May 2026 (UTC)

I don't have the authority to bless Crazy J but I think that it is allowable. I would suggest that it reads as though there isn't yet a Crazy J compiler akin to existing tools for BLC; that's not a bad sign but it is a sign of an immature article. With work, I expect that it could get to the same level of quality as the main article on combinatory logic, where there is not a need to pad out the article with long strings and we can keep programs short enough to communicate useful information to the reader. Corbin (talk) 15:17, 10 May 2026 (UTC)

My question was not about Crazy J per se but about the articles' structure in light of the proposed rules changes. Is it (or would it be) allowed to place examples on separate subpages and provide them with exhaustive explanation? --Blashyrkh (talk) 16:03, 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)

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)

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)

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)