LWN: Comments on "Arch shares its wiki strategy with Debian"

Wiki markup isn't too bad

sl2c — Sun, 21 Sep 2025 05:53:48 +0000

Honestly, from my reading Wikipedia internals lately, it being different from Markdown is actually an advantage, because it makes it that much more obvious that someone copy-pasted from an LLM when their text is covered in double-asterisked words.

Wiki markup isn't too bad

cscott — Fri, 22 Aug 2025 18:50:21 +0000

It's also taken nine years *just to write a spec* for markdown (commonmark started 2014, latest version just published 2024-01-28). Things which look simple on the surface can be surprisingly hard to nail *all the way down*.

And that's the case for wikitext, for sure. Parsoid has been in production use since 2012, and has powered all the mobile apps for almost as long. Many many other WMF projects have been using Parsoid HTML for a decade. Before we completely ditch the old legacy parser, however, we need to make sure that 99.<some number of nines>% of Wikipedia's >100M pages are bug-for-bug compatible, because we take seriously our duty as custodians of the knowledge base which is Wikipedia and the WMF projects. At this point you might consider our work more 'archivist' then 'engineer', in that our main effort isn't the parser, per se, but preserving the rendering of existing articles.

The goal of Parsoid is to render pages into well-specified semantic HTML, which preserves all the meaningful information (template boundaries, template arguments, invisible constructs, etc) of the original wikitext. This isn't *just* to allow us to use an HTML editor and round-trip back to the original wikitext, it also paves the way for other editors and markup languages in the future: as long as it can round-trip to and from "MediaWiki DOM Spec" HTML, you can use it to edit wikipedia.

More information: https://en.wikipedia.org/wiki/User:Cscott/Ideas/A_Dozen_V...

Wiki markup isn't too bad

smurf — Mon, 18 Aug 2025 21:04:56 +0000

Counterpoint: if you need 15 years to write a correct parser for a markup language, that markup language *is* bad, almost by definition.

Wiki markup isn't too bad

paravoid — Mon, 18 Aug 2025 14:27:32 +0000

Parsoid is indeed the next-generation parser, is being actively developed by a fully staffed team, and has been for ~14 years by now, if I'm not mistaken. It's *still* not the default for read views which speaks to the complexity of the problem (among other reasons). The Wikimedia Parser/Parsoid team will be the first to tell you how difficult wikitext can be in terms of semantics, so I don't think the criticism here is undeserved.

Parsoid is supposed to become the default for read view on Wikipedias by July 2026, and the default for MediaWiki 1.47 LTS (Nov 2026), with the legacy parser to be ultimately deprecated in 2028. These timelines have slipped multiple times before, and the language the WMF folks use to announce them is... careful ("tentantively scheduled", "we hope", etc.), so don't hold your breath. Fortunately one can already benefit from it by using VisualEditor, including on the new Debian wiki.

https://wikimedia.eventyay.com/talk/wikimania2025/talk/UU... and, linked from there, https://docs.google.com/presentation/d/198_UG5VmHYMoO_38s... is probably the most recent update from the project.

DRY

claudex — Sat, 16 Aug 2025 09:11:40 +0000

I'm not sure about the 90% of the same information. I think they is a lot of difference that can be useful in the wiki. The number of package and the version will impact a lot for the option available. There is not AUR equivalent in Debian which is frequently referenced in the Arch wiki. The stable nature of Debian imply that a lot of workaround for bug found (or not fixed) after the release can also be documented. Using debconf instead of modifying the configuration file for the most common installation is also something most casual users would be interested.

Thank you Arch Linux documentation team

smoogen — Fri, 15 Aug 2025 12:23:50 +0000

I don't mean this in any disrespect for Debian, but if there is an operating system where I think such deep knowledge like the Arch wiki has is needed, it is Debian. It has a large amount of different software which can be set up in so many ways just like Arch. I say this as someone who never got a Debian to install from scratch without extra help until premade vm's and clouds were available. [I think it is because I come from a Red Hat RPM background so certain choices I would make in the install seemed obvious to me and obviously bad to the person who would end up fixing my mistakes.]

