Page MenuHomePhabricator

Make Link Syntax Consistent Across All Link-Types, and Accommodate Unlimited New Link-Types
Open, LowestPublic

Description

MediaWiki Design Flaws

@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]
  • With external web links, single brackets are used, but with external wiki links, double brackets are used: [[w:Wikipedia:Village pump|]]

https://www.mediawiki.org/wiki/Manual:Interwiki#To_test
https://www.mediawiki.org/wiki/Help:Links

This is a Frankenstein mish-mash. The MW developers chose to give pipe two different meanings depending on type of link, they require two different syntaxes to display link-text, and different syntaxes for external weblinks vs external wiki-links. With each link-type, a different syntax was implemented.

To support new link-types, more and more brackets or other unique characters or character-order would be required-- put colons here instead, put pipes there instead, use this many or that many brackets.

That's confusing and inconsistent-- extremely, excruciatingly poor, very bad design, imo.

Goal
The objective of this request is to make all link types share a consistent syntax, which they currently do not.
And, to support unlimited new link-types, without having to add more and more brackets or other unique characters to differentiate them.

So, our only option is to introduce a new syntax. But, this new syntax mustn't conflict with existing double-square links. Eg., 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 unlimited new link-types, without breaking existing wikis?

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, where links support parameters (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.
      • Consistent bracket style for external web-links and external wiki-links.
      • Won't break existing links.
      • Existing wikis WOULD be able to use this new feature.
      • Less typing.
      • Can reuse existing code:
        • Entry point for single square links.
        • Link validation.
        • Interpreting/applying display text.
    • Dev notes:
      • Modifying existing external link code seems least effort, since this new syntax is based on external link syntax.
      • Case statements at the single square entry point accommodate new link-types in the future:

What kind of link is it?

  • internal: handle internal link
  • external: handle external link
  • transwiki: handle transwiki
  • video: handle video link
  • google-search: handle google-search
  • future type: handle future type
  • none of the above: return error
      • I propose link-type tags with # sign. Eg:

[#internallink: Namespace:Page 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 the # label for internal links.
        • Later, could add support for abbreviations, eg

[#transwiki: WikiID:Namespace:Page Display]

would be equivalent to

[#tw: WikiID:Namespace:Page Display]

Parameters
Some link-types may support parameters. It might also be desired to support parameter for internal links sometime in the future. This solution can be made to support parameters without breaking existing wikis, as such:
[Namespace:MyPage|Param1|Param2 Go to this page]
[#youtube: |start=2:30|end=4:00| Go to video]

Event Timeline

Johnywhy created this task.May 28 2018, 5:08 PM
Johnywhy updated the task description. (Show Details)May 28 2018, 5:11 PM

For the records, this task seems to be a spin-off from T194571: Request: Allow passing parameters to MediaWiki Pages.

Yes, this introduces the same syntax, but parameters need not be included.
This solution fixes the general problem of inconsistent link-syntax.

(I'm afraid that costs might outweigh the benefits nowadays. I'd very much agree with this task if we could travel back a lot of years in time, though.)

(I'm afraid that costs might outweigh the benefits nowadays. I'd very much agree with this task if we could travel back a lot of years in time, though.)

Why not now?

Your implication is that this syntax will require reprogramming existing functionality, or will break existing functionality. It will not.

This task will NOT require reprogramming existing functionality. This task does not break any existing syntax.

It's not an urgent bugfix, and can be developed slowly over time as resources are available.

Johnywhy updated the task description. (Show Details)May 28 2018, 5:22 PM
Johnywhy updated the task description. (Show Details)May 28 2018, 5:25 PM
Johnywhy updated the task description. (Show Details)May 28 2018, 5:30 PM
Aklapper removed a subscriber: Aklapper.May 28 2018, 6:09 PM

Your implication is that this syntax will require reprogramming existing functionality, or will break existing functionality. It will not.

No, I neither implied nor wrote that. I'm saying that any additional features (like adding another implementation) can create maintenance costs for years. Anyway.

matmarex added a subscriber: Aklapper.
Aklapper removed a subscriber: Aklapper.May 28 2018, 6:16 PM
Johnywhy added a subscriber: Aklapper.EditedMay 28 2018, 6:32 PM

I'm saying that any additional features (like adding another implementation) can create maintenance costs for years. Anyway.

For sure. Like any new feature.
And because it can be developed over time, there's plenty of time for devs to take it up and move it forward.

It sounds like you are deciding for the community in advance.

If you want to eliminate maintenance, why not just eliminate MediaWiki?
Good software design reduces future effort.

The choice to allow poor design to persist is not healthy for software development, or for MediaWiki, or for it's users. Poor design creates MORE work. Blocking important improvements results in more pain and effort in the future.

It's incredibly short-sighted of you.

Aklapper removed a subscriber: Aklapper.May 28 2018, 6:35 PM
Vvjjkkii renamed this task from Make Link Syntax Consistent Across All Link-Types, and Accommodate Unlimited New Link-Types to s4baaaaaaa.Jul 1 2018, 1:07 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
CommunityTechBot renamed this task from s4baaaaaaa to Make Link Syntax Consistent Across All Link-Types, and Accommodate Unlimited New Link-Types.Jul 2 2018, 3:31 PM
CommunityTechBot raised the priority of this task from High to Needs Triage.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added a subscriber: Aklapper.
Aklapper triaged this task as Lowest priority.Aug 4 2018, 3:32 PM