Re: Conversion edge cases
On Mon, Jul 28, 2025 at 09:47:32AM +0800, Maytham Alsudany wrote:
> On Sun, 2025-07-27 at 21:01 +0100, Andrew Sayers wrote:
[...]
> > == #format ==
> >
> > Some pages use "#FORMAT" / "#format" to indicate the parser the page should use.
> > "wiki" is widely used (and does nothing), the rest are only used on these pages:
> [...]
>
> At least for plain text, everything can be wrapped in a <nowiki> tag to
> prevent parsing, or a code block.
We might need <pre><nowiki> to replicate the look, but yeah.
Here's a detailed suggestion that covers some related topics:
The converter can just remove "#format wiki" and convert everything else to
e.g. {{MoinFormat|<format>|<text>}} - there don't seem to be any "}}"s on
non-wiki format pages, so it should be that simple. Then the conversion work
can continue without needing all the formats to be finalised yet.
Template:MoinFormat (or whatever we call it) should be a simple dispatcher:
{{#ifexist: Template:MoinFormat/{{{1}}}
| {{MoinFormat/{{{1}}}|{{{2}}}}}
| Please create [[Template:MoinFormat/{{{1}}}]]
}}
... so then we can discuss the best way to style Template:MoinFormat/plain
without interrupting the people working on Template:MoinFormat/irc or
having to think about the underlying template magic all the time.
Finally, the alpha version of Template:MoinFormat/plain should resemble:
= Proposed layout =
<pre><nowiki>{{{1|}}}</nowiki></pre>
= See also =
* [[https://wiki.debian.org/{{FULLPAGENAME}}]]
* [[Special:WhatLinksHere/Template:MoinFormat/plain]]
* [[Special:WhatLinksHere]]
... so we can quickly review pages and find issues.
> > == #language ==
> [...]
>
> I think the Translate extension handles language stuff automatically
> from the page path, so language doesn't need to be declared on each
> page.
While we're on the topic, are we definitely sticking with namespaced
translations that resemble the English version? Alternatives include
wikipedia-style {cn,de,fr}.wiki.debian.org or some kind of magic with
the Accept-Language header. To be clear - I'm not pushing those in
favour of the current model, just making sure it's been considered.
Assuming we stick with the current model, I suggest replacing the
current language-choice blocks with a {{Template:ChooseLanguage}} like:
{{#ifexist: cn/{{FULLPAGENAME}} | [[cn/{{FULLPAGENAME}}|cn]] }}
{{#ifexist: de/{{FULLPAGENAME}} | [[de/{{FULLPAGENAME}}|de]] }}
{{#ifexist: fr/{{FULLPAGENAME}} | [[fr/{{FULLPAGENAME}}|fr]] }}
...
... so translations get added and removed automatically without needing
page-specific management.
Also, I just stumbled across the MediaWiki Language Extension Bundle[0].
Any interest?
>
> > == #pragma ==
> >
[...]
> >
> > Some pages have "#pragma section-numbers 2" or even "... 3", but again
> > these don't seem to do anything.
>
> These are for determining what gets included in TOC and for numbering
> section headings. For example, see
> https://wiki.debian.org/MaythamAlsudany/SectionNumbers1 vs.
> https://wiki.debian.org/MaythamAlsudany/SectionNumbers2
Oh! I've seen pages that would have benefited from that (top-level heading
used as page title, makes the TOC look weird). I don't see an MW alternative
in a quick search, but converting these to e.g. {{MoinSectionNumbers|<arg>}}
would make it easier to sort out when the time comes. At minimum, I could use
Special:WhatLinksHere/Template:MoinSectionNumbers as a todo list.
(if it's not obvious yet - templates are my default answer for every question,
because they let us iterate on the solution in our own time)
> > == <<MailTo>> ==
> >
> > Widely used, seems to show the mangled text to logged-out users and a nice
> > e-mail address when logged in. See e.g. KevinCoyner.
>
> Could be implemented with a template that checks if
> {{currentloggeduser}} variable is populated and shows different content,
> though this only helps if spammers don't look at the raw page content.
> https://www.mediawiki.org/wiki/Extension:MyVariables#:~:text={{currentuserrealname}}
<<MailTo>> expects mangled text as input, then unmangles it in the macro.
So it's only a problem if spammers parse {{Template:MailTo}} ;)
[...]
> > == <<MonthCalendar>> ==
>
> I was already looking into this for FreedomBox/ProgressCalls.
> There's a list at https://www.mediawiki.org/wiki/Calendars
>
> - https://www.mediawiki.org/wiki/Extension:SimpleCalendar
> Either shows one month or one year. Not interactive, just a table of
> dates and links to subpages with those dates. To show current month, you
> need to use the {{CURRENTMONTH}} variable in the month parameter.
>
> - Cargo's calendar display
> - https://www.mediawiki.org/wiki/Extension:JsCalendar
> These two both rely on JS, but seem to be more useful since they're
> interactive and can list events. I haven't had a thorough look though.
I haven't tried SimpleCalendar, but seem to remember not getting along with
Cargo calendars. The "format=icalendar" parameter always generated links like
e.g. `...&order+by=%60start%60%2C%60end%60`, and the "%60"s caused the backend
to die. That was a while ago now, so it might have improved.
MediaWiki ships jQuery by default[1]. If those don't work out,
consider importing a jQuery calendar as a gadget
[...]
> > = Interwiki links =
Correction: the previous numbers were for e.g. "[[DebianBug:NNN]]".
Here are the numbers including un-bracketed "DebianBug:NNN"s:
AliothList 12
AliothProject 10
Bug 235
DebPkg 4396
Debian 115
DebianBTSUser 35
DebianBug 10036
DebianIRC 9
DebianList 171
DebianMachine 18
DebianMan 2977
DebianPackage 1233
DebianPkg 23547
DebianPkgShots 6
DebianPts 11701
DebianWebIRC 2
DebianWiki 42
LaunchpadBug 2
MeatBall 14
UbuntuBug 52
UbuntuWiki 47
UseMod 1
WikiPedia 1624
> As previously discussed, these can be implemented as MW Interwiki links
> as well as templates.
Doing DebianBug that way will require converting plain links
("[[https://bugs.debian.org/...]]";) and un-bracketed strings to templates.
The logic for that is at [2], and doesn't look *too* hard.
Slightly harder will be ensuring people use {{DebianBug|NNN}} in future.
I think the MediaWiki-y solution is for a bot to poll the RecentChanges feed[3]
and automatically edit the page. The bot would presumably use the same logic,
which is worth being aware of while writing the converter.
Also, I've found 82 instances of "https://bugs.launchpad.net/"; in the wiki,
and 16 instances of "http://launchpad.net/";. That strikes me as plenty
enough to make a Template:LaunchpadBug, but I guess we'd wait and see if
anyone complains before adding Launchpad itself as an external data source?
[0] https://www.mediawiki.org/wiki/MediaWiki_Language_Extension_Bundle
[1] https://www.mediawiki.org/wiki/JQuery
[2] https://salsa.debian.org/debian/wiki.debian.org/-/blob/master/usr/htdocs/bugstatus.js#L109
[3] https://www.mediawiki.org/wiki/Help:Recent_changes#Web_feed
Reply to: