Page MenuHomePhabricator

[Story] Add a new MediaWiki system message at the footer of content pages
Closed, DeclinedPublic

Tokens
"Party Time" token, awarded by Esc3300."Love" token, awarded by Liuxinyu970226."Love" token, awarded by dgstranz."Love" token, awarded by Santamarcanda."Love" token, awarded by Mr.Ajedrez."Love" token, awarded by Ivanhercaz."Love" token, awarded by Sjoerddebruin.
Assigned To
None
Authored By
abian, Jun 25 2016

Description

I request adding a new MediaWiki system message that would appear inside the #bodyContent element, between #mw-content-text and .printfooter (if it exists) or #catlinks (if .printfooter is not displayed) tags, as seen in the image.

We expect to use it on Spanish Wikipedia to automatically show content from Wikidata (e.g. the table for authority control), but I think this is a useful feature that should be available on all MediaWiki installations.

This "message" would be empty by default and, as usual, its content would be determined by a certain page in the MediaWiki namespace.

For the equivalent header in #mw-content-text, see T151682.

Event Timeline

abian created this task.Jun 25 2016, 9:59 AM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 25 2016, 9:59 AM

Could you link to a discussion on Spanish Wikipedia about this?
Has this been discussed with the Wikidata folks?

Aklapper renamed this task from New MediaWiki system message at the footer of content pages to Automatically show content from Wikidata by ading a new MediaWiki system message at the footer of content pages.Jun 25 2016, 12:03 PM

This task is not strictly related to Wikidata, nor to Spanish Wikipedia, nor to a specific Wikimedia project. It's about a MediaWiki system message that, I think, should be added to all MediaWiki installations.

Aklapper triaged this task as Low priority.Jun 26 2016, 4:08 PM
-jem- added a subscriber: -jem-.Aug 15 2016, 5:04 PM

How should the message be named? content-footer perhaps?

How should the message be named? content-footer perhaps?

It looks good to me.

abian renamed this task from Automatically show content from Wikidata by ading a new MediaWiki system message at the footer of content pages to Add a new MediaWiki system message at the footer of content pages.Sep 2 2016, 6:04 PM
abian raised the priority of this task from Low to Normal.Sep 5 2016, 9:29 PM

This feature is important for not having to use bots (which are very inefficient) to add and change templates that present some data from Wikidata (such as external IDs), or even for automatically managing all kinds of categories depending on the corresponding statements in Wikidata.

I think that this is not a very complex task, so I encourage volunteers with some experience with MediaWiki that they dare complete it. I don't even have such minimal experience and fear that I can break something, but I know that there are many Wikimedians able to make this possible.

@abian: The priority of this task was increased. As priority reflects reality and does not cause it, could you please elaborate why this task has become more urgent recently? If you increased priority because you plan to work on this task (thanks!) please claim the task by setting yourself as assignee. Thank you for your help!

Ivanhercaz added a comment.EditedSep 6 2016, 10:51 AM

Hi @Aklapper!

I am trying to set the authority control in each page of Wikipedia in Spanish. I was working this task with CanaryBot (my bot). I can continue with this task but I think that add the system of this task could be better and faster to apply. It could improve the pages, because it will show all the authority links in a page if exists in its Wikidata item, so it saves time to put the authority control with CanaryBot (or manually).

I would like to have knowledge to make this task but I haven't the necessary to make it fine. If someone could make I will be thankfully.

abian added a comment.Sep 6 2016, 11:05 AM

@abian: The priority of this task was increased. As priority reflects reality and does not cause it, could you please elaborate why this task has become more urgent recently?

I've only raised the priority because of the time that has passed since this task was opened. It was created in June, the Spanish Wikipedia stopped managing via bot some Wikidata-based templates such as the {{Authority control}} in July and, since then, the number of articles which aren't automatically fixed increases over time just as the number of new articles grows.

Indeed, @Ivanhercaz's bot was carrying out some tasks (particularly, adding the {{Authority control}} template). Now, I see that he offers to resume his task via bot, but I think that wouldn't be the best idea.

If you increased priority because you plan to work on this task (thanks!) please claim the task by setting yourself as assignee. Thank you for your help!

As I explained, despite this task doesn't seem hard, I cannot complete it for a lack of experience with MediaWiki "meat".

Thanks for explaining!

