Re: MediaWiki next steps
On Mon, Jul 21, 2025 at 11:48:52AM +0200, Taavi Väänänen wrote:
> On 7/20/25 10:20 PM, Andrew Sayers wrote:
> > Wikipedia has a huge collection of templates and seem to encourage other wikis
> > to import them. I maintain a personal wiki, and if memory serves, I had to
> > give up on the attempt because I made some simple mistake and would have needed
> > to reset the database to fix it. Consider importing MW templates now while
> > resetting the whole database (or just rolling it back to a known-good instance)
> > is an option. A quick look suggests [0] is a good place to start.
>
> The templates used on en.wikipedia have gotten very complex over the
> years. If there is a need for features they have that would be difficult
> to otherwise implement then I think that's an option, but importing some
> unspecified set of very complicated templates without clear use is
> something I'd rather not do.
That's fair, but as an exercise in wiki-building, how would you (all) translate
the "svn-buildpackage" page to MW? It's a complex page about a package, forces
us to think about CategoryProposedDeletion, and is a low-risk experiment
because it probably won't actually be migrated.
My first instinct would involve an infobox reused on every package page,
and a navbox at the bottom linking to other *-buildpackage pages. That would
push us towards including at least a large subset of WP templates.
>
> > The Cargo extension[1] lets you create content on one page that gets added
> > to a database, then queried on other pages. For example, consider a page like:
> >
> > /tmp became a tmps in trixie. {{{ChangeAtEOL|bookworm|delete this line}}}
> >
> > Cargo lets the template add itself to a database table, and lets you make a
> > separate page that queries the database for ChangeAtEOL items with an
> > appropriate release. I suspect this will be most useful for the sorts of
> > problems that ossify relatively early in the project, so it's worth thinking
> > about now.
>
> Cargo's security track record makes me really uncomfortable about
> deploying it. (Also, the particular example you mentioned seems like
> something where a maintenance category could be used just as well.)
Having only used it in a personal capacity, I can't comment on security.
But I don't think I was clear about the example. The current wiki's "ToDo"
page is just a list of (currently) 183 page names, which nobody will ever
browse through to find something they could work on. I for one would be more
likely to spend 5 minutes here and there if it was a table with a comment for
each entry - "delete this line", "check this works on i386", "rephrase" etc.
>
> > Finally, there was some talk about migration. How about moving the two wikis
> > to `moin.wiki.d.o` and `mw.wiki.d.o`, and making `wiki.d.o` act like a mirror of
> > MoinMoin by default, or MediaWiki for pages where MoinMoin 404's? That would
> > make it easy to do a gradual transition - pages that exist in the old wiki are
> > displayed as normal, then individual editors can spend some time migrating the
> > page, and delete the MoinMoin version when they're happy for people to default
> > to the new version.
>
> Just noting that Moin and MW use different URL structures (/$ARTICLE vs
> /wiki/$ARTICLE) at least in theory we could serve both from the same
> domain by proxying unhandled requests to the other esrver.
That's a better idea. It occurs to me that MoinMoin links to missing pages as
"[?]PageName" and MediaWiki uses red links, so mixing them in a single
namespace would need careful management to avoid wikis rendering pages as
broken links when they only exist in the other wiki. Not impossible, but
/wiki/$ARTICLE is easier and failures would be easier for users to understand.
Reply to: