Page MenuHomePhabricator

Support 'noreplace' keyword in {{SHORTDESC}}
Closed, ResolvedPublic

Description

For the page description (Wikidata description override) the last instance of the magic word {{SHORRTDESC}} is used. This is awkward as editors want to put the description on the top of the page (which is where you'd expect a summary to be), and they want to provide fallback values via various templates like infoboxes, and those templates come later, so the fallback takes precedence over the real value.

SHORTDESC should support {{SHORTDESC:...|noreplace}} like DISPLAYTITLE and other things do, so that templates can mark their values as fallback ones.

Details

Related Gerrit Patches:
mediawiki/extensions/Wikibase : masterHandle {{SHORTDESC:...|noreplace}}

Event Timeline

Restricted Application added a subscriber: Scoopfinder. · View Herald TranscriptMay 4 2018, 11:31 AM
Reedy added a comment.May 4 2018, 11:47 AM

Last instance of what?

JJMC89 renamed this task from Short description magic word returns last instance on page to Short description magic word stores last instance on page.May 4 2018, 3:24 PM
JJMC89 updated the task description. (Show Details)
JJMC89 added a subscriber: JJMC89.May 4 2018, 3:35 PM

I don't see a good reason to make {{SHORTDESC}} function differently than {{DISPLAYTITLE}} and {{DEFAULTSORT}}.

Perhaps the adding the noerror and noreplace functionality would be useful.

RexxS added a subscriber: RexxS.EditedMay 4 2018, 9:31 PM

If {{SHORTDESC}} appears more than once on an article's page, then the text in the final instance takes precedence.

Since the output on Wikipedia app (and previously on mobile view) appears at the top of the article, immediately after the title, it would seem natural to fix any errors by editing something also at the top of the article.

However, if there is another instance of the magic word lurking somewhere else on the page as well (perhaps buried inside a template), then an editor trying to fix a problem will be perplexed when their edit to the first instance has no effect.

Peter is asking whether it would be possible for the first (i.e. nearest the top) instance of the magic word could override any later instances, in order to avoid the issue I describe.

Pbsouthwood added a comment.EditedMay 4 2018, 9:31 PM

If there is more than one short description on the page the API call gets the last one. It would be far better if it got the first one, as there are a large number of pages where there is a default short description generated from a template or infobox, but for some of these a hand crafted short description would be better, which would be at the top of the page, so that is the one that should be used

I see that JJMC89 changed my task name. I would like to know why, as the new name does not make sense to me.

RexxS added a comment.EditedMay 4 2018, 9:35 PM

The renaming is because JJMC89 is only considering the functionality of storing a value of prop=description. Perhaps he wasn't aware that the Wikipedia app actually returns the value as rendered text close to the top of the article displayed.

OK, got it. So the problem is that the last one is stored, where it would be more useful if the first one was stored. It would seem that there is a routine that runs through the whole page, changing the value each time an instance is found, instead of stopping as soon as the first instance is found?

JJMC89 added a comment.May 4 2018, 9:42 PM

I see that JJMC89 changed my task name. I would like to know why, as the new name does not make sense to me.

It was renamed because the magic word stores the short description in the database; it does not return anything.

The renaming is because JJMC89 is only considering the functionality of storing a value of prop=description. Perhaps he wasn't aware that the Wikipedia app actually returns the value as rendered text close to the top of the article displayed.

An API/app returns what is in the database.

Pbsouthwood added a comment.EditedMay 4 2018, 10:01 PM

Fine, that is now clear to me. Thanks for clarifying
Is my question now sufficiently clear to get an answer?
(I dont know how {{DISPLAYTITLE}} and {{SORTKEY}} work, or what noerror and noreplace do)

RexxS added a comment.May 4 2018, 10:12 PM

I see that JJMC89 changed my task name. I would like to know why, as the new name does not make sense to me.

It was renamed because the magic word stores the short description in the database; it does not return anything.

The renaming is because JJMC89 is only considering the functionality of storing a value of prop=description. Perhaps he wasn't aware that the Wikipedia app actually returns the value as rendered text close to the top of the article displayed.

An API/app returns what is in the database.

If you want to be pedantic, the magic word doesn't actually do anything. There is code that reads the magic word's value and stores it in the database, just as there is code that reads the database and renders it. It's just as important to be able to see the complete flow of information from wikitext to database to rendered page as it is to see the compartmentalised view. That flow happens for the magic words, just as it does for any other piece of wikitext. As far as users are concerned, they won't worry about how the backend works.

It does not look like I am going to get a reply, so will have to open a task to have it fixed without knowing how practicable it is

Tgr added a subscriber: Tgr.May 16 2018, 11:22 AM

I can see why people want to put the description on the top of the wikitext. On the other hand, every magic word / parser function overrides the side effect of earlier invocations with that of later ones, and I don't think it's a good idea to change that - wikitext is complex enough without editors having to memorize which magic word works in which order of precedence.

noreplace seems like a reasonable compromise - use {{SHORTDESC:foo|noreplace}} in templates, and if there is an invocation without noreplace, that takes precedence over the noreplace ones.

RexxS added a comment.May 16 2018, 1:58 PM

Thank you @Tgr.

I think that is the solution that Peter and I have been looking for.

Can I put in a request to have the documentation at https://www.mediawiki.org/wiki/Help:Magic_words#Technical_metadata updated, please? (presumably the "Affects page content") section of the table? I'd do it myself if I was certain about the information for the 'Versions' column.

Tgr added a comment.May 16 2018, 2:27 PM

To be clear, this is not something that exists for SHORTDESC currently. Shouldn't be hard to add though, and other magic words already use the mechanism so it won't make things more complex than they already are.

Tgr renamed this task from Short description magic word stores last instance on page to Support 'noreplace' keyword in {{SHORTDESC}}.May 16 2018, 2:33 PM
Tgr updated the task description. (Show Details)
RexxS added a comment.EditedMay 16 2018, 2:33 PM

Yes, I've just found that out by testing.

Thanks for renaming the thread.

Tgr updated the task description. (Show Details)May 16 2018, 2:36 PM
Pbsouthwood added a comment.EditedMay 16 2018, 8:58 PM

Sounds like it might work. I guess we will need different templates for manually added short description and auto added short description.

Alsee added a subscriber: Alsee.May 20 2018, 12:00 AM

@Pbsouthwood, I also originally thought the simple and obvious answer was to use the first description. I definitely see some ugly and backwards aspects of using noreplace. However on deep thought, noreplace is probably the right answer. Consider an infobox that tries to add an automatic description, and an editor adds a short description template somewhere below that infobox. Yes yes, that's unthinkably gross and bizarre. The reason I did think of it is because I've already seen it. The description was either below the infobox, or it was below the infobox & below the lead. Gross... but it's a wiki.... we gotta expect stuff like that. If we use "first description" then we'd get the infobox-auto-description. If we use noreplace then the human description can be given priority. I think noreplace is probably what we want, even if it is a bit ugly.

There's an ugly corner case though. If an article has more than one {{short description|}} template, it's going to use the last one. It may be painful trying to figure out why the description is broken if you only notice the top description.

Pbsouthwood added a comment.EditedMay 26 2018, 7:36 AM

This is worse if people use a bare magic word (not encased in the short description template), so the short description does not show using css as it has allocated class. The upside is that these have mostly been added at the bottom of articles, the downside is that this may not always be the case, which will require special searches to find them. This is already a maintenence problem. Who knows how many more hassles it will give us?

Tgr claimed this task.Jun 4 2018, 10:18 AM
Tgr moved this task from To Do to Doing on the Product-Infrastructure-Team-Backlog (Kanban) board.

Change 437222 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/Wikibase@master] Handle {{SHORTDESC:...|noreplace}}

