Question : History of old articles

If I understand correctly, this feature will potentially allow to view an article with the versions of the templates that existed at the time the wikitext was edited. Two questions arise then :

• will that also work for deleted templates ?
• will we be able to restore the revisions of version prior to multiple content revision deployment, say a 2005 revison of some article ?

@TomT0m No, Multi-Content-Revisions does not help with consistent display of old template revisions. Well, it does in cases where the use of templates is replaced by the use of slots - if e.g. template documentation was stored in a slot instead of a subpage, you would always see the correct version of the documentation for old versions of the template. But that would be because it would no longer use the template mechanism.

In T107595#2791111, @daniel wrote:

@TomT0m No, Multi-Content-Revisions does not help with consistent display of old template revisions. Well, it does in cases where the use of templates is replaced by the use of slots - if e.g. template documentation was stored in a slot instead of a subpage, you would always see the correct version of the documentation for old versions of the template. But that would be because it would no longer use the template mechanism.

Ok, I got confused. Does that mean that the documentation will not have its wikipage address anymore ?

Would this then be possible to have a special type of "reference" slot which would hold a pointer to another page revision ? I guess the parser could be modified to maintain those reference slots when page are saved.

For example the parser computes a new version of the page when its content is modified, and when he expands a template a hook triggers the slot mangager to store the revision number of the template with those "reference" slots - I guess this this kind of hooks or something similar exists since we got a list of the used templates on previsualisation of a page.

In T107595#2791067, @TomT0m wrote:

If I understand correctly, this feature will potentially allow to view an article with the versions of the templates that existed at the time the wikitext was edited.

You might be thinking of Memento (which is not related to this in any way).

In T107595#2791142, @TomT0m wrote:

Ok, I got confused. Does that mean that the documentation will not have its wikipage address anymore ?

Yes, the documentation would be part of the template page proper, and would not have a separate title.

Would this then be possible to have a special type of "reference" slot which would hold a pointer to another page revision ? I guess the parser could be modified to maintain those reference slots when page are saved.

That would theoretically possible, but there are currently no plans to do this. I'm also not sure this would be the best way to tie a page revision to template revisions. So far, slots are intended to be editable, not derived. I have been thinking about derived slots, but the use cases for that idea all seem a bit contrieved, and would perhaps be better served by a more specialized solution, like a dedicated database table.

For example the parser computes a new version of the page when its content is modified, and when he expands a template a hook triggers the slot mangager to store the revision number of the template with those "reference" slots - I guess this this kind of hooks or something similar exists since we got a list of the used templates on previsualisation of a page.

This could be done with a DB table that associated a revision ID of the "transcluder" with a revision ID of the "transcluded" in each row. Simple enough to do, and would be stable against moving the template being renamed, etc. It's going to be a big table, though. And quite a change in how things work. As Tgr pointed out, there is the Memento extension that does this with some limitation. It's a feature that has been discussed time and time again, but never gained enough traction to be properly implemented.

Just for clarity, as I've worked on this task but not actually commented, we in Editing see MCR as very important to our long-term plans. The use cases laid out at Multi-Content Revisions#Use Cases cover a lot, but I'll just pull out the four that we see as most vital:

• The structured media info work, as almost goes without saying;
• Rejigging templates to have dedicated template, styling, data, and documentation slots, with UI to match;
• Rejigging files to have a fused history for the blob and the description, removing UI confusion; and
• Moving to a structured-data approach for categories.

Lots of others are also important, but those are the most useful.

Notes for the session right now: https://etherpad.wikimedia.org/p/devsummit17-multi-content-revisions

If we use MCR for annotation storage, it would be useful to have a canonical URL for the contents of a specific slot. That might be an API URL, like https://en.wikipedia.org/api/rest_v1/page/html/Main_Page/749836961/<slot number> or else a user-visible URL like https://en.wikipedia.org/wiki/Main_Page/<slot name> or https://en.wikipedia.org/wiki/<Slot>:Main_Page or even a quasi-API URL like https://en.wikipedia.org/wiki/Special:redirect/slot/<revision>/<slotname>. Thoughts?

(cc @MarkTraceur)

As assigned to T135845, I would use dedicated pages to exchange structured datas between several central or local Lua modules.
These pages could content:

• the first and actual versions of several modules
• the story of mediawiki versions in each wiki to help coders to better describe new bugs
• the options to manage these exchanges: central or local, priorities of some modules as managers, used structures...
• the places where find i18n translations...

I assume this can be closed now?

There are other data than those provided for RFCs related to the content of a page.
They will be available thanks to T168726: Create a syntax documentation page for Special:PageData.
A PageData could contain:

• The first and current versions of several Lua modules,
• The history of mediawiki versions in each wiki to help coders to better describe new bugs,
• The options for managing these exchanges: central or local, priorities of certain modules as main, structures used ...
• Places to find translations i18n ...

These datas are related to the content of the page but not to the revisions.
These 2 tasks could benefit from similar and compatible functions and codings.