Delete archived wiki items

[Tertius]

I suggest the items and pages that are currently archived are actually deleted, so every trace of them is removed from the wiki.

Why:

The game has been stable in the current state for more than 2 years.
Archived items have no use. They are not relevant to the current game. They are not relevant for any game concept. There is no trace about them in the gameplay for the last years. They don't help to get a deeper understanding of the game.

I got Factorio March 2021, 2.5 years ago, and I use the wiki very much to get detailed game information. I read every single wiki page (while creating/updating a complete and up to date German translation). While doing this, and while playing the game, and while discussing several game mechanics in the forum, there was never a single need and a single mention of archived items or archived features.

They don't matter. Instead, they clutter the wiki. Worse, they come back as undead and waste editor's time. They clutter lists. Some remains I thought I killed are resurrected through the translation template. All archived items were part of the early access and development before 1.0 release. They don't matter for current and upcoming players.

With the upcoming version 2.0 of the game we should, in my opinion, concentrate on the current and upcoming state of the game. We are no archaeologists who should painstakingly conserve history but instead document the current state of the game.
Gone historical game features can be seen in the update history.

It may be we have to archive current game features with the 2.0 update. Let's do this, but after the game and the wiki has stabilized after 2.0, I also suggest to remove the then archived items as well.

If archived items should have a gravestone, I propose to create one wiki page "Removed game features" that collects historical and archived game features in a single page, sorted by removal date.

[Bilka]

I keep getting annoyed by the steel axe page (archived) because it comes up first when looking for the steel axe research (current), so I give this some hesitant agreement. I also give this some hesitant disagreement because pages like the alien artifact page are linked occasionally and preserve a lot of historical information that doesn't have any other place. The details on these pages (research costs, recipes, mechanical information) aren't in the changelog. At most you might be lucky to find them in FFFs. Otherwise you'd have to install old game versions to rediscover the info.

If archived items should have a gravestone, I propose to create one wiki page "Removed game features" that collects historical and archived game features in a single page, sorted by removal date.

If we kept information like research costs, that would be a quite large page. If we didn't, and just keep mechnical information like the page text on the alien artifact page or iron axe page, then it would be shorter. But then we'd be looking at information loss again.

[AccessViolation]

I want to start off by saying I don't have a lot of experience with Factorio but I do have some experience contributing to the Factorio wiki (and other wikis), and I have quite some experience in digital archival.

About the point that archived items have no use, this might be true currently, but we have no way of knowing what information would benefit people in the future. Outdated information isn't useful to anyone, until it is, and we have no way of knowing when and for what reason, but it is almost a given that one of the archived pages will be, eventually.

The nice thing about digital information already present is that you don't need to be an archeologist and you don't need to "painstakingly conserve" anything, all that's strictly necessary is not doing something, which would be deleting it all.
Ideally, archived information wouldn't get in the way of the 99% of visitors that are looking for up-to-date information, while keeping the archived information accessible to that other 1%.

I do understand that outdated information clutters the search and can be confusing to new players. Maybe a solution would be to create 'Archived' and 'Current' categories. All archived pages can have '[[Category:Archived]]' added to the top, same thing for the Current category with currently relevant pages. The default search parameters could then be changed to have the 'Pages in these categories' field set to Current, so no archived pages show up in the search by default, while allowing users to remove this search restriction with an advanced search. The same filtering logic could maybe also be applied to the 'archived' template, but I don't know if you can filter by pages that do not have a template, only by pages that do, so categories may be a better solution.

[ickputzdirwech]

I keep getting annoyed by the steel axe page (archived) because it comes up first when looking for the steel axe research (current), so I give this some hesitant agreement.

How about moving archived pages in to their own namespace? Like

Code: Select all

Archive:Steel axe

That way they wouldn't show up in searches any more. I don't think they should be deleted.

[Bilka]

Another issue that I neglected to mention is that sometimes people miss the "Archived" box on the page and assume the page is talking about current page content. But likely this issue can already be reduced by removing the pages from the default search.

The suggestion by AccessViolation would work for that, except our Search doesn't support exclusions or inclusions by category, so I'd have to look into why that is the case. Likely it would need some backend server work to enable a different search engine or this search option in our current search engine.

The namespace suggestion would be possible. Adding a namespace is easy and it can be excluded from the search by default. There is just with one problem: What to do with archived infoboxes. They are in the Infobox: namespace and cannot be in two namespaces at once. The option I see there is to keep them in the Infobox: namespace with the current "Infobox:Item name (archived)" naming.

However, simply moving the archived pages does not solve that their translations linger in the translation template.