https://gerrit.wikimedia.org/r/437222

I am happy to see some action here. Is there an explanation somewhere of how this will work, so we can plan ahead? cheers

Tgr added a comment.Jun 4 2018, 5:21 PM

Exactly as described in T193857#4209931, if it goes through code review unchanged.

Pbsouthwood added a comment.EditedJun 4 2018, 5:36 PM

"if there is an invocation without noreplace, that takes precedence over the noreplace ones."
If I understand this correctly, we must add noreplace to any magic word that can be replaced, and leave it out for the one which must not be replaced, which is a bit counterintuitive based on the apparent meaning of the string.

Tgr added a comment.Jun 4 2018, 6:08 PM

A better way to look at it is that you should add noreplace to everything that should not replace other, presumably more specific instances. So, use noreplace in templates, don't use noreplace in articles.

Suddenly it is clear! Thanks for that explanation. Like a figure and ground problem, it depends on how you first look at it..

If we were to add noreplace to all template inclusions, will it have any adverse effect. or should this wait until you are done?

Tgr added a comment.Jun 5 2018, 10:27 AM

It's generally best to wait at least until things get merged, as they might change shape until then.

Change 437222 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Handle {{SHORTDESC:...|noreplace}}

https://gerrit.wikimedia.org/r/437222

Tgr closed this task as Resolved.Jun 18 2018, 4:22 PM

Has been in production for a couple days. Please reopen if it's not working as expected.

Vvjjkkii renamed this task from Support 'noreplace' keyword in {{SHORTDESC}} to emdaaaaaaa.Jul 1 2018, 1:11 AM
Vvjjkkii reopened this task as Open.
Vvjjkkii removed Tgr as the assignee of this task.
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed subscribers: gerritbot, Aklapper.
bearND renamed this task from emdaaaaaaa to Support 'noreplace' keyword in {{SHORTDESC}}.Jul 1 2018, 4:53 AM
bearND assigned this task to Tgr.
bearND raised the priority of this task from High to Needs Triage.
bearND updated the task description. (Show Details)
bearND added subscribers: Aklapper, GerritBot.
bearND removed a subscriber: GerritBot.
Tgr closed this task as Resolved.Jul 2 2018, 4:33 PM