@Jgiannelos after some more digging, I've seen some references of topic being the app bundle identifier (like org.wikimedia.wikipedia), which would make sense. Ultimately I just needed to confirm that we could receive only one push that represents multiple types of notifications, for example, a talk page notification and an edit reverted notification, and that we need to handle that combined description in the push UI. Those would not be separated on the backend and sent as two different generic pushes simply because they are different notification types. But they could also be sent separately if the randomized timing, sizing or workers sussed it out that way.

@Jgiannelos thanks for the followup!

@Jgiannelos @Mholloway awesome, thanks for the info! I'll mention the checkmark disabling to the rest of the team and will let you know if we decide to move forward with that.

More reports from OTRS:

@vadim-kovalenko thanks! I tested the patch and it's looking good. I see some weirdness with saving for offline for us but I'm pretty sure that's client-side and/or because I'm serving it locally. Do you still have a staging step once the patch is merged, where it's hosted in mobileapps.wmflabs.org but not yet in production? I'd like to test there too before this goes live. Tagging @MattCleinman and @Dbrant in case they want to confirm anything with this on the Android side.

https://github.com/wikimedia/wikipedia-ios/pull/3969

@Jgiannelos @Mholloway I have a few of questions on how the push notifications service delivers notifications.

@vadim-kovalenko thanks for the heads up! I've been testing this and the mobile-html endpoint is working well. Since this is getting farther along in the flow I found another couple of 404s that occur once mobile-html successfully loads for the summary and media-list endpoints. Would it be possible to add the redirect logic to these as well? I wasn't sure if you wanted to consider the fix as a part of this task or separately since they are different endpoints.

Just piping in with my iOS digging, we currently request these styles from mobileapps:

This looks like a server-side issue, so tagging Product Infrastructure and moving into Tracking. Also I can reproduce on both 6.7.4 and 6.8.1, so it seems unrelated to our Chinese variant release in 6.8.0.

https://github.com/wikimedia/wikipedia-ios/pull/3956

PR for removing grunt entirely: https://github.com/wikimedia/wikipedia-ios/pull/3952

Nothing to test for this one, so moving to PM Signoff. Code change is in TestFlight build 6.8.1 (1815).

@cooltey thanks! That's helpful. Does your Explore feed preferences show anything about Top Read only being enabled for one of the languages?

@SNowick_WMF if you haven't already started, please QA on TestFlight build 6.8.1 (1814), which is our (hopefully) last release candidate.

PR: https://github.com/wikimedia/wikipedia-ios/pull/3943

There's not really any way to test this besides regression once wikifeeds is updated. Moving this to PM signoff - regression testing can be done as a part of https://phabricator.wikimedia.org/T282190.

Following up with some weirdness I did see, to document possible improvements we can make in the future:

I haven't been able to reproduce so far. I've been testing with both en and zh-tw and ja, on a fresh install of Testflight 6.8.1 (1813). I notice the Explore feed does continue to fetch previous when you scroll down to the bottom, and if you come back after several days it does not fetch intervening days, which is the opposite of how we originally thought this worked.

@MSantos we get that text from the summary endpoint, from the extract field. After digging deeper, it looks like there's an extract_html field that we should be using instead that will provide sub/sup data, I think we can fix this entirely client-side. I'll untag PI from this, sorry about that!

This is in TestFlight build 6.8.1 (1813).

Related to: https://phabricator.wikimedia.org/T281612

This will be in Testflight build 6.8.1 (1813).

This will be in Testflight build 6.8.1 (1813).

This will be in Testflight build 6.8.1 (1813).

This will be in Testflight build 6.8.1 (1813).