Magic word on English WP to override display of Wikidata short description
Closed, ResolvedPublic

Description

Create a magic word to be used on English Wikipedia as an override for the display of the Wikidata short description in all of the places where the description is paired with English Wikipedia content, including on the apps, in search, and in Visual Editor's link module.

The model for this is the defaultsort magic word -- {{DEFAULTSORT:Big Sleep, The}} -- which is used in the wikitext on the article page to determine where the page title appears on category pages.

The new magic word should be {{SHORTDESC:1946 film by Howard Hawkes}}

When displaying the short description, the display should check to see if the magic word is filled in (not blank) in the English Wikipedia article. If there is a description on English Wikipedia, then that description should be used.

If the magic word isn't used on the page, or if the description is blank, then it should show the description from Wikidata.

"Blank" means:

  • not having any description in the field {{SHORTDESC:}}
  • just blank spaces {{SHORTDESC: }}
  • just punctuation {{SHORTDESC:.}}
  • just non-breaking space {{SHORTDESC: }}

In those cases, it should pull the description from Wikidata.

Once this override is live, Wikipedia editors will populate the magic word on pages where they want to override the description. If/when they write enough descriptions that it's roughly comparable to the number of existing Wikidata descriptions, we will change the system again, to only pull from the Wikipedia descriptions, and not use the descriptions on Wikidata as the default/fallback. At that point, on pages that don't have the magic word (or on pages where the description is left blank), there will be no description to display.

We're still talking about when that switch will happen -- the current plan is to switch when there are non-blank descriptions on 2 million article pages. That might happen quickly, or it might take a long time, depending on how the community chooses to use the magic word.

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Tgr added a comment.Feb 20 2018, 8:32 PM

The Wikidata label is a description of the Wikidata item.

