Fri, Aug 23
@bearND ok - I was wrong, I'm not seeing the description source there either.
@bearND description source is already in /page/summary so it could be removed here. If it's easier to move language links or protections to summary I think that'd be fine as well, but I think at last check the thought was to try to remove as much from /page/summary as possible due to performance concerns
@Mholloway the specific problem is that File:Olympic_rings.svg isn't what the mobile-html for that page loads. It loads the thumbnails from the redirected image (for example, https://upload.wikimedia.org/wikipedia/commons/thumb/5/5c/Olympic_rings_without_rims.svg/320px-Olympic_rings_without_rims.svg.png). This ticket and T230067 are intertwined. The clients need the exact srcset that mobile-html will attempt to load for that page without having to know the implementation details of mobile-html.
Tue, Aug 13
Sat, Aug 10
Fri, Aug 9
@JMinor it's a bit of a re-work. I think it's fine to merge the simpler solution to solve this ticket then follow up later with a more nuanced implementation like option b
Would a simple edit history list without displaying pageviews also result in duplicate entries?
Yes, the edit history list we can get from the API is a list of recent edits, so if the user edited the same article multiple times, there would be multiple entries for each edit. This is independent of whether or not page views are include
@schoenbaechler if you're ok with showing a paginated list of recent edits and the pageviews for those articles since those edits, pre-existing APIs can be used to collect that client-side. The caveat is that if a user edits the same article multiple times, you would have duplicate entries in the list. You also would not know the date the user started editing the article. Duplicate entires could be coalesced app-side but it appears there'd be no easy way to get the earliest edit date.
Thu, Aug 8
@MSantos sounds good
@MSantos It looks like the srcset differs. Would you make media-list be based off of mobile-html instead of parsoid html?
@MSantos yes that would be fine as well as long as the srcset is identical to what is output by mobile-html - I'm not sure if the srcset on the parsoid output is identical to what's on the mobile-html output
Do you need /transform/html/to/mobile-html exposed publicly, or actually you need transform/wikitext/to/mobile-html - as I understand the idea is for the app to submit edited wikitext, not HTML? Thus, we can combine transform/wikitext/to/html and transform/html/to/mobile-html inside RESTBase and not have the app do an additional round-trip.
Wed, Aug 7
Tue, Aug 6
I am able to repro with this article: https://ja.wikipedia.org/wiki/小田急電鉄
Mon, Aug 5
@Reedy in the future, should the apps rely on the fields in the response rather than the id? Could there be a separate field type (instead of string) for 2FA to allow for only numerical input?
Fri, Aug 2
Other articles don't seem to repro the issue, only "OK Computer" on enwiki
@Reedy it looks like the iOS and Android apps are both looking for a request with id equal to TOTPAuthenticationRequest in the response and that string changed to MediaWiki\Extension\OATHAuth\Auth\TOTPAuthenticationRequest - is this expected?
@Reedy yes, we can add automated testing for this. Is there a way to create accounts with 2FA enabled on the beta cluster?
The issue might be a lack of 'Accept-Language' in the PCS response Vary header. srwiki works fine and when testing locally PCS includes Accept-Language in the Vary header whereas zhwiki does not.
Thu, Aug 1
Wed, Jul 31
Will be fixed by T219995
This works already