The Debian documentation has been my second goto after the Arch wiki because it does go into deep things on software but I usually need the Arch wiki to find the proper terms to get a search engine to pull up the relevant Debian documentation. Hopefully the items which Arch has found successful can be useful or at least inspire things which would help someone like me figure out things.

Thank you Arch Linux documentation team

kreijack — Fri, 15 Aug 2025 08:26:34 +0000

> I want to say that if I need to find how a newer piece of software works, the Arch Linux wiki has always been the place for me to go to over the last .. 20 years? The documentation has always been top notch, kept up to date and filled with a technical knowledge rare in many places. I always wanted to know how this was possible when so many other documentation teams have struggled to keep up with the rapid changes in FLOSS ecosystems.

Google frequently points me to Arch Wiki pages when I search for technical answers. While not perfect, they’re often the most useful and practical resources available.

I believe this is largely due to the nature of the Arch user base: highly technical, deeply engaged, and committed to sharing knowledge. It reminds me of the spirit behind the old HOWTOs I used to read when I first started using Linux in the late’90s.

The documentation feels like it’s written by technicians, for technicians—which brings both strengths and limitations:

- It’s geared toward experienced users (which aligns with Arch’s philosophy), but this can make it inaccessible to beginners or those who prefer graphical interfaces over the command line.
- The quality is generally excellent, though not flawless. Skilled users are usually able to navigate minor inaccuracies—and often contribute improvements themselves.

That’s why, for technically inclined users, the Arch Wiki remains a trusted and invaluable reference.

How this can be ported in a Debian world, will be an interesting challenge, being Debian more generalist.

DRY

smurf — Fri, 15 Aug 2025 05:14:10 +0000

… so why does the world need yet another wiki, this time Debian's, with 90% the same information? (Five percent Arch-specific pages, five percent s/apt+dpkg/pacman/)

Cooperation is keen

kirb — Thu, 14 Aug 2025 16:43:35 +0000

A bunch of Markdown extensions do exist, but they just don’t seem to capture the extent of features you need to really feel like a wiki page. Markdown is narrow in the scope of syntax it wants to work with - if you want an image to be right-floated, you’re using HTML for that. That’s a downgrade from MediaWiki image syntax.

I run a large MW myself, and earlier this year helped someone to set up a new wiki. They wrote the first article in Markdown, thousands of words, then went to paste it onto their new wiki, where they quickly learned MediaWiki isn’t Markdown. They then went down the path of trying Markdown extensions, then tried converting to wikitext with pandoc, then finally decided to just convert by hand.

Unfortunately some extensions like VisualEditor are also very tied to the wikitext parser, and can’t be adapted to handle Markdown easily. The situation with syntax just isn’t great, but I guess Wikimedia is more concerned with maintaining the millions of articles that already exist in their wikis.

Wiki markup isn't too bad

t-8ch — Thu, 14 Aug 2025 12:23:20 +0000

> It's different from Markdown, but the description of wiki markup seems a bit overly negative.

It's very complex and internally inconsistent, having grown through ad-hoc changes to the parsing logic over the years.
When I researched wikitext parsers a few years ago, the only comprehensive and robust one was Parsoid.
It has been developed by the Wikimedia foundation since 2012 and ships with newer MediaWiki installations out of the box. It can convert between wikitext and annotated HTML which is then very easy to handle with any HTML library.
As an example for the complexity of wikitext, Parsoid needs multiple parsing phases. Around five if I recall correctly.

https://www.mediawiki.org/wiki/Parsoid

Wiki markup isn't too bad

AdamW — Thu, 14 Aug 2025 12:04:53 +0000

It's fine as markup. I have a love/hate relationship with using the really exotic bits. You can do some crazy stuff with it (like, ahem, https://fedoraproject.org/wiki/Wikitcms ). But it sure is fun getting the kinks out, and remembering how it all works when you come back to it a year later.

