Addshore added a comment.

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


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.



To: Tgr, Addshore
Cc: TheDJ, Fjalapeno, 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

Reply via email to