"Label" in Wikidata terminology is the article title (e.g. Q663375 has the English label "hatmaking" and English description "manufacture and design of hats and headwear"; there's a separate item for hatmaker).

This raises an interesting point... what about label ? Where is that used ? What should it do in this mode ? Reflect the page title ? automatically strip the (disambig) postfix if there is a description ?????

I don't see any reason to touch label handling.

@Tgr I'm assuming no markup (like in wikidata). What about text length restrictions ? (I remember space in pageprops was limited??)

Markup should be removed, probably just by stripping HTML tags. page_props.pp_value is a blob (65K) but page terms are VARCHAR(255) so probably best limit it to that. (Not sure if there should be some kind of error message if it has to be truncated.)

Which reminds me, the override should be exposed in page information.

Instead of making the "original" description available in addition (which one is "original" anyway?) or indicating whether the description returned was overwritten, perhaps add a parameter for suppressing the override, forcing the use of the description from wikidata: disable-description-override or force-shared-description or something.

source=shared vs local maybe?

  • The parser function hook stores the argument of the parserfunction in the ParserOutput's page properties with a wikibase-description-override key.

So, this doesn't really have anything to do with wikibase, what we are adding here is a parser function to register an article description, that we want to be accessible via an API.
I agree with what @Alsee says that the description of the wikidata item and the description of the article can be and probably should be two distinct things.

  • In PageTerms::execute go through the returned terms, and replace the descriptions with overrides when available. Rely on the PageProps class to do the caching.
  • Maybe keep the Wikidata description and add it to the API result under a different name (wikibaseDescription? originalDescription?) so that old clients will automatically use the overrides while clients aware of what's going on can decide for themselves.

So, again overriding the current wikidata description here is a breaking change.
We should not do that.
If we want to add something new, such as an article description, lets add it under a new key called "article-description" instead of redefining something that already exists and has a clear definition.

  • Modify the API help messages (only if overrides are enabled) to make clear what's happening. Not considered an API B/C break since clients still get a description, just from a slightly different source.

Again, changing what is under the description key is a break in compatibility in my eyes, the description key should remain the wikidata description for the item linked to the article. If we want to add other stuff, then sure.

@Tgr Sounds like a decent plan. In an ideal world, the "short description" functionality would be factored out of wikidata, so it could be backed by *just* the magic word or *just* wikidata or both combined or something else. But that would of course break B/C. So I suppose modifying PageTerms is an OK solution. I agree that making TermSqlIndex aware of the override wouldn't be a good choice.

We could factor out the page terms stuff and not break B/C, just leaving the wikidata stuff where it is now and adding new keys for extra stuff. 'description' and 'article-description' could live side by side. One backed by wikidata and one backed by a magic word / parser function.

Instead of making the "original" description available in addition (which one is "original" anyway?) or indicating whether the description returned was overwritten, perhaps add a parameter for suppressing the override, forcing the use of the description from wikidata: disable-description-override or force-shared-description or something.

A param could be another route, something that would allow selecting of the source of the terms. options could be 'wikibase', or 'parser-overrides' or 'wikibase-fallback' etc with varying behaviours.

The Wikidata label is a description of the Wikidata item.

"Label" in Wikidata terminology is the article title (e.g. Q663375 has the English label "hatmaking" and English description "manufacture and design of hats and headwear"; there's a separate item for hatmaker).

This sentence is a bit misleading. "Label" in Wikidata terminology is nothing to do with 'article title'.
As written in the wikidata glossary "Label (also name) is the main name given to identify an entity".
So it is the term used to describe the concept of the item, but let's avoid the word article there to avoid any confusion.

@Tgr I'm assuming no markup (like in wikidata). What about text length restrictions ? (I remember space in pageprops was limited??)

Markup should be removed, probably just by stripping HTML tags. page_props.pp_value is a blob (65K) but page terms are VARCHAR(255) so probably best limit it to that. (Not sure if there should be some kind of error message if it has to be truncated.)

The length of a wikidata description is actually currently 250 rather than 255 (as is in the db).
This can be found in Wikibase.default.php in Wikibase/repo/config

	// Define constraints for multilingual terms (such as labels, descriptions and aliases).
	'multilang-limits' => [
		'length' => 250, // length constraint
	],
Tgr added a comment.Feb 20 2018, 11:40 PM

So, again overriding the current wikidata description here is a breaking change.
We should not do that.
If we want to add something new, such as an article description, lets add it under a new key called "article-description" instead of redefining something that already exists and has a clear definition.

Is it actually breaking anything, though? Clients want a description, they get one. (A better one, if we do this whole override thing on account of considering the local description superior.) In what possible scenario would that cause a problem?
The only one I can think of is when a client feeds this information back to Wikidata, e.g. by showing editable article descriptions, and I'm not aware of anything doing that (there was work on it for the official apps in T90765 and T145813 but not enabled yet).

Alsee added a comment.Feb 21 2018, 9:09 AM

@Tgr thanks for catching my sloppy hatmaking example. Hatmaking is an illustration for a completely different serious bug - interwiki links are badly broken. 75% of the interwiki links are missing from the English article , and 75% of languages with an article are missing interwiki links to English version.

However the seesaw/swing example still proves the fundamental point. Wikidata descriptions are descriptions of Wikidata items, for Wikidata purposes. Trying to put a Czech article-description in the Wikidata-description would be flat-out wrong. And using a Wikidata description as the Czech article description is going to be wrong.

Wikidata descriptions commonly have a passable resemblance to article descriptions, and some clients may sloppily or carelessly use them for that purpose, but Wikidata descriptions are not article descriptions. They never were.

Whoever started using Wikidata descriptions as article descriptions either made a deliberate decision that a convenient and sloppy-resemblance to "right" was better than nothing; or they were careless and didn't think through what they were doing. Either way, it's the 100th case where we could have saved a lot of headaches if the WMF had talked to the community before building the code.

Can someone post a link to the relevant API documentation page?

Can someone post a link to the relevant API documentation page?

You might mean this https://en.wikipedia.org/w/api.php?action=help&recursivesubmodules=1#query+pageterms

Is it actually breaking anything, though?

It is still a breaking change / change in behaviour.
Things could currently be using the behaviour that we advertise, changing the behaviour would be a break.
It is rather easy to avoid this breaking change, just don't change the definition of the "description" key in the api output.

The only one I can think of is when a client feeds this information back to Wikidata, e.g. by showing editable article descriptions, and I'm not aware of anything doing that (there was work on it for the official apps in T90765 and T145813 but not enabled yet).

That's a great example of how things could break.
If a client assumes the description returned by the page terms api is the wikidata description (which is currently a correct assumption and what is advertised) and goes on to make edits with it or even compare it with descriptions then things will start to break.

The Wikibase Web API accessible via https://www.wikidata.org/w/api.php is considered a stable interface. Changes to the parameters, operation, or returned data structure are subject to the above notification policy.

Breaking change: a change to an API or data format that violates guarantees given or widely assumed before. Breaking changes include removal of API functions, parameters, or data fields and changes to the interpretation or format of parameters or data fields.

TheDJ added a comment.Feb 21 2018, 9:43 AM

@Tgr Hmm. I just realised that pageterms module also reflects the wikidata content in the language as indicated by uselang... that's another potential api breaking point.

BTW. I wondered where "terms" originated from in wikidata speak. Best I could find was: "Term is a technical concept representing some text (a single string) in a specific language. Allocated in a set contained by a Fingerprint, Terms are used to capture Labels and Descriptions of Entities."

From an older version of the wikibase development glossary: https://www.mediawiki.org/wiki/User:Henning_(WMDE)/Wikibase/Glossary#Term

@Tgr Hmm. I just realised that pageterms module also reflects the wikidata content in the language as indicated by uselang... that's another potential api breaking point.

Yup, another reason to not change the "description" key.

In a world where we factor out page terms into its own thing and could move things around a nice final output could be something like:

[
    'wikibase' => [
        'label' => 'Foo1',
        'description' => 'Foo2',
    ],
    'article' => [
        'description' => 'from the parser function',
    ]
]

BTW. I wondered where "terms" originated from in wikidata speak. Best I could find was: "Term is a technical concept representing some text (a single string) in a specific language. Allocated in a set contained by a Fingerprint, Terms are used to capture Labels and Descriptions of Entities."

From an older version of the wikibase development glossary: https://www.mediawiki.org/wiki/User:Henning_(WMDE)/Wikibase/Glossary#Term

So yes, a term is basically a string in a specific language, although the term "term" can appear in different ways at different levels of the system.
Also with the above definition individual aliases are probably also terms / can be represented as a term.

Alsee added a comment.EditedFeb 21 2018, 4:44 PM

According to the API info, it looks like a pageterms API call is doing the correct thing, returning a Wikidata value. That probably shouldn't be broken. It appears the issue is the bits of code making the API calls. They are explicitly requesting Wikidata values.

It looks like the magic word description belongs under pageprops. However returning Wikidata descriptions though here would be just as wrong as returning the page description via the Wikidata API call.

It looks like the options are:

  1. Abuse the Wikidata API call to return a value from either source;
  2. Abuse the page properties API to return a value from either source;
  3. Have the calling code deal with both API calls;
  4. Have a new API call somewhere that isn't explicitly tied to a source; or
  5. Open a discussion on Meta and/or some of the other big wikis to consider the likely case that "silent" wikis have the same concerns and the same position as EnWiki. Then all calling code could be changed to use a pageprops API call.

1 and 2 are basically broken APIs. I hope we can veto broken APIs. 3 is gross, and should be scratched as well. Assuming I didn't miss anything, I think that pretty much leaves 4 or 5 as credible options. And in regard to #5, the fundamental reason for mess here is the plan to use one source for 50% of pageviews, and use a second source for the other 50%. (I checked the stats, EnWiki is in a close ballpark of 50%.)

Mike_Peel added a comment.EditedFeb 21 2018, 5:33 PM

However the seesaw/swing example still proves the fundamental point. Wikidata descriptions are descriptions of Wikidata items, for Wikidata purposes. Trying to put a Czech article-description in the Wikidata-description would be flat-out wrong. And using a Wikidata description as the Czech article description is going to be wrong.

Wikidata descriptions commonly have a passable resemblance to article descriptions, and some clients may sloppily or carelessly use them for that purpose, but Wikidata descriptions are not article descriptions. They never were.

This is partly true, but partly not. I'd describe them more as 'topic descriptions' - this is the description about what this topic is about, with links to the Wikipedia articles about it. Where the descriptions are well-written, then they do both what you are referring to as 'Wikidata descriptions' or 'article descriptions' (which are, sadly, yet another example of 'us vs them' thinking in this area...).

Although I still think the solution here is to improve the descriptions on Wikidata (and @daniel was spot-on here in his comments above), leaving that aside I have a question about the implementation. Will it be possible to access/display the descriptions in the text of other articles (e.g., list articles, or ideally even on Commons/other projects), or will this be write-only from the perspective of editing?

@Addshore I guess the problem here is that what technically is a breaking change is also the requirement of this ticket: make existing clients receive the overwritten local description, without any change to the client. We cannot fulfill that requirement without a breaking change.

If changing client behavior is an option, my preferred approach would be to introduce a new API module that offers a short description and (to the outside) says nothing about where it comes from, and then have one implementation that uses wikidata, one that uses the magic word, and one that combines both using some kind of fallback logic. But as far as I understand, we do not have this luxury.

Tgr added a comment.Feb 21 2018, 6:32 PM

The only one I can think of is when a client feeds this information back to Wikidata, e.g. by showing editable article descriptions, and I'm not aware of anything doing that (there was work on it for the official apps in T90765 and T145813 but not enabled yet).

(@bearND pointed out that the Android app does that, but not on English Wikipedia.)

It is still a breaking change / change in behaviour.
...

The Wikibase Web API accessible via https://www.wikidata.org/w/api.php is considered a stable interface. Changes to the parameters, operation, or returned data structure are subject to the above notification policy.
Breaking change: a change to an API or data format that violates guarantees given or widely assumed before. Breaking changes include removal of API functions, parameters, or data fields and changes to the interpretation or format of parameters or data fields.

The policy requires an announcement two weeks in advance for breaking changes. One could argue whether it applies or not (it talks about www.wikidata.org APIs, which would not change), but that seems doable anyway; that means we should decide now which way to go and make the announcement (or not). I think how to handle legacy clients is a product decision so I'll kick this upwards. @DannyH asked for the breaking change option (or at least that's how I understood T184000#3953713) but maybe he or @Lydia_Pintscher wants to reconsider in light of the arguments brought up since.

To recap, we can either:

  1. change the behavior of the API, to return the override when called the way clients call it currently (no extra parameters etc). That would automatically "upgrade" all clients out there to honor the override; if for some reason they rely on the description being specifically the same as the Wikidata description (e.g. because they allow editing and then write it back to Wikidata), they might break.
  2. make the override a new "mode" of the API (that could be an opt-in behavior of the pageterm API that can be enabled by some extra parameter; or an extra field in the API output; or a new/different API module). That would mean all clients which want to honor the override need to be updated to use the API in the new way (see T184000#3954787 for a list of current clients); and then wait until end-users update their clients (for apps and other locally hosted software that can have a considerable long tail).

If we go with the first version, someone needs to decide whether we need to apply the timeline from the stable interface policy (at least two but preferably four weeks between announcement and deployment). That's a call for the Wikidata developer team I think.

@Tgr Hmm. I just realised that pageterms module also reflects the wikidata content in the language as indicated by uselang... that's another potential api breaking point.

IMO we should only override pageterms that are in the content language. Or maybe those which are queried in the content language (it's a close enough approximation and makes things simpler).

IMO we should only override pageterms that are in the content language. Or maybe those which are queried in the content language (it's a close enough approximation and makes things simpler).

Yes, going by the requested language seems correct. And overriding descriptions requested in other languages would certainly be the wrong thing to do.

As @daniel said, the purpose of this ticket is to change the way that this works. I think we should do the first option in @Tgr's message above -- all clients should honor the override. We've made a commitment to people on English Wikipedia that this will be done.

@daniel & @Tgr -- sorry, I misspoke in my last comment. I talked to a couple more people and I understand it better now. :) We should do the second option and create a new mode of the API. I believe that means we won't have to notify Wikibase, so that should save some time.

Tgr added a comment.Feb 22 2018, 12:09 AM

Thanks @DannyH.

If changing client behavior is an option, my preferred approach would be to introduce a new API module that offers a short description and (to the outside) says nothing about where it comes from, and then have one implementation that uses wikidata, one that uses the magic word, and one that combines both using some kind of fallback logic. But as far as I understand, we do not have this luxury.

So something like prop=description I suppose?

How would the other two implementations get exposed? A site configuration option?

@daniel pointed out to me that the pageterms api module was originally introduced for the apps etc to use.
For future, APIs have the ability to be marked as "internal" if they are only designed for internal use, this would allow us to make whatever changes we want to suit the needs of wikimedia products.
If this was the case already for pageterms I really wouldn't mind what changes would be made (although it would probably make more sense that the module have a better name, appterms or similar)

@daniel & @Tgr -- sorry, I misspoke in my last comment. I talked to a couple more people and I understand it better now. :) We should do the second option and create a new mode of the API. I believe that means we won't have to notify Wikibase, so that should save some time.

Woo!

So something like prop=description I suppose?

How would the other two implementations get exposed? A site configuration option?

So, prop=description sounds like the approach that would totally separate this from wikibase, which in my eyes is a good idea.
The choice of implementation could just be provided as another parameter to the api module, this could even be multivalue to allow fallbacks, for example:

  • prop=description&descsource=wikibase - Description comes from wikibase directly.
  • prop=description&descsource=magicword - Description comes from magicword.
  • prop=description&descsource=magicword|wikibase - Description comes from the magic word with a fallback to wikibase.

prop=description sounds like a good way to do this! It's a little more work, but provides a more sensible interface to clients.

descsource=magicword|wikibase would work, but in general, clients should not know or care about this. At least, the default behavior in the absence of descsource should be a configuration option.

One big question is however where this code would live. It will have to know about wikibase, but only have a soft dependency on it. So it shouldn't be in core. It can live in wikibase, but I'd prefer it to be separate. Conceptually, this mechanism could be used to provide short descriptions without wikibase being installed. On the other hand, making this a separate extension may be too much overhead.

Bah, why is it always hard to do the Right Thing...

Tgr added a comment.Feb 23 2018, 10:55 PM

Conceptually, this mechanism could be used to provide short descriptions without wikibase being installed.

I'd rather put it in Wikibase for now, it can e reconsidered if someone actually shows interest in that. (We might want to rethink the whole thing once MCR lands, anyway.)

Change 414633 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/Wikibase@master] Add parser function and API module for page descriptions

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

Tgr added a comment.Feb 26 2018, 10:00 AM

Not sure about performance of the patch. PageProperties only does in-process caching (and even that only for lookups where the property exists); that sounds problematic but PagePropsEntityIdLookup (used by the pageterms API) does not do any caching either so maybe it's not so bad?

Elitre added a subscriber: Elitre.Mar 2 2018, 7:31 PM

Change 414633 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Add parser function and API module for page descriptions

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

Change 418843 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/mediawiki-config@master] Enable Wikidata description override on testwiki

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

Change 419083 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/mediawiki-config@master] Enable Wikidata description override on beta cluster

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

