Last instance of what?

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.

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.

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.

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?

In T193857#4183281, @Pbsouthwood wrote:

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.

In T193857#4183283, @RexxS wrote:

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.

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)

In T193857#4183293, @JJMC89 wrote:

In T193857#4183281, @Pbsouthwood wrote:

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.

In T193857#4183283, @RexxS wrote:

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

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.

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.

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.

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

Thanks for renaming the thread.

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

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

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?

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

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

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

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?

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

Fair enough.

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

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