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

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.

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

In T138652#2570765, @Platonides wrote:

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

It looks good to me.

@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!

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.

In T138652#2610539, @Aklapper wrote:

@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.

In T138652#2610539, @Aklapper wrote:

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!

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.

In T138652#2823462, @jeblad wrote:

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.

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

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.

In T138652#3008489, @Ladsgroup wrote:

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.

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.