Parameterized wiki pages

This thread concerns parameterized wiki pages.

Use-case
The use-case for parameterized internal wiki links is the ability to display a wiki-page with dynamic behaviors or values based on the parameters passed in from the linking page. For example, (assuming hypothetically that broken pipe ¦ could be used to delimit parameters in an internal link), the internal link:

[[Fruit¦apples]]

would display a wiki page called Fruit, and pass to it the parameter "Apples". If the page Fruit contained:

I like {{{1}}}.

This would render as:

I like apples.

I believe many wikis would find this a very useful, powerful feature.

Transclusion parameters

It's appropriate to say development of this feature is already half done. Page-parameters completes the feature set begun by transclusion-parameters. It's an inconsistency of MediaWiki that parameterized transclusion is available, but not parameterized links.

The feature requested in this post, wiki-page parameters, is basically the same behavior as Transclusion parameters: passing parameters to another wikipage. But, unlike transclusion, this request is to pass variable values to a displayed wikipage (directly rendered), rather than a transcluded wikipage.

Currently, Templates support parameters for transclusion. (actually, all wiki-pages support transclusion and transclusion-parameters, but Template is the namespace intended for transclusion).

"To enrich the mechanism of transclusion, MediaWiki allows parameters to be passed to a template when it is transcluded. Parameters allow the template to produce different contents or have different behaviors."

Parameters can be sent to a transcluded page via curly-braces transclusion, with pipe as delimiter. Example of a call to a parameterized MediaWiki template:

{{Thankyou|all your efforts|Me}}

For more info, you may review the following resources:
https://www.mediawiki.org/wiki/Help:Templates#Parameters
https://www.google.com/search?q=mediawiki+transclusion+parameters&tbs=li:1

Parameterized web pages

The feature requested in this post, wiki-page parameters, is similar to Parameterized web pages: The ability to pass variable values to a page on the internet:

URL parameter: A way to pass information about a click through its URL. You can insert URL parameters into your URLs so that your URLs track information about a click. URL parameters are made of a key and a value separated by an equals sign (=)."
https://www.google.com/search?q=%22URL+parameters%22&tbs=li:1

The pervasiveness of parameterized webpages is another good argument in support of parameterized links. The usefulness of parameterized-webpages also applies to wiki pages.

Example of a url parameter is everything after the question mark in this url:
https://www.mediawiki.org/w/index.php?title=Topic:Ucmsdl9osvcbes0l

Except in this request, we're passing parameters to internal wiki-pages specifically, rather than to just any webpage. For that reason, we want use internal MediaWiki syntax.

Redirects

A redirect example isn't critical to understanding this thread. It's just an example of where one might apply a parameterized internal link.

