Needs product thinking

Needs product/design thought on this.

We're ready to rotate this key. Instructions: https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/establishing_a_token-based_connection_to_apns

We continue to get complaints from users, increasing priority of this task. That said, it's coming into the weekend, and this can wait for next week.

We're still receiving reports of this bug. It looks like there is a potential solution. Do you have an estimate of when it will be in production?

Do we know when this will be complete and deployed? Thanks!

Done here: https://github.com/wikimedia/wikipedia-ios/pull/4093

Done here: https://github.com/wikimedia/wikipedia-ios/pull/4093

Thanks for the additional context. Most of the team is out today w/ the US holiday, but we'll discuss early next week.

Another Znuny report: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12118332#

No, you're 100% correct. Thanks, total Friday brainfart over here.

We're still waiting for this to be deployed to production, right? Is there anything we can do to assist with it's deployment?

I'll note that the root ticket connected to this one (https://phabricator.wikimedia.org/T302436) is a Foundational Technology Request to get an API that allows only one type of edits (bot, non-bot, etc.). It's unlikely that process will finish anytime soon, but we've gone through the proper channels to reqeust an API enhancement for this.

I’m not quite sure who tagged Growth on that ticket, I just see it as Restricted Application. I appreciate your work digging in, @kostajh. I’m also not sure the broader implications of removing that limit. 😅

Confirming: This API version also works for the Android team, as well as iOS. Thanks to @DLynch for all your hard work on this.

Thanks! Let us know when it's live on beta cluster and we can confirm all is well.

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

For #1, how do you feel about letting iOS define the margins a little, rather than specified exact numbers? We can use readableContentGuide in our constraints to automagically tuck the margins in on larger devices (see https://developer.apple.com/documentation/uikit/uiview/1622644-readablecontentguide for details).

@cooltey found a couple issues with the patch:

Looking at the ticket, I suppose we never explicitly said the default should be not visible, other than calling it “optional”.

Checking in - What is the status on this task? Is the patch still under review? Thanks!

While we won't need help for ~3 weeks, adding Service Ops to this for advance notice.

Assigning to @Amire80 , as it's currently awaiting a confirmation.

Looks great to me, thanks @Jdlrobson!

Related ticket for non-notifications: https://phabricator.wikimedia.org/T283846

Another request: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12112868

A user wrote in requesting this: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12116599

This is fixed, and I'm closing the ticket.

Good call - I poked around a bit more with this. Bizarrely, this is the only size where this occurs. This file[0] output the text differently at 640[1] than slightly larger[2], slightly smaller[3], super big[4], and super small[5]. Of course, we're requesting it at 640. I'm asking around to learn more about how commons creates various sizes, will update this ticket as I get more info.

I finally got an old version of the app to compile and send just some requests to the patch demo server. (If all requests go there, the iOS app breaks in horrible ways.)

Per Peter above: iOS and Android teams are currently investigating switching to the new API for talk pages (https://phabricator.wikimedia.org/T285971). If that's successful, this ticket becomes irrelevant and we may be able to remove the /api/rest_v1/page/talk/ API entirely.

Seemingly feasible

1. Endpoint for counts for all types (capped at some large number)

Another request for this in email.

@ABorbaWMF thanks for looking into this - apparently it's not going to be an easy one to find. Thank you for looking into. the upgrade paths. Hopefully folks who have experienced it can help us narrow down the cause - we'll start sending those follow-up questions out to people shortly.

Moving a snippet from a dup'd task into here:

Another example: https://en.wikipedia.org/wiki/Wikipedia:Help_desk/Archives/2022_January_24#Link_working_in_desktop,_but_not_iOS_mobile_version

In the last month, 0.73% of our sessions came from apps using MobileView API. (Source: App Store Connect Analytics.)

@Dbrant Good point. I've changed terminology here to call it an "issue" and "disappearance".

We need this ticket to complete before we can work on this: https://phabricator.wikimedia.org/T285971

@JMinor @JTannerWMF @schoenbaechler @OTichonova @cmadeo - I've started a mediawiki page that this message will link to. Please feel free to edit it or build it out: https://www.mediawiki.org/wiki/Wikimedia_Apps/Sunsetting_MobileView

New PR for this: https://github.com/wikimedia/wikipedia-ios/pull/4120

While looking into this, I found that PCS uses the MobileView API for all requests for Chinese Wikipedia (zh.wikipedia.org). I'm not sure the history of this, but it complicates the retirement of this system. I'm adding Content Transformers to this ticket, as we're going to need their support to figure out how to remove this dependency.

I believe this is going to be irrelevant by https://phabricator.wikimedia.org/T285971. If that new API works as expected, we may even be able to deprecate the /page/talk endpoint.

@DLynch Thank you!!!! That looks absolutely amazing. And apologies for not reading the ticket carefully enough.

While making these changes, two other tweaks (that I think should be fairly easy):

• Could the response include a timestamp field for each comment, now that the information is available?
• Could the response include a field for the username of who wrote each comment?

Related ticket: https://phabricator.wikimedia.org/T285971

Bug fix is up for review: https://github.com/wikimedia/wikipedia-ios/pull/4114

Same issue in notifications-push-talk-body-format

I've been getting this not for Wikipedia app, but for various other apps/websites. I'm thinking it's an Apple bug, but we should confirm that.

Can reproduce on iPhone SE (2020).

@Sharvaniharan Which API are we currently using for this? If you can let me know that API, I'll see how possible it might be for server teams to allow for filtering. Thanks!

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

This is from machine learning that was added to try to improve short descriptions by identifying the language. Unfortunately, sometimes there are false positives. (That said, I'm surprised that Hebrew, with a unique character set, triggered a false positive.) Since we know that there are occasionally false positives, this message is intentionally a warning, and should not prevent the short description from being added.

It seems like there might be a new API we can use, but if not, here is a suggestion from a user: Since the focus issue for non-face images mainly applies to portrait-orientated images – because they are cropped to a landscape format, while the latter remain mostly unchanged – I suggest that a quick fix could be to just center the crops of all non-face images by default?

This is mostly done in prototype branch.