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)