Tgr added a comment.

Implementation plan:

  • Register a $wgWBClientSettings['descriptionOverride'] config variable.
  • When enabled, define a new parser function {{SHORTDESC:...}}.
  • The parser function hook stores the argument of the parserfunction in the ParserOutput's page properties with a wikibase-description-override key.
  • 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.
    • ...which doesn't actually seem to do it for negative results, so that needs to be fixed.
    • The alternative would be to modify / subclass TermSqlIndex to look at page properties, but that seems more wrong given that this is API-specific behavior that doesn't really have much to do with the actual page terms. (OTOH maybe there are non-API usages where there override needs to work? Such as Lua / templates?)
    • 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.
  • 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.
  • Somewhere at the end of parsing use a ParserOutputUsageAccumulator to register whether the description for the current page was overriden or not (the idea being that the description is always "in use" due to the mobile apps showing it, so it should always be exposed in recent changes etc same as if it were used in a template, unless it gets overridden). Not sure what's the right place for that, ContentAlterParserOutput maybe?

Does that sound reasonable?


TASK DETAIL
https://phabricator.wikimedia.org/T184000

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tgr
Cc: Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to