Wiki Revamp/Other Conversations

---

MoinMoin 1.9 is no longer supported in Debian and MoinMoin 2.0 is still in development, so we're taking the opportunity to switch this wiki to MediaWiki. This page summarises conversations from the mailing list (contact) and IRC channel (webchat). It will always be somewhat out-of-date and incomplete.

Debian Bug Links

The current wiki renders Debian and Ubuntu bugs specially - links get a title and closed bugs are struck through. For example, the following bugs should be struck through, and you should see a custom title when you hover over them: Debian Bug #399237 Launchpad bug 1597017.

This is implemented by including bugstatus.js in every page, which scans the HTML for appropriate links and sends requests to the bugstatus script and the launchpad script. The bugstatus script in turn uses the Debbugs SOAP interface, while the launchpad script uses launchpadlib.

MediaWiki alternatives to this solution include:

MediaWiki:Common.js is a JavaScript file included on every page in a wiki. This is the most direct translation, but can be hard to manage because of the temptation to put unrelated content in the same file. The Gadgets extension is a more powerful alternative to MediaWiki:Common.js, and seems like the natural choice for a MediaWiki equivalent of the current implementation. Scary Transcluding lets you include pages and templates from other wikis. Data is cached, with a configurable timeout. For example, this would let us run an internal service that generates HTML from some pre-existing Perl library, then transclude that HTML into ordinary wiki pages. It's the wrong tool for this particular job, but may be worth revisiting if other use cases pop up. The Cargo extension lets MediaWiki store and query data in an internal database, which could potentially be synchronised with an external database somehow. But Cargo has a poor security reputation, and synchronising data could be awkward. The External Data extension lets MediaWiki interrogate external sources like the Ultimate Debian Database. This would let us render links server-side instead of in JavaScript, but would introduce questions around caching. Allowing the wiki to query the UDD opens up a lot of interesting possibilities, and this might be a good way to make that possible. This is the solution we currently expect to use.

See also: DebianBug links on the mailing list.

Migrating user accounts

The plan is to switch from MoinMoin's built-in user database to Salsa accounts, so people will need to create a Salsa account.

The suggested solution is to disable creation of new wiki accounts at some point, give people Salsa accounts with the same username as the wiki, and ask them to change their information if they want.

See also: How to manage new Salsa accounts with the new wiki on the mailing list.

Boilerplate page headers

Pages often start with some boilerplate text (e.g. translation headers). Putting a common header template on all pages would make it easier to manage that text. See the PageHeader template for an initial demonstration.

This has been mentioned in passing, but no decision has been made.

Translations

We plan to install MediaWiki's Translate Extension to handle translation. Benefits of this extension include:

• no need to maintain a 'TAG:TRANSLATION-HEADER' block - just add <languages /> to the top of the page, and the rest is handled automatically
  • see e.g. the "Languages" block at the top of Translate Extension
• provides advanced translation tools, like showing how complete a translation is and suggesting machine translations
• may be familiar to people coming here from other MediaWiki-based wikis

We could avoid the need to add <languages /> by installing MediaWiki's Universal Language Selector Extension and enabling wgTranslatePageTranslationULS. To see how this works, go to Debian's Wikipedia page and click on the Template:MoinMarkupEmbed Languages button near the top of the page.

An alternative would be to write our own custom templates (see ExampleForTranslation). They would have no external dependencies and we could modify them more easily, but they'd be harder to maintain and wouldn't have as many features.

Another alternative is OpenStreetMap's languages template. This uses a Lua module, so it only requires the common Scribunto extension. It would probably produce a better result than custom templates, but doesn't provide the advanced tools in MediaWiki's solution.

We plan to include a template to link to localised versions of pages. So for example, if you're translating Page1 and find a link to Page2, {{ll|Page2}} will update automatically when translations of Page2 are added or removed - see MediaWiki's Localized link template, the custom ll template, and OpenStreetMap's LL template.

See also: Info request on new Wiki translations - any automatic handling of translation headers and translated pages?.

Editorial tasks (e.g. CategoryProposedDeletion)

In the current wiki, pages are added to editorial categories like CategoryProposedDeletion, with the expectation the editorial work will be made at some future date. That editorial process is discussed in the editor guide.

MediaWiki makes it easy to create more verbose and precise admonitions, with guidance on the page itself - see ExampleForProposedDeletion.

See also: IRC summary: Issues around CategoryProposedDeletion.

Scope

Discussion on the scope of the wiki is ongoing, but still in early stages. Most of it is happening in aims of the wiki? on the mailing list.

A draft for guidelines were published at MaythamAlsudany/DraftContentGuidelines and is open for discussion.

Milestones and gamification

By default, MediaWiki notifies you when you make round-numbered edits (1st, 10th, 100th etc.). This can be disable by going to event preferences and disabling "Edit milestone", but there doesn't seem to be a way to disable this by default for new users.

Automated edits with bots

We don't have bots making edits to the current wiki, but some proposals for the new wiki would benefit from automated edits. Debian Bug Links can be implemented without JavaScript, so long as editors write links as {{DebianBug|NNN}} instead of DebianBug:NNN or https://bugs.debian.org/NNN. That's more likely to happen if a bot fixes those links automatically. Boilerplate page headers (e.g. translations) need to be added to the top of each page. Having a bot do that is probably easier than educating each new editor that comes along. Editorial tasks involve scheduling some action for a particular future date (e.g. deleting a page if nobody objects for one month). Automating those actions would give everyone more certainty about the issue, and might mean non-admin users don't need permission to delete pages themselves.

An alternative would be to encourage people to help clean up the wiki in general, rather than just focus on their little corner of it. This hasn't worked before, because doing so is less inherently rewarding, risks treading on others' toes, and is unnecessarily hard work in MoinMoin.

This hasn't had its own dedicated discussion, and no decision has been made.

Interwiki links vs templates

The current wiki's InterWikiMap is quite large, and Debian Bug Links shows there's interest in pushing beyond what it's designed to handle. MediaWiki interwiki links can only be changed by editing a database table, so a direct translation would be harder to use than the current solution.

Templates are more flexible than interwiki links, and more familiar to users. So far, nobody has objected to the idea of converting interwiki links to templates.

See also a brief mention in Re: Complex conversion issues and the example DebianIRC template.

Automation (bots, modules, CGI scripts etc.)

Several features of the current wiki need some kind of automation. For example, Debian Bug Links (above) use a CGI script that updates a cache whenever a new link is added to the wiki, while the <<DebianDate(stable)>> macro is regularly updated by the get-debian-suite-info bot.

See also Bots (and automation generally) on the new wiki.

External images

The current wiki allows anyone to embed images from any site, and doesn't require image filenames to end with any particular extension. The former might change in the new wiki, the latter is sadly likely to change.

See also External images on the new wiki.

---

CategoryMigration