In https://github.com/wikimedia/wikipedia-ios/commit/9be85f1303d3d41e9cbc8f408342aa69d604dd61 (the first of 2 commits removing the EPC storage manager), @mpopov sez:
Wed, Oct 28
Tue, Oct 27
@Tsevener It sounds fine to me to include that value as part of the announcement config if it's related.
Following up from a DM convo with @Tsevener:
To be revisited during API Gateway migration work.
Sat, Oct 24
Fri, Oct 23
Most of the article content got zapped during the swapping in of the collapsible infobox. It was contained within the replaced div because of the erroneous template usage. I'm satisfied calling this one a content issue and not a mobileapps bug.
Yes, thanks very much for fixing that, @Pcoombe!
For what it's worth, Parsoid is designating all sections of this article other than the lead section as non-editable (data-mw-section-id="-1"). They may want to investigate that. It seems to be the case going several revisions back, which suggests that the real culprit is probably a recent change to a transcluded template. Still, it's a bug for that to break mobile-html in this way, so a mobileapps update will be needed in any case.
Thu, Oct 22
As a 10% time effort I'd like to revive the CirrusSearch-based description and caption recommendations and see if that approach can be made viable. I think it was a much more robust solution overall, and we now have a random sort order in CirrusSearch (which was implemented shortly after the CirrusSearch approach was rejected by the Android team before) which turns out to actually be pretty fast. T220282#5377975
Alternatively, stop trying to force the renaming, and just live with Mobile-Content-Service? It's been a few years now, and that's the name that seems to have stuck.
@cooltey Can you confirm this is fixed?
Wed, Oct 21
Personally I quite strongly favor org-namespacing, but I was surprised to find that others disagreed, so opened this ticket for discussion. If FSG want to keep it open for discussion and eventual adoption of a convention, that's fine with me, otherwise we can just close it as declined and let the status quo be.
This is the expected behavior.
@JMinor Curious to hear from you on this. Is it something that you want to be able to target push notifications specifically to the iOS app only?
I'm sorry if I've muddied the waters by bringing up T256034: Provide for targeting notifications to specific platforms, since strictly speaking it's completely independent of this task, but I do think it's time to start digging into the technical details of how cross-platform push notifications should look, so I'll update there and welcome comments from everyone on this task.
Tue, Oct 20
The child task is still waiting on action from Cloud Services, but no reason to keep two tasks open about it.
Ah, I think I understand what's going on. The current implementation is pretty apps-focused, even before this patch. We've left it as an open question whether to handle web push within the existing "push" notifier type or whether they should be handled as a new, separate notifier type. (See also T256034: Provide for targeting notifications to specific platforms which is a related issue.) There's a similar open question about subscription storage. Now it's time to make some decisions.
I see @Jgiannelos commented on the patch that it's being discussed to put this into MediaWiki-extensions-MobileApp because it's becoming rather app-specific, but after looking at the code it's not obvious to me how that's so. @Catrope What are the differences between what's there now and what will be needed for web? I don't feel strongly about this code living in Echo specifically, but if it's getting too app-specific, then it feels like we might be taking a wrong turn somewhere...
Mon, Oct 19
Deployed this morning.
Fri, Oct 16
I've been assuming that @JMinor has been following along on this, but I suppose it's a good idea to get affirmative sign-off. We can hold off deploying this change until then.
Thu, Oct 15
After doing some background digging, it appears that the PrefUpdate schema is intended to capture specifically explicit, user-initiated preference changes (cf. T260867, a bug filed when the check for user initiation was dropped and events were being created relating to preference creation on user registration). If you drill down, you'll see that User::saveSettings is called from quite a few different places (including several different special pages), but I am gathering that in those cases, for purposes of the PrefUpdate schema, the fact of a preference being updated is incidental to what the user is trying to accomplish. Here, for example, it's essentially an implementation detail that mutes are implemented as a user option; the user doesn't navigate to Special:Mute intending to accomplish a preference change.
Wed, Oct 14
WikimediaEvents is enabled on all open, public, non-fishbowl production wikis.
Result diffs for en (P12997), de (P12998), and zh (P12999) before/after the patch above show that the diffs consist of pages now included that appear valid but were excluded by our apparently more aggressive filtering heuristic. I think this change can go forward.
Project is archived and we won't be putting any more engineering time into it.
The standalone mobileapps instance isn't meant to match the public REST API behavior exactly, simply to expose an instance of the backing mobileapps service publicly for testing.
Reopen in case of specific performance issues.
PCS language variant handing currently appears only to handle zh (Chinese) and sr (Serbian) variants (and only the general zh-hans and zh-hant variants in the case of Chinese). See lib/wikiLanguage.js and lib/wikiLanguageMapping.json. We'd be better off grabbing the full language variant info from siteinfo (just as @Dbrant suggests doing here in the Android app) rather than working from a hard-coded list.
Let us know if there's anthing more needed from Product Infrastructure.
Untagging PI and tagging Platform Engineering for consideration of the original feature request for ApiQueryRevisions.