User:Dantman/Skinning system/Link lists rewrite

Current link structure

This is our current structure for tools links:

• personal_tools
  • userpage
  • mytalk
  • preferences
  • watchlist
  • mycontris [sic]
  • logout
  • anonuserpage
  • anontalk
  • anonlogin
  • login
  • createaccount
• content_navigation / actions
  • namespaces
    • subject
    • talk
    • special
  • views
    • view
    • edit
    • addsection
    • viewsource
    • history
  • actions
    • delete
    • move
    • protect
    • unprotect
    • undelete
    • watch
    • unwatch
  • variants
    • *
• toolbox
  • whatlinkshere
  • trackbacklink
  • feeds
  • contributions
  • log
  • blockip
  • emailuser
  • upload
  • specialpages
  • print
  • permalink
  • ispermalink

Proposed link structure

This is an alternative idea. Instead of grouped by ui element, we group things by context. Then instead of these themselves being ui elements, we have a tools definition that defines ui elements and notes what links go where then outputs those ui elements into the skin.

In addition to tools, we will likely incorporate 'related' links into this structure (see User:Dantman/Skinning system/Customization#Alternative page links). The only default such list would be related.languages.*.

• user (links relevant to who is logged in)
  • links
    • userpage
    • talk
  • tools
    • preferences
    • watchlist
    • contribs
  • actions
    • logout
    • login
    • createaccount
• page (links relevant to what page is being viewed)
  • namespaces
    • subject
    • talk
    • special
  • views
    • view
    • edit
    • addsection
    • viewsource
    • history
  • actions
    • delete
    • move
    • protect
    • unprotect
    • undelete
    • watch
    • unwatch
  • links
    • whatlinkshere
    • recentchangeslinked
    • print
    • permalink
    • ispermalink
    • feeds (~Do feeds need a separate feature?)
  • user
    • contributions
    • log
    • blockip
    • emailuser
• related (links on or off site to things with some relation to the current page)
  • variants (variants of the current page in different scripts, etc...)
    • *
  • languages (other language versions of the same page)
    • *
  • ... (extensions can define other types of relations, such as version relations for software documentation, sister wiki links, etc...)
    • *
• global (links relevant to the entire site)
  • specialpages
  • upload

Proposed syntax

The syntax likely goes something like:

• UI element names are marked inside []'s.
• Each item starting with * notes where a series of links should go.
• An item that points to a link inserts that link, and item that points to an array inserts that array. While the foo.* syntax matches everything with that pattern. ie: user.* where user.talk, etc... are links will insert all the links on the same level, while page.* where page.namespaces, etc... are arrays will insert a 'namespaces' arrayed key, etc...
• The system parses the whole thing and distributes links in a weighted system. eg: If you have user.* in one area, and user.userpage in another, then user.userpage will go to the spot that defined user.userpage, while every other link inside user will go to where user.* was defined.
• Rather than * a line can also start with - or +. Using + will add an item separately from the weighted * system (ie: Using '+ user.userpage' will add a userpage link while leaving user.userpage to go wherever it fits in the weighted system meaning that user.userpage exists in two separate lists as duplicates). Using - will eliminate a link from a list in such a way that unless you explicitly + it the link will not show up in any list (If you want to remove a link from a list and have it elsewhere you should use the weighted * system for that).
• An 'as' syntax is also supported. 'page.namespaces as foo' will add the page.namespaces array using the key 'foo' instead of 'namespaces'.
• Using x.** rather than x.* will do a recursive match that will flatten any hierarchy and create a flat list of links.
• A tool map should consider containing a * or ** somewhere in the definition that will take new features we add into account. The latter will of course flatten it to a single list of links instead of making it a hierarchy.

Vector Map:

[personal_links]
* user.*.*
[content_navigation]
* page.namespaces
* views:
** page.views.*
** page.actions.watch
** page.actions.unwatch
* page.actions
* related.variants
[related]
* related.*
[toolbox]
* page.*.*
* global.*
* **

MonoBook Map

[personal_links]
* user.*.*
[content_actions]
* page.namespaces.*
* page.views.*
- page.views.view
* page.actions.*
* related.variants.*
[related]
* related.*
[toolbox]
* page.*.*
* global.*
* **

Note how MonoBook uses - to erase the redundant view link.

Also note the [related] section. A "[language_urls]\n* related.languages.*" would be more recognizable, but [related] would ideally replace that and be used by the sidebar widget to create boxes like language_urls for other types of relations.