Significant whitespace! Oy.

Recording

Flozza — Thu, 14 Aug 2025 07:59:41 +0000

The talk was recorded and is available at https://meetings-archive.debian.net/pub/debian-meetings/2025/DebConf25/ with two links:
- https://meetings-archive.debian.net/pub/debian-meetings/2025/DebConf25/debconf25-664-archwiki-a-biased-swot-analysis.av1.webm
- https://meetings-archive.debian.net/pub/debian-meetings/2025/DebConf25/debconf25-664-archwiki-a-biased-swot-analysis.lq.webm

As an arch user it was really cool to peek behind the curtain of my favourite wiki!

Wiki markup isn't too bad

tux3 — Wed, 13 Aug 2025 23:43:08 +0000

I like wikitext, but on enwiki it's fairly common to see new users accidentally destroying the infobox, or adorning the page with a snazzy bright red error message after mangling its references.

Then there's the very elaborate template system. At this point the comparison to Markdown stops – it's easy to have lighter syntax if you simply don't have the feature, but you can't really avoid running into MediaWiki templates even as a casual user. Templates are used in almost all MediaWiki installs I've seen, they're really great to automate repetitive elements in a page, but on some Wikis they're sprinkled in practically every paragraph of text.
And a small mistake with these can have a very large blast radius. It's surprisingly easy to accidentally break tens of thousand of pages at once and/or to bring the servers to their knees with reasonable-looking changes.

Wikimedia spent a lot of effort on the visual editor, and I think casual users really benefit from it. It's significantly harder to edit the average enwiki article in source form than a Markdown page.
Take today's enwiki featured article for example, the page starts with a screenfull of templates for the infobox, it is sprinkled with inline <ref>{{cite ... }}</ref> calls that interrupt the flow of text with anywhere between a single line and half a screen of inline cite data, and even simple formatting uses '''''some unusual''''' syntax, like these 5 single quotes that control bold and italics.

Wiki markup isn't too bad

KJ7RRV — Wed, 13 Aug 2025 22:58:27 +0000

It's different from Markdown, but the description of wiki markup seems a bit overly negative. I've never tried writing a parser for it, but I would not describe it as "very weird and hard to understand ... for humans." Like any markup language, it must be learned, but it doesn't seem to be any harder than Markdown for comparable features.

The fact that it's less familiar than Markdown is certainly a valid consideration, as it's quite reasonable to prefer a system that will be more familiar to its users, but the quotes suggest that it's inherently hard to use, which doesn't seem to be the case.

Are there any specific examples of "changing a single token ... completely break[ing] a page"? I've never seen that happen on either of the MediaWiki sites I've been an active user of (one as an administrator), so I'm curious to see a case where it did happen.

Cooperation is keen

NightMonkey — Wed, 13 Aug 2025 13:49:19 +0000

It's nice to see cooperation develop between community distributions. While it's understandable that people love to 'pick their favorite team', there's really little reason to act as if there is some kind of benefit to a strict rivalry.

I do see that there's at least one somewhat actively developed Markdown extension for MediaWiki: https://www.mediawiki.org/wiki/Extension:WikiMarkdown. Sure, having to use an extension is going to increase the oops factor over something natively supporting Markdown, but perhaps that could help the project lessen the barriers created by MediaWiki syntax and parsing? Cheers!

Thank you Arch Linux documentation team

smoogen — Tue, 12 Aug 2025 18:50:20 +0000

I want to say that if I need to find how a newer piece of software works, the Arch Linux wiki has always been the place for me to go to over the last .. 20 years? The documentation has always been top notch, kept up to date and filled with a technical knowledge rare in many places. I always wanted to know how this was possible when so many other documentation teams have struggled to keep up with the rapid changes in FLOSS ecosystems.

This article gave me a lot of ideas on how this was possible and how they promoted a community to keep it going for so long. Thank you again everyone who has written documents for Arch.. they have been helpful to everyone.