| Tgr added a comment. |
In T184000#3987715, @Tgr wrote:
(@bearND pointed out that the Android app does that, but not on English Wikipedia.)
In T184000#3988377, @Addshore wrote: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:
- 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.
- 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.
In T184000#3988387, @TheDJ wrote:@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).
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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