Like ANY page with a redirect, you'll be redirected to the page specified in the redirect. That's the point of a redirect-- it redirects the visitor to a different page. Except (if internal link parameters were supported), the parameters would get passed to the linked page. That means, when the page is redirected, the target page would receive whatever parameters are sent to it from the originating page. In this example, the string "Apples" would be a parameter passed to the page Fruit (IF link-parameters were supported with broken pipe ¦, which they aren't currently):

#REDIRECT [[Fruit¦Apples]]

MediaWiki Design Flaws

Ideally, this would be implemented with square-bracket internal-link style, because that's MW's internal link syntax. Ideally, imo, new features should conform to existing implementation, instead of adding yet another different syntax.

@Aklapper wrote: [[Fruit|Apples]] is existing syntax to make the string "Apples" link to the page "Fruit".

You're absolutely right, and therein is a glaring inconsistency in MW:

• With transclusion, the pipe means: parameter: {{Thankyou|all your effort}}
• With internal links, the pipe means: link-text. [[Fruit|Apples]]
• With external links, a space means: link-text. [https://mediawiki.org MediaWiki]

https://www.mediawiki.org/wiki/Help:Links

The MW developers chose to give pipe two different meanings depending on type of link, and they require two different syntaxes to display link-text. That's confusing and inconsistent-- extremely, excruciatingly poor design, imo.

It also means we can't identify parameters with pipes, as we do in transclusion, because, with double-square internal links, the pipe indicates display text. Thus, due to a disorganized link-syntax, pipe cannot be used in a consistent way.

Solutions

So, our next option is to introduce a new syntax.

This new syntax mustn't conflict with existing double-square links. The double-square with pipe is already used in all existing MW installs, and we don't want to break existing wikis by changing existing syntax.

What syntax would support internal link parameters without breaking existing wikis? There are a few possible solutions:

Best solution:

• [Namespace:Page|Param1|Param2 Display]
  • Syntax:
    • Don't touch double square bracket. Double square internal links will continue to work as now.
    • Single square external links will continue to work as now.
    • Use single squares (same as external-link syntax).
    • Use pipes for all params (same as transclusion).
    • And use whitespace for display text (same as external-link syntax).
  • Benefits:
    • Consistent parameter syntax for transclusion and linking,
    • Consistent bracket style and display-syntax for internal and external links.
    • Won't break existing wiki links.
    • Existing wikis WOULD be able to use this new feature.
    • Less typing.
    • Can reuse existing code:
      • Entry point for single square links.
      • Validate that the page name is valid.
      • Interpret display text.
      • Apply parameters.
  • Dev notes:
    • Modify existing external link code seems least effort, since this new syntax is based on external link syntax.
    • A design that can accommodate new link-types in the future would use case statements at the single square entry point:

What kind of link is it?

• internal: handle internal link
• external: handle external link
• transwiki: handle transwiki
• future type: handle future type
• none of the above: return error

• • • I propose link-type tags with # sign. Eg:

[#internallink: Namespace:Page|Param1|Param2 Display]

• • • • Such link-type tags with # sign would enable an unlimited number of link types.
      • Eliminates need for string-evaluation of the link, like "Is there www?"
      • Can make internal link the default, so can leave out for internal links.
      • Later, could add support for abbreviations.

Acceptable solution:

• Use current double-square internal-link syntax, and place parameters after the display-text. All subsequent pipes assumed to be parameters: [[PageName|Display|Param1|Param2]] -This is a decent short-term option. It retains solution-brackets for internal links, would not break existing wikis, and would still allow pipe as parameter delimiter. Will allow existing wikis to use the new feature. Less dev effort than 'Best' solution above, because retains double-squares (no new internal/external test needed). However, retains MW's inconsistent syntax, and doesn't support future link types.

Unacceptable solutions:

• [[Namespace:Pagename|Param1 Display]] Break existing Wikis by redefining double-square internal link syntax. Provide config option to enable EITHER/OR. Use double-square internal-link syntax. All pipes, including first one, are parameters (same as transclusion). Use whitespace at the end to indicate display text (same as external links). - But if implemented now, it would break links on all existing wikis, which is not acceptable. To fix that, we could offer a config option that toggles whether to interpret pipe as parameter-delimiter (the new feature), or as display-text (the current standard). New wikis could then take advantage of the feature, without breaking existing wikis. More dev effort than 'Preferred' solution above, cuz requires a new config option in user Prefs or in LocalSettings.php. Existing wikis would NOT be able to use the new feature.
• Use pipe-escape as parameter delimiter: {{!}} -Too much typing. Misuse of escape.
• Require underscore for name, so space can mean show, thus freeing up pipe for params: [[pg_name show-string|param1|param2]] -Not consistent with existing link-rules, which currently allow white-space.
• Use questionmark+ampersand (like url parameters): [[MyPage?MyParam=MyValue|Display]] -Not consistent, doesn't look like wikitext, seems like a crappy workaround.
• Use broken pipe ¦ . [[Namespace:Page|Display¦Param1¦Param2]] -Not on keyboard.
• Use double pipes: [[Namespace:Page|Display||Param1||Param2]] -Too much typing.
• Use triple squares for parameterized internal links, and whitespace for display text (consistent with external links): [[[Namespace:Page|Param1|Param2 Display]]] -too much typing, and Introduces a new syntax, instead of building on existing syntax.
• Place parameters before the page-name: [[Param1|Param2|Namespace:Page|Display]] -Counter-intuitive.
  • Might be relevant: https://www.mediawiki.org/w/index.php?title=Topic:Sfpe9v36gmk0ulww&topic_showPostId=sfpe9vhtedf5m6vo#flow-post-sfpe9vhtedf5m6vo

*Alternatives*

Extension:UrlGetParameters provides a workaround, but there are problems with that:

• only works with "a" tag HTML links, not wikitext square bracket links. So it's inconsistent with MW standard linking.
• parameters can't be queried with standard MW syntax, eg {{{1}}} etc. Must use #urlget.
• doesn't work at all with #REDIRECT.