[Qon]

Maybe a crude and dumb solution is good enough? Just make copy of the whole wiki, give access to it from a separate URL, like wikiarchive.factorio.com, and then delete archived pages on the regular wiki. An issue is to maintain a complete archive you would have to continue updating the archive with new pages and updates so that it doesn't lose out on new information. But maybe a simple script can just scan the up to date wiki for updates and make the same edits on the archive, except for data deletions? If the wiki software has a good API this could be quick and easy. Otherwise maybe patching the wiki software search engine could be easier...

[ickputzdirwech]

Another issue that I neglected to mention is that sometimes people miss the "Archived" box on the page and assume the page is talking about current page content. But likely this issue can already be reduced by removing the pages from the default search.

I agree with your last point there. Also the "Archived" box is too unobtrusive. A colorful icon and changing the title (to "This feature has been removed from the game") could go a long way.

However, simply moving the archived pages does not solve that their translations linger in the translation template.

We could move all the translations for archived pages into a separate section in the translation template (at least the German one needs a bit of sorting anyway imo). I started adding a comment to them so they can be found easily.

The namespace suggestion would be possible. Adding a namespace is easy and it can be excluded from the search by default. There is just with one problem: What to do with archived infoboxes. They are in the Infobox: namespace and cannot be in two namespaces at once. The option I see there is to keep them in the Infobox: namespace with the current "Infobox:Item name (archived)" naming.

Everything that is not in the main namespace can stay were it is, since a casual reader would never encounter these and editors usually are relatively knowledgeable about the game and wikis.

If the archived Pages are indeed moved or otherwise hidden from the search I suggest that a navbox for all archived pages is created and that https://wiki.factorio.com/Version_history links to it.

[Bilka]

For now I think the namespace is the best solution. It has little overhead and a large effect regarding the search, without outright removing anything. So I'll get started on the backend changes for that.

Moving the pages will need to leave a redirect, for now, to not break too many links. The internal links can then be changed with the assistance of Factorio:Redirects. After some time the redirects should also be removed, otherwise they will keep showing up in the search. But I don't want to break external links from one day to the next.

[Bilka]

I ran a script to move the pages to the new Archive: namespace. For now, the redirects exist so the old page still show up in the search. Once the redirects are slowly removed the pages will also disappear from the search.

I decided against making a navbox for the archived pages. I think the category for them (https://wiki.factorio.com/Category:Archived) and the ability to filter searches by the new namespace should be enough to navigate between these pages. I'm happy to be convinced otherwise though.

Edit: Currently the icons for the recipe product in the sandbox link to the redirect (because icon links strip out the namespace). So the redirects need to be kept until I fix that. With the way the infoboxes are coded this is sadly not a minor change.

[Bilka]

I'm slowly converting the code for the infoboxes to Lua in preparation for 2.0 and that allowed me find what to change to get them to link to the right page for the archived items. So that is now done and I have removed the redirects, which finishes off this project.

[Tertius]

Nice work, thank you! By creating an Archive: namespace that will not show up on search, one of my goals to create this thread is achieved: obsolete items don't interfere with daily wiki usage.

I don't know how the second one will work out: managing translations. A complete main translation template such as the German one is so big, it created performance issues in the past, so I worked hard to remove stuff not present any more. Some of it was added back to get translations back into archived items, which grew the dictionary again, which was the main motivation to create this thread.

Since then the hardware was upgraded, so performance improved, and I hope it stays this way if we start adding translations of the 2.0 game features.

[Bilka]

I don't know how the second one will work out: managing translations. A complete main translation template such as the German one is so big, it created performance issues in the past, so I worked hard to remove stuff not present any more. Some of it was added back to get translations back into archived items, which grew the dictionary again, which was the main motivation to create this thread.

Since then the hardware was upgraded, so performance improved, and I hope it stays this way if we start adding translations of the 2.0 game features.

Generally the size of the template shouldn't be the problem. It mostly has an impact on performance because it's used in so many pages. However, the way the wiki software queues up the jobs to update the cache of pages means that generally it shouldn't be an issue to change templates like this, it just takes some time until the caches are updated. E.g. when I changed the infobox template yesterday it took some time for things like the "what links here" pages to show the updated values. That's why the translation guide recommends to not edit the translation templates too often and instead batch the edits - that kicks off less update jobs. But I am not worried about the templates becoming too large at this point.

That being said, the Lua extension would make it possible to replace the Translation templates with Lua versions. Generally that should be more performant, but I'd have to try it out. And that has to wait until after 2.0 release.