Extension:ParseAfter

Legacy: This article describes a concept that has been superseded in the course of ongoing development on the Organic Design wiki. Please do not develop this any further or base work on this concept, this is only useful for a historic record of work done. You may find a link to the currently used concept or function in this article, if not you can contact the author to find out what has taken the place of this legacy item.

This code is in our Git repository here. Note: If there is no information in this page about this code and it's a MediaWiki extension, there may be something at mediawiki.org.

This extension was created in response to some problems that have required inner expressions within brace structures to be parsed after the outer expressions. For example, consider the following wikitext:

{{#dpl: category = Records | format = ,*[[:Category:{{plural|%TITLE%}}]], \n, }}

The purpose of this is to create a list of all the record types in plural form so that a "Person" record gives a link to "Category:People". The problem is though that at the time Template:Plural is expanded, the parameter it receives (%TITLE%) is not expanded by DPL and therefore results in all pluralisation being the default operation of having an "s" appended.

The solution is to allow some parts of the expression to be parsed after the first parse is done, for example:

{{#dpl: category = Records | format = ,*{{#after:[[:Category:{{plural|%TITLE%}}]]}}, \n, }}

After the first parse, the DPL query will expand out to a number of {{#after}} expressions with resolved %TITLE% parts, these then need to be parsed separately. This is slightly tricky because each #after section needs to protect its contents from the wiki parse, yet keep the DPL variables intact so that they can be expanded properly.

Using tags fails

The first idea was to create a tag function which allowed its content to contain brace expressions which it would expand, but this fails because the content of the tag is protected from the parser so that the DPL variables are hidden and not expanded.

Another similar example

The following is a similar example, but instead of DPL with %NAME% variables it is this time a $1 that needs to be expanded by the #regex parser function before pluralisation occurs.

{{#regex:{{{1}}}|/(\w+)/|{{plural|$1}}}}