Dwarf Fortress Wiki talk:Versions

Archives

Page 1

Version 0.31.19 starts a new DF generation?

My reading of Toady's comments on the release of 0.31.19 is that it came out basically because he felt it would take too long to get DF all the way to 0.32. With the ore changes, the sitefinder changes, the addition of grazing and several different industries, there's a lot of changes between 31.18 and 31.19. So I'm thinking it might be a good idea to call it the first release of DF2011 - and what we refer to as "DF2010" would then become 0.31.18.

Thoughts? --DeMatt 07:06, 28 February 2011 (UTC)

Revisiting Redirects

I wasn't around when the redirect policy was created, and I'm having trouble understanding the rationale. The example claims that linking Main:Cheese to cv:Cheese maker is problematic...but mainspace only ever redirects to the current version. If the best target in the current version is cheese maker, why not link to it directly? (It's not, at least for Cheese, since DF2012:Cheese exists now.) The explanation seems to be claiming that 40d articles that link to Cheese will follow the Mainspace link--but that hasn't been the case for a long while now. Articles in 40d automatically link against other articles in 40d, so that version remains internally consistent no matter where mainspace links to in the current version. For a current example, what do we gain by linking Main:Mead to cv:Mead and linking DF2012:Mead to DF2012:Alcohol?

If this really is just an outdated procedure, I recommend we drop the mummery and allow mainspace to link to cv:(best target). Double redirects may work (sometimes, but Main:Mead demonstrates a common problem where automatic redirection fails), but if they are unnecessary I think they should be avoided, partly because of problems like Main:Mead and partly because of the effort required to protect double redirects from users who believe they are problematic.--Loci (talk) 20:16, 8 January 2014 (UTC)

I was just thinking that. I'm currently attempting to write a basic extension to eliminate the need for mainspace redirects entirely, although Mediawiki's class structure may make this more difficult than I had hoped (the only method I've found for resolving redirects takes the article text instead of a title, e.g. "#REDIRECT ..."). I do agree that the current situation with redirects isn't ideal, so I'm hoping this will work better (once I get it to work). --Lethosor (talk) 20:42, 8 January 2014 (UTC)

Okay, that wasn't quite as clear as I meant it to be. In general, I think this is a tricky situation. Mediawiki wasn't designed to have five content namespaces, and certainly not chains of redirects between them. The problem that was pointed out in the policy is the fact that with:

Main:Foo -> cv:Bar

pages in the cv: namespace can't use [[foo]], since the namespace links modification causes it to be treated as [[cv:foo]] instead, which doesn't exist. The current suggested solution is this:

Main:Foo -> cv:Foo -> cv:Bar

This fixes the problem of [[foo]] not working on cv pages, but creates issues with double redirects not always working. Another solution, which is more intuitive to new editors, is:

Main:Foo -> cv:Bar
cv:Foo -> cv:Bar

Both require creating two redirects. The first method has the advantage of ensuring that the cv redirect exists (otherwise, main:foo would be a redlink), while the second has the advantage of working more reliably in a couple cases.

What I'm trying to do is make main:Foo "jump" to cv:Foo when cv:foo exists, even if main:foo doesn't exist (basically it would treat all mainspace pages as redirects to cv pages, but only if the cv page exists and not the mainspace page). I had main:Bar jumping to cv:Bar fine, but if cv:Foo redirected to cv:Bar, accessing main:Foo would mysteriously stop at cv:Foo even if I increased the redirect limit. What I'm trying to do now is follow the redirects internally, without relying on Mediawiki to do it automatically - unfortunately, that has proved to be harder than I had hoped (and I sent my web server into an infinite loop while trying). I will try to work on this some more when I get a chance, although I'm not sure when that'll be yet :(. For now, feel free to fix broken double mainspace redirects as necessary, as long as redirects in the DF2012 namespace stay pointing to the right page (and new mainspace redirects get added in the DF2012 namespace too). --Lethosor (talk) 04:21, 9 January 2014 (UTC)

You're treating cv like a namespace--it's not. It is simply shorthand for "fill in the current version here". As I discovered a long time ago on a server not far away, linking from Main:Foo to cv:Foo tends to break redirection chains. If, instead of linking to cv:Foo, you link to DF2012:Foo, it might just work. It would, of course, be better if your patch could evaluate cv itself, but even if you have to hardcode the current version it's a single point of maintenance that requires update very infrequently. (For that matter, we could probably dispense with the cv hack entirely and just have a bot update mainspace links from DF2012 to DF201X when we switch to a new version.)--Loci (talk) 20:05, 9 January 2014 (UTC)

I know cv isn't a namespace - I was just trying to avoid future confusion when the DF2012 namespace changes. It's interesting that changing "cv" to "DF2012" fixes some broken redirects, although I've found that simply making an edit to a broken redirect can usually fix it as well. I've actually had the most problems with double redirects when the second one (in the DF2012 namespace) doesn't use the DF2012 prefix (e.g. main:Foo containing [[cv:Foo]] and DF2012:Foo containing [[Bar]]). I'd rather keep the cv alias even if it isn't necessary for mainspace redirects when I get the patch to work, since it makes it easier to refer to the current version of the page (for example, several MDF articles contain links to a vanilla page for things that don't change in the mod).

Also, using aliases like "cv" is supported by Mediawiki; in fact, several WMF wikis use them (for example, "WP:Redirects" on Wikipedia). It's quite likely that Mediawiki isn't processing double redirects using aliases correctly, though, since that's uncommon on most wikis. --Lethosor (talk) 21:35, 9 January 2014 (UTC)

In light of the lack of support for the current redirect policy, I propose we replace the current redirect section with:

Mainspace article pages should use the cv: alias when redirecting to a versioned page, which will automatically update the link when a new version is released. For example, page "Main:Foo" should redirect to page "cv:Bar" (where "Bar" is the page that best describes the topic Foo in the current version).

Pages in mainspace should only redirect to an older versioned page if that content no longer exists in the current version of the game (e.g. Cave river, Chunk). In these cases the cv: alias cannot be used.

Pages inside a versioned namespace should not use the cv: alias. Instead, they should redirect to the best page within that versioned namespace (e.g. DF2012:Dodging, v0.31:Drink).

Due to limitations of the wiki software, double redirects should be avoided if possible. When fixing double redirects in mainspace, please make sure to use the cv: alias as appropriate.

If no one objects, I will make this change in a few days.--Loci (talk) 20:21, 15 January 2014 (UTC)

Okay with me. It may be worth mentioning that double redirects only really need to be changed when they don't work (since changing a lot of redirects that work isn't necessary), but I think it's clearer and more relevant than the current policy. —Lethosor (talk) 00:26, 16 January 2014 (UTC)

Done.--Loci (talk) 20:55, 22 January 2014 (UTC)

I was finally able to get my extension to work after being motivated by one too many malfunctioning redirects. It now causes nonexistent pages in the main namespace to behave exactly like redirects to their DF2012 counterparts (when linked to, accessed directly, and transcluded). Double redirects also work (up to 100, in fact, although that was a temporary safety measure that I'll probably change). This means we'll be able to safely get rid of all mainspace redirects (redirects that redirect to something other than "cv" will still function if not deleted). —Lethosor (talk) 01:20, 14 March 2014 (UTC)

What about articles which don't exist in the current version but do exist in older versions? Will those still need mainspace redirects, or will your extension be able to automatically redirect them to v0.31/40d/23a? --Quietust (talk) 01:29, 14 March 2014 (UTC)

It ignores all mainspace pages that actually have content, including redirects, so pages like masons guild won't be affected (unless deleted). —Lethosor (talk) 01:47, 14 March 2014 (UTC)

Done and deployed. Cat is still treated as a redirect, even though I just deleted it (try clicking on the "redirected from" link). Pages that exist are ignored, so Masons guild and History of Dwarf Fortress still function normally (as a redirect to a 23a page and a non-redirect, respectively). —Lethosor (talk) 18:57, 14 April 2014 (UTC)

I'm sending around a bot right now to delete all redirects of the format "foo -> cv:foo" (a surprising number don't fit this format, so I'm leaving them alone for now). —Lethosor (talk) 20:43, 14 April 2014 (UTC)

I'm confused. Do we use double redirects or not? Is there a single place we define our linking policy (including redirects), and is it updated?

I had trouble linking to Consolidated_development in v0.34:Dragon. It kept pointing to v0.34:Consolidated_development, which does not exist. I ended up linking to Main:Consolidated_development to make it work. --Nahno (talk) 10:18, 1 July 2014 (UTC)

That's a separate problem altogether - links in the versioned namespaces (v0.34, v0.31, 40d, 23a) automatically link to pages within their namespace. I may be able to set up a fallback to mainspace once I'm able to deploy again, but for now the "main:" alias is the intended solution. —Lethosor (talk) 11:36, 1 July 2014 (UTC)

Google often directs people to the 0.31 page

I've noticed a couple of times that finding a wiki page from an external search will often drop me onto a page from an older version. Is it possible to mitigate this somehow for new players? I could imagine something like redirecting old:Bar -> cv:Bar unless the user has come from old:Foo; no idea if that would actually work though. PeridexisErrant (talk) 11:48, 4 May 2014 (UTC)

As a temporary solution, I could write a script that displays a banner of some kind if the user came from an external site. I'll ask Briess if he can do anything on the server level to increase the weighting of the current version's pages. (Obviously there are situations where people are looking for old pages, like 23a:dungeon master, so we don't want to disable indexing entirely on old pages.) —Lethosor (talk) 17:03, 4 May 2014 (UTC)

DF2014?

As Toady draws closer to a new release, it might be worthwhile to discuss the addition of a new version to the wiki. The upcoming release covers two years of changes and introduces a number of new plants, foods, drinks, multi-tile trees, climbing, jumping, etc., so it is likely to have significant changes from the current DF2012. To avoid having people start new pages (and lose all the effort spent refining the prior version's page), I think it would be best to have a bot automatically copy over the DF2012 pages as a starting point for DF2014. I would suggest that these copied pages include a noticebox template mentioning that the content may be outdated, so that we can easily track which pages have been reviewed. I think either the {{version check}} or {{old}} template would work. --Loci (talk) 19:43, 5 May 2014 (UTC)

This is what User:QuietBot did after the 0.34 release, so it's certainly possible to use the same script to migrate to DF2014. I would like a way of tagging migrated pages, since inaccuracies in some pages went unnoticed for months after they were migrated. Since {{old}} is already in use, {{version check}} may be a better solution (it can be reworded slightly, or we can make a separate template for DF2014 migration). —Lethosor (talk) 19:23, 1 June 2014 (UTC)

Made Template:DF2014 migrated as an example. Any thoughts? —Lethosor (talk) 19:32, 1 June 2014 (UTC)

Redirects inconsistency

Following a redirect is supposed to be exactly the same as going straight to the page it redirects to, but this actually isn't the case:

• Go to Seeds and you get v0.34:Seed (outdated)
• Go to http://dwarffortresswiki.org/index.php?title=Seeds&redirect=no and click on the link and you get to DF2014:Seed (current)

So if you search for "seed", the top result is the DF2014 version. But search for "seeds" and you get the redirect, which sends you to the outdated page instead. Hairy Dude (talk) 23:22, 22 February 2015 (UTC)

While I'm talking about redirects, it seems redirects to sections don't work: see DF2014:How do I manage my seeds and crops. I know MediaWiki is capable of this trick because Wikipedia does it. Hairy Dude (talk) 23:32, 22 February 2015 (UTC)

I have absolutely no idea why seeds redirects to a v0.34 page - it could be a Mediawiki bug. The section links issue is due to a known issue in the redirect extension we use, which has yet to be fixed. —Lethosor (talk) 00:01, 23 February 2015 (UTC)

It looks like deleting both Seeds and DF2014:Seeds fixed things (by allowing AutoRedirect to handle the redirects instead). Feel free to tag any others with {{bad redirect}}. —Lethosor (talk) 00:03, 23 February 2015 (UTC)

It gets stranger. Vial redirects explicitly to cv:Flask which displays (when you look at it with &redirect=no) as DF2014:Flask, but still goes to the v0.34 version. It seems redirects interpret the cv: pseudo-namespace (or whatever it's called) in an outdated way. Hairy Dude (talk) 18:08, 23 February 2015 (UTC)

I've added a note to this page about this issue. If it gets resolved, the note should be removed. Hairy Dude (talk) 21:04, 23 February 2015 (UTC)

Reorganizing versions

The internet deals with moved content... poorly. Google is still linking to v0.34 pages more than a year after the switch to "DF2014", and even the wiki software still has cached links pointing to the old version pages.

I propose reorganizing versions on the wiki to avoid moving content whenever possible. Instead of having a temporary "current version" namespace that changes occasionally, all the current information gets promoted to the Main namespace. When the next version split occurs, the Main articles as of a certain revision number can be copied to the newly-created permanent "old version" namespace, while all the current information remains in Main. This not only fixes the link rot issue, but it has a few other benefits as well: fewer administrative tasks, no lockdown (a historical version of the Main pages can be copied at any point, even if the Main articles are already modified for the new version), almost all the article history is maintained in the Main article (instead of being spread unevenly across multiple versions), no "temporary" namespaces are needed, fewer problematic long redirect chains, and hopefully less user confusion (since Main gets priority in search results, etc.).

As an example, today we would not have a DF2014 namespace (which is good because "temporary" namespaces historically disappear anyway). If you ran a search for seed you'd end up at Main:seed, which would have all the current information on seeds. The version box at the top of the page would still link to the older versions of the seed article. When a new version is released, an admin would choose a revision number and copy the Main:seed article as it exists at that revision number to v0.40:seed. That's it. One historical copy that needs little to no new editing, and zero redirections/moves.--Loci (talk) 19:02, 27 July 2015 (UTC)

Makes sense to me. It would involve a lot of work, though (e.g. fixing templates and categories to account for the current version being in mainspace), although that should be doable thanks to {{category}}, {{version switch}}, etc.. A bot could be set up to copy revisions from before a release date as well, which would be more difficult (and maybe slower) than a direct copy, but not severely. —Lethosor (talk) 17:24, 30 July 2015 (UTC)

Actually, there are a few issues with that, namely that there wouldn't be an easy way to distinguish between versioned and non-versioned mainspace pages. There are ways to resolve Google search priority (we can exclude pages from older versions from search engine results if there are newer versions of those pages available, for example). —Lethosor (talk) 19:47, 6 August 2015 (UTC)

There aren't very many non-versioned mainspace pages, and determining if a page is versioned is as simple as looking for the version template and/or categories added by the version template (e.g. copy this category instead of Main:*). The problem with "suggesting" newer pages to Google is that they obviously aren't crawling our wiki regularly (if they were, the fact that the mainspace redirects point to new pages would automatically be picked up). Even if your Google hints worked they wouldn't do anything for all the other broken links out on the 'net.--Loci (talk) 20:35, 6 August 2015 (UTC)

Google actually crawls the wiki constantly - we probably get crawl hits from google for a continuous block of 2-3 hours per day, each and every day. Why they are slow to update is beyond me though. I can't remember why we didn't do this initially, but there was a technical limitation involved if I remember correctly. --Briess (talk) 22:05, 6 August 2015 (UTC)

There are <meta> tags that can be used to hide pages from search results (for search engines that recognize them, that is). Searching for {{av}} or Category:Current might work, although we'd have to make sure all of the DF2014 pages include that (some pages don't, particularly some disambiguation pages, although all of them should). —Lethosor (talk) 22:53, 6 August 2015 (UTC)

Is there a particular reason main and current are separate to begin with?—CLA (talk) 00:17, 7 August 2015 (UTC)

It's mostly intended to distinguish between versioned and non-versioned pages and make version-related templates simpler to work with, since every versioned page has a namespace. I wasn't active here in 2010 when this system was created, so Briess and Emi would know more.

Another issue I just thought of with Loci's suggestion is categories - currently, categories like Category:Animals are used to organize the versioned sub-categories. Sure, we can change {{Category}} to categorize mainspace pages in Category:v0.40:Animals or Category:DF2014:Animals, but that would be less straightforward because there wouldn't be a namespace with that name (until pages are migrated when a newer major version is released). —Lethosor (talk) 13:05, 7 August 2015 (UTC)

Moving current pages to the main namespace sounds like a great idea. -Jecowa (talk) 20:47, 4 January 2018 (UTC)

Another thought: dealing with migrating redirects could be difficult with this proposal - specifically, determining which redirects should be migrated to a versioned namespace. Redirects can't contain {{av}}, at least not before #REDIRECT. I think it would be possible to copy pages in two stages, though - all non-redirects first, then all redirects whose targets were also copied. Thoughts? Anything I'm missing? —Lethosor (talk) 23:41, 27 June 2019 (UTC)

Some subpages (particularly /raw and /Edit notice) also deliberately lack {{av}}, although those shouldn't be too hard to handle. —Lethosor (talk) 00:35, 9 July 2019 (UTC)

Redirect pages (and all other edge cases I've looked at) can be included in categories (like Category:Current) to determine whether or not they should be copied into an archival version. But if the redirects are "properly qualified" then they can all be copied over blindly. Mainspace redirects pointing to versioned information should use a blank namespace (which will be automatically constrained to the archival namespace); mainspace redirects pointing to unversioned information should use an explicit "Main" (which will automatically link back to the unversioned page). Then, when [[Toady]] gets copied to [[v0.4x:Toady]] it will point back to [[Main:Toady One]]. Meanwhile, [[Beer]], copied to [[v0.4x:Beer]], will properly point to [[v0.4x:Alcohol]].--Loci (talk) 20:00, 14 July 2019 (UTC)

I think qualifying redirects is the best solution here - categorizing redirects manually is another possible source of errors, since categories (or a lack thereof) would only be visible on the redirect page itself, and Category:Current is a hidden category. Copying over mainspace redirects into versioned namespaces would also resolve some issues that have come up due to those not reliably existing currently. I should be able to set up a bot script to add "main:" to current mainspace redirects (and it shouldn't break anything, since those redirects go to other mainspace pages anyway). —Lethosor (talk) 21:57, 14 July 2019 (UTC)

(Note: I wrote all of this without noticing the previous discussion above.) I was wondering, when the wiki creates a new namespace for a major release again, if it is possible to not create a namespace for the next current version (e.g. "DF202x") and instead have the mainspace articles (which are currently redirects) become the new cv and move the content there. Therefore, cv:Cat would just be "Cat" (or Main:Cat).

Certain namespace-related templates like Template:Ns/0 would need to be changed, though nothing significant as far as I know. For most cases, any "DF2014" would be replaced with "Main" or even blank. There's also multiple extensions handling the current namespace system and they may need to be modified too, though I'm not sure if or how much. I'm guessing based on the discussions above that it will change stuff up.

My reason is the current namespace is increasingly becoming more anachronistic. "DF2014" could be misinterpreted as "this page is about the 2014 version of the game" or "this page was last updated in 2014", which I've seen a few people in forums mention. Granted that Template:Av is on the top of very article, I still think the namespace is inconsistent with the recentness of the article. But how is this related to what I'm asking for? Let's say we continue the current system: if we happen to do a new namespace change this year and create DF2020, the next major release (after graphics/UI) will be mythgen, which is estimated to take several years to develop (the Big Wait), and so the anachronism will start over again. The proposed way will prevent this from occurring for the next major release and every release thereafter.

I think the confusion with having a namespace that becomes old-fashioned overtime supersedes the confusion with not marking current versioned articles with a namespace. Most users just search "Cat" on the search bar and naturally expect to get information about the latest release of DF. So if users go a page that's just titled "Cat", they won't expect outdated info about cats from a previous release. That's how the current system works anyways. We'll be skipping the two-step process that we have now. It'll make several wiki tasks much simpler as well. Editors can create new articles for current versions without remembering to add a namespace. It'll fix any existing issues with (double) redirects; instead of Main:Kitten redirecting to cv:Kitten, which goes to DF2014:Kitten, which then redirects to DF2014:Cat, Main:Kitten would just redirect to Main:Cat. And the cv: alias will no longer be necessary since "cv:" = "Main:" and will be forever.

There's no need to differentiate the current version and previous versions with a namespace for the current version is what I'm saying. Articles of previous versions will retain their respective namespaces. Users will still type "40d:Cat" to go to the 40d version of the article, but if they want the current version, they'll just type "Cat" (like now). The mainspace containing the "live" version of an article is natural and would create no uncertainty when browsing the wiki. And it would simplify the wiki somewhat and future-proof this anachronism problem. As a bonus, this change will also prevent web search engines from showing previous version pages when typing "DF cat" or something. (This isn't happening right now as DF2014 has been the current namespace for ~6 years, but it'll happen again when everything moves to a new namespace.)

This is the gist of it, and I may have ignored most of the problems with this proposal. I have personally wished for the whole version namespacing be made less complicated and have been seeking for a solution, and I feel like this is the best way to go about in the future. – Doorkeeper 21:27, 14 August 2020 (UTC)

Whoops, looks like Loci already proposed this exact thing long ago. I definitely missed that discussion and should have checked first. My apologies. I'll move my text to that section and remove this one. – Doorkeeper 21:36, 14 August 2020 (UTC) Done. – Doorkeeper 21:40, 14 August 2020 (UTC)

The main issue I have with that is that putting pages about the current version in a namespace also differentiates between those pages and pages not about any version (for example, Toady One does not need a 40d or v0.34 page). Yes, we can use {{av}} to mark versioned pages, but people often forget to add that to new pages. The current system also allows determining whether a page is versioned or not from its title, which makes migrations a lot faster. Relying on {{av}} would require either reading the content of every page (which would slow scripts down significantly) or cross-checking with the list of all pages including the template (feasible, but a bit more complicated, and still susceptible to missing templates). I suppose that manually fixing and migrating pages missing {{av}} later wouldn't be too much work, though.

I am definitely in favor of changing "DF2014" (or a new namespace) to "Current", though. I was in favor of "DF2014" in 2014, but I don't think it makes sense anymore, and "Current" seemed to be a popular alternative in both the DF2012 and DF2014 discussions on the matter. —Lethosor (talk) 04:02, 16 August 2020 (UTC)

Weird redirect behaviour

Pump stack redirects to cv:Screw pump#Pump stack. If you look at the redirect itself it says it redirects to DF2014 namespace, which is correct. But if you actually follow the redirect, it goes to v0.34 namespace. Hairy Dude (talk) 16:10, 20 August 2018 (UTC)

Yeah, that's part of the issue described in the above section (the wiki caching part, not on Google's end.) —Lethosor (talk) 15:00, 21 August 2018 (UTC)

v50 organization

Some wiki admins have had a talk on Discord and decided that the most sustainable path forward is to put content for all future versions of DF in the main namespace. We will be working on a bot to do this in the next few days. Feel free to chime in with suggestions here. —Lethosor (talk) 22:56, 14 December 2022 (UTC)

Is it maybe possible to do backwards-namespacing? Like we have a "Main" namespace, which people are free to update, and whenever there's a new version of DF the "Main" namespace is copied into a namespace for the then old version, much like how you'd branch a stable branch from a development branch when working with a git-project? Therahedwig (talk) 23:13, 14 December 2022 (UTC)

Yeah, we could do that if we decide to. We were talking about doing that for v50, actually, and might still do something similar to preserve edit history if it doesn't end up being too hard to automate. Our hope is that we will not introduce new namespaces for v50 -> v5x, unless there is a serious breaking change (and hopefully there isn't one). But if we change our mind, one advantage of the type of migration you mentioned is that it can be done retroactively - we can copy historical revisions that were current at the time of the release, and would only lose some typo fixes made after the release that apply to earlier versions as well. —Lethosor (talk) 02:11, 15 December 2022 (UTC)

ETA is < 24 hours. Doing some final checks on a migration script. —Lethosor (talk) 07:08, 19 December 2022 (UTC)

We should really have a task list as there are many things that change and need updating. Including but not limited to:

• Most templates that used the previous namespace convention broke, including nav templates.
• Many game files changed locations and their pages need to be updated.
• Raws need to be updated.
• Various features added, changed, removed.
• UI has been changed -- though I am more inclined to wait for classic release to avoid extra work --Jan (talk) 06:56, 20 December 2022 (UTC)

"Raws need to be updated." Including applying wraparound where necessary, I suppose - more than a few of them have proven to be that special kind of...difficult to navigate otherwise, shall we say? Silverwing235 (talk) 12:52, 20 December 2022 (UTC)

v50 migration

The initial migration script is done. New content is in the main namespace, e.g. Cat. Old content is still at DF2014:Cat. History was migrated to the new (main namespace) articles.

I know several things are broken still. Please reply if you find any others:

• Versioned templates haven't been migrated yet (e.g. {{vermin}} on Ant)
  • I am working on a script to handle this.
• Raws are missing on all pages that use them.
  • This also affects sidebars, such as on Cat and Microcline.
  • This will be addressed with an upgrade to the DFRawFunctions extension. This will take some time because the layout of the raws has changed significantly, so we cannot do a straightforward migration here.

—Lethosor (talk) 04:54, 20 December 2022 (UTC)

The quality levels of the 50.03 pages seem to be missing. I'm not sure if that's covered under that first point. Trainzack (talk) 06:47, 20 December 2022 (UTC)

If the the Dwarf Fortress Wiki:Quality feature can be made to work with namespace scheme change, I suggest to automatically assign the lowest quality rating to all pages, alternately add the {{old}} to all pages. Otherwise there will be a lot of pages that will fall through the cracks. --Jan (talk) 09:12, 20 December 2022 (UTC)

It appears some pages are redirecting recursively and never resolving correctly, like the [table] and tileset repository 07:35, 20 December 2022 (UTC)

Indeed, these can be caught here: Special:DoubleRedirects --Jan (talk) 07:51, 20 December 2022 (UTC)

It might be useful to change the notice title to "release information for editors" --142.59.195.176 10:26, 20 December 2022 (UTC)