Change 419083 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable Wikidata description override on beta cluster

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

Mentioned in SAL (#wikimedia-operations) [2018-03-14T23:41:02Z] <tgr@tin> Synchronized wmf-config/InitialiseSettings.php: T184000 Enable Wikidata description override on beta cluster (duration: 01m 15s)

Mentioned in SAL (#wikimedia-operations) [2018-03-14T23:43:25Z] <tgr@tin> Synchronized wmf-config/InitialiseSettings-labs.php: T184000 Enable Wikidata description override on beta cluster (duration: 01m 15s)

Mentioned in SAL (#wikimedia-operations) [2018-03-14T23:45:26Z] <tgr@tin> Synchronized wmf-config/Wikibase.php: T184000 Enable Wikidata description override on beta cluster (duration: 01m 14s)

Change 420227 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/mediawiki-config@master] Enable Wikidata description override on enwiki

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

@Tgr Are you going to tackle T173144 as well so the remaining descriptions are still being tracked and changes show up in the watchlist?

Change 418843 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable Wikidata description override on testwiki

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

Tgr added a comment.Mar 20 2018, 12:49 AM

This is now in testwiki (also beta enwiki) and seems to be working well. Just from testing some large API queries, it seems on par with pageterms on performance (both are fairly fast even for thousands of pages). I think it could go to enwiki later this week, but I won't be around. Anyone willing to shepherd https://gerrit.wikimedia.org/r/420227 through SWAT? Otherwise, I can do it next Tuesday.

  • Display the override in the page information.

Oops, forgot to do that. Not a blocker, I'll add it later.

@Tgr Are you going to tackle T173144 as well so the remaining descriptions are still being tracked and changes show up in the watchlist?

I'll make an attempt at adding auto-tracking for pages which do not have a manual description (next week, maybe); nothing as generic as the hook proposed in T173144 though.

Note that given MobileFrontend doesn't always use the API it may need updating post this change.

Change 420227 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable Wikidata description override on enwiki

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

Mentioned in SAL (#wikimedia-operations) [2018-03-28T13:42:06Z] <catrope@tin> Synchronized wmf-config/InitialiseSettings.php: Enable Wikidata description override on enwik (T184000) (duration: 01m 18s)

Tgr added a comment.EditedMar 28 2018, 2:23 PM

Deployed on enwiki (ping @LGoto). Not used anywhere yet (I imagine {{short description}}, used on ~5000 pages, will be soon updated to use it); API help is at https://en.wikipedia.org/wiki/Special:ApiHelp/query+description
Note that the API is enabled on all wikis but overrides only work on enwiki (and testwiki / enwiki beta).

Follow-ups needed:

  • add short description to page info so that editors can check the current value without having to call the API
  • add auto-tracking of Wikidata description to pages where the override is not used
  • use the new API in MobileFrontend, MCS and mobile apps (and maybe VisualEditor?)
Tgr added a subscriber: LGoto.Mar 28 2018, 2:28 PM

I'm testing it out on enwiki:

https://en.wikipedia.org/wiki/Wagon_Train (Wikidata desc: Television program / enwiki desc: Western television series aired 1957-1965)

https://en.wikipedia.org/wiki/Guy_Madison (Wikidata: Actor / enwiki: American film and television actor)

I don't see the overrides showing up in the iOS app, but it's only been a couple minutes and it's probably cached. Is there an estimate for how long it'll take to see the override description?

@DannyH see follow ups - I think we need to update all clients now. @Tgr do you plan to do one for mobile web or do you need me to organise that?

Thanks, Jon. So this is the most important follow-up:

  • use the new API in MobileFrontend, MCS and mobile apps (and maybe VisualEditor?)

VisualEditor should be included in this; the short description should use the override everywhere that the description is used on English WP.

Tgr added a comment.Mar 28 2018, 4:50 PM

@Tgr do you plan to do one for mobile web or do you need me to organise that?

I'd leave that to Reading Web if that's OK with you.

Will it be possible to access/display the descriptions in the text of other articles (e.g., list articles, or ideally even on Commons/other projects), or will this be write-only from the perspective of editing?

Asking this again in light of the recent activity.

Tgr added a comment.Mar 28 2018, 6:32 PM

VisualEditor should be included in this; the short description should use the override everywhere that the description is used on English WP.

From a quick grep, the affected MediaWiki extensions seem to be CirrusSearch, ContentTranslation, MobileFrontend, RelatedArticles and VisualEditor.
(Plus the mobile apps, plus any services - MCR at least.)

Dbrant added a subscriber: Dbrant.Mar 29 2018, 1:27 AM
RexxS added a subscriber: RexxS.Mar 29 2018, 6:20 PM

I've now enabled the magic word on some 4600 articles on English Wikipedia:

https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:Short_description

That should give some scope for testing where you want the output of {{SHORTDESC:}} to go to.

Change 423244 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/Wikibase@master] Refactor business logic in description API into helper class

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

Change 423245 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/Wikibase@master] Add local and central description to page info

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

Deskana added a subscriber: Deskana.Apr 3 2018, 7:11 PM

Will it be possible to access/display the descriptions in the text of other articles (e.g., list articles, or ideally even on Commons/other projects), or will this be write-only from the perspective of editing?

Asking this again in light of the recent activity.

The local description can be retrieved from the API using prop=description, so anything that can query the API can use the description.

TheDJ added a comment.Apr 5 2018, 2:13 PM

Since people don't want to wait for proper development, nor are capable of writing their own scripts (why do we even bother with gadgets etc any longer? ) https://en.wikipedia.org/wiki/MediaWiki:Gadget-Page_descriptions.js

Pbsouthwood added a subscriber: Pbsouthwood.EditedTue, May 15, 6:43 AM

The short description stored is the one from the last instance of the magic word SHORRTDESC found on the page. This is problematic and it would be preferable to store the first instance found on the page. This is a bug. Please fix

Short descriptions are automatically produced by several templates, Some produce a generic short description suitable for a large number of pages, such as disambiguation pages. Others assemble a short description from component parameters of an infobox, which are sufficient in most cases, but seldom ideal.

In cases where a local customised short description is preferred, this is added to the top of the article for reasons discussed on Wikipedia, which come down to that the top of the article is whre people will look for it as it is an annotation to the title.

Currently the last instance of the magic word defines the stored short description. This should be changed so that the first instance is stored

Tgr added a comment.Tue, May 15, 10:24 AM

Every magic word with a side effect works in a last-one-wins manner; it would be pretty confusing to change that just for this one, IMO. Anyway, probably better to discuss in a new task than an already-closed one.

Pbsouthwood added a comment.EditedTue, May 15, 2:58 PM

a) What side effect?
b) Confusing to whom? As it stands it is confusing to the people who have to use it, and may require complicated work-arounds to get it to work usefully. These will be a huge time-sink for the people who are writing the encyclopaedia.
c) This is the task for creating this magic word, and the task is not finished until it works effectively for its purpose.
c) How do you suggest we make this thing work?

TheDJ added a comment.Wed, May 16, 8:29 AM

@Tgr That ticket would basically be T193857: Support 'noreplace' keyword in {{SHORTDESC}}

@Pbsouthwood
a) The side effect is taking something from a revision and using it for the page (different level of the datamodel).
b) This has been the behaviour of all magic words for 15 years. For instance this is also the behaviour of {{DISPLAYTITLE}}, {{DEFAULTSORT}} etc. consistency is important, even if it might be inconvenient for a particular use.
c) Wikitext parsing has many peculiarities that people need to know about in order to be able to use it correctly