Page MenuHomePhabricator

Adding/editing descriptions should modify the local article, not Wikidata - iOS task
Closed, ResolvedPublic


NB: All of this applies only to English Wikipedia.

This is to document the logic and behavior proposed so far, and to discuss potential changes, caveats, and edge cases. The basic behavior is as follows:

  • If an article already contains the {{short description}} template, we will parse the template and replace the text in the template with the new text supplied by the user.
  • If the article does not contain the {{short description}} template, we will insert the template at the top of the article, with the text supplied by the user.
  • If the article uses a template that generates a short description automatically (e.g. {{Infobox settlement}} among others), we will still make the description editable, and will explicitly insert a new {{short description}} template at the top, which will override any implicit short description generated by another template.

Possible pitfalls / other questions:

  • Is it possible for the description itself to contain wikitext and/or transclude other templates? If so, how should we handle those cases? Is there an example of an article that does this?
  • Is the name {{short description}} guaranteed to remain the official name of this template? Are there other names/aliases of this template that do the same thing?

Event Timeline

Per the recent emails/conversations, we will proceed with local implementation. There are reference implementations if helpful...

@cmadeo @JMinor I noticed there's a "Learn more" link that discusses WikiData on the title description screen. This screen won't be accurate anymore on EN Wikipedia since it will only be saved in the article wikitext template. Should we change this screen?

Screen Shot 2021-03-04 at 10.05.00 AM.png (1×549 px, 222 KB)

Screen Shot 2021-03-04 at 10.05.05 AM.png (1×549 px, 288 KB)

@SNowick_WMF do you need any schema adjustments for these changes? We'll be moving all EN article description editing to go through our native title description editor screen, as opposed to sending them straight to the wikitext section editor. This means events that previously were produced for title description changes that made it to the Wikidata backend will now *also* be produced for description changes that only change the wikitext in the first section of the article (i.e. no Wikidata involved), for EN wikipedia only. This is what the events look like:

new description - save attempt

new description - saved

existing - ready

existing - start

existing - save attempt

existing - saved

existing - error

Just thought I'd check to confirm since the "wikidataDescriptionEdit" key could be confusing for an edit that doesn't involve Wikidata. Feel free to ping me if you have any questions. The edit schema that we are on is

For the info link, ideally we'd keep the existing info for all languages except English. In English I'd propose just opening this page in the browser:

Its the usual scary insider version of things, and the formatting will likely be terrible, but this is what the English community has chosen.

@Tsevener Josh and I discussed this, the best option is to keep everything in the schema the same, I will add a note on on the schema doc that for mobile app enwiki edits where wikidataDescriptionEdit is not NULL wikidatawiki is not changed, edit goes to Wikipedia. This will apply to Android as well so will note change in my analytics for both apps.

When we have a go live date for when this change is made I will add that to schema notes as well.

Prior distribution of edits on wikipedia vs wikidatawiki can be tracked on

Note we're seeing a server-side delay when updating short descriptions and requesting the new revisionID from the editing flow. Updating other intro text works fine, so it seems like a caching hiccup for short descriptions in particular. Made to track this.

Note: Because the server-side takes a while to return the updated description in the article content, we are locally updating the article content ourselves so the user will see their reflected update immediately.

There is a bug with the old description value pre-populating in the textfield if a user taps the edit description button again without pulling to refresh after a successful update. I will make a follow-up PR to fix this.

Tsevener added a subscriber: Tsevener.

This fix is in TestFlight build 6.8.0 (1798).

JMinor claimed this task.

Published to App Store in v6.8