@DLynch sounds good, thanks!

Hi all,

It looks like the mobile-html endpoint ignores our Accept-Language header - I see Cyrillic characters even if we pass in `kk-latn' in the request:

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

We're opting out of encoding this on the server-side. We'll have to adjust the urlString here first by url encoding all characters after the first # mark. That should help this successfully insantiate.

Going to close this in favor of a client-side workaround. This work will be done in T307604. Thanks everyone!

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

Another Znuny report (no article details): https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12221642

Another theming bug report for track listings: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12219210

Similar report from Znuny due to custom yellow background, on the "List of highest-grossing animated films" article on EN Wikipedia:

@Tgr yep, just URLs in JSON structures. I was thinking if an encoded fragment would still be WhatWG-compliant, yet allow other clients with older URL standards to more easily deal with them, it would be win-win. But I see what you mean that the risk isn't worth it when there's a simple workaround on our side.

Some initial tweaks are in the xcode-14-building branch, though commit 7c8e3eb2ab should be re-evaluated to be sure it's the proper fix.

@vadim-kovalenko I did a bit of digging on our side, and it looks like iOS fetches both https://en.wikipedia.org/api/rest_v1/feed/featured/2022/04/08 and https://en.wikipedia.org/api/rest_v1/feed/onthisday/events/4/8 (not selected). However, when deserializing the https://en.wikipedia.org/api/rest_v1/feed/featured/2022/04/08 response we totally ignore the "onthisday" object. I believe the on this day events card is powered only by the results in https://en.wikipedia.org/api/rest_v1/feed/onthisday/events/4/8.

@kostajh Sorry for the delay - that sounds good! I'll write something up and send it to wikitech-l early next week.

@JMinor also kicked off another Experimental build with the current state of the PR. Thanks!

Most work is complete and in https://github.com/wikimedia/wikipedia-ios/pull/4239, just waiting on final copy now.

So as a team we decided against pulling in the swift-url library. The Swift Foundation URL is just too integral to all of Apple's APIs. It's also basically how we identify articles in the app so it would be a huge change if we were to switch to it across the codebase. If Apple were to come out with a new WhatWG-supported URL type of their own, that sign-off would be enough of a push for us to switch. WWDC is in two weeks - I'm extremely doubtful but maybe we can kick the can down the road until we're sure there's nothing new coming from them in this area.

Maybe it is possible to override that font directly in wikipedia-ios?

@matmarex thanks for the information! I didn't realize the URL standardization was that different with modern web vs Swift URL vs URLComponents, though I'm not wild about introducing a third party library for something as widespread as URL in our codebase. I'll discuss with the wider team in our sync tomorrow and will let you know our collective thoughts.

@kostajh sure - it's worth noting that we take the URL from the notifications API, extract the fragment topic title (we use the legacyPrimary URL since the topic title is more on its own there), and use that to send them to a native user talk page. The native user talk page matches up the topic titles with the fragment string and if it finds a match, sends them straight to that particular topic thread with its replies.

To expand on this bullet point:

Traffic patterns are as usual as ever.

@JMinor Agreed, that sounds good to me. Thanks!

Hi y'all - I believe whatever was last done for me on T308616 (adding me to analytics-private-users) might work here as well.

@Marostegui @Ottomata that worked! Thanks so much. FYI, this may be what is needed for what @Dmantena is seeing as well, see T308294.