jeblad added a subscriber: jeblad.Nov 25 2016, 3:35 PM

There are several such messages that could/should be added. In addition to content-footer there should be a content-header, and it should even be headers and footers for each section. A message content-header-external-linksshould be a header on the external links section. It is also necessary to use named positions, like content-header-first-section and content-header-last-section.

The messages must use wikitext, as they will most likely contain a reference to a Lua module.

There are several such messages that could/should be added. In addition to content-footer there should be a content-header, and it should even be headers and footers for each section. A message content-header-external-linksshould be a header on the external links section. It is also necessary to use named positions, like content-header-first-section and content-header-last-section.

The messages must use wikitext, as they will most likely contain a reference to a Lua module.

I like your idea. And this could be really useful for external MediaWiki installations, not only the Wikimedia projects. I've created T151658 as a parent task.

Meanwhile, if you know any volunteer that can create content-footer so that we can centralize authority control and other great Wikidata-based features, please, feel free to encourage them to do it!

Is anyone working in this task? It could be help to centralize the authority control and make it useful in all pages.

Mr.Ajedrez added a subscriber: Mr.Ajedrez.

No assignee is set, hence I assume nobody is working on this task.

Lydia_Pintscher renamed this task from Add a new MediaWiki system message at the footer of content pages to [Story] Add a new MediaWiki system message at the footer of content pages.Jan 3 2017, 3:19 PM
Lydia_Pintscher added a project: Wikidata.

One quick note: It adds a great functionality but it will probably end up as a performance hiccup too. Pinging @aaron from Performance-Team, He might have some notes.

Okay, We talked about this in our weekly meeting and this is the result:
It adds several layers of complexity specially in matter of cache. If we want to do anything that starts to add backlinks in any possible way. This is going to blow the templatelinks table (and probably the whole database). Also if someone updates the given message key it's going to stay there and not propagate through cache because message keys are designed to be unchangeable.
In a more technical level. I think we should have an extension that uses one of the registered hooks. We have several options: 1- Hooks before parsing the page such as ParserBeforeInternalParse which makes us amend stuff to the wikitext before it gets parsed to HTML so practically we were just making all pages a little bit longer 2- After parsing and we would inject the HTML so we would need to sanatize (escape), fix caching and so many other problems. 3- Use PageBeforeDisplay hook which is as the same as 2.

daniel added a subscriber: daniel.Feb 8 2017, 9:26 AM

Also if someone updates the given message key it's going to stay there and not propagate through cache, because message keys are designed to be unchangeable.

...unless we track the message usage via templatelinks, with, as you said, will add one row for each (content) page in the wiki.

1- Hooks before parsing the page such as ParserBeforeInternalParse which makes us amend stuff to the wikitext before it gets parsed to HTML

This seems to be the best option to me, if we can overcome the tracking/parsing issue above.

One approach would be: if we know that ALL pages are using a specific template (or message), we don't need to track that in the database, we can just purge ALL pages when that template (or message) changes. However, puring ALL pages is a scary prospect... that's the main problem of this proposal in my mind.

2- After parsing and we would inject the HTML so we would need to sanatize (escape), fix caching and so many other problems.

Right, if we use the ParserAfterParse hook, we would probably run the parser against the message content manually; we probably can't use Message.parse(). That would need more investigation.

It should be mentioned that this option puts the resulting HTML into the ParserOutput object, making use of the parser cache.

3- Use PageBeforeDisplay hook which is as the same as 2.

It's not quite the sames as 2: PageBeforeDisplay is called every time the page is shown, even if it is not rendered. If use it, we cannot use the parser cache. But we would still have to re-parse the template/message very time, because we have to parse it in the context of the page being shown (so we can e.g. know which Wikidata item is connected). We cannot use the Message cache, since that would loose that context: the output would be the same for all pages.

daniel added a comment.Feb 9 2017, 3:46 PM

All the above being said: if there is a template that is used on pretty much all pages anyway, we may as well automate this.
My worry is that this is making it too easy to do horribly expensive things.

Lydia_Pintscher closed this task as Declined.Apr 17 2017, 4:19 PM

We've investigated and discussed this extensively and at this point it seems too risky to do this. Sorry :( We'd like to push it back to after we have Multi Content Revisions and see if the situation changes then.

Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptApr 17 2017, 4:19 PM