Thu, Oct 29
Would be nice to slip this into 6.8.
Wed, Oct 28
Tue, Oct 27
Fri, Oct 23
Thu, Oct 22
Toni and I compared iOS 13 and iOS 14. Could not find any regressions in iOS 14.
Tue, Oct 20
Mon, Oct 19
Fri, Oct 16
OTRS request for this: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=11546616
Fri, Oct 9
Thu, Oct 8
- Move tappedThank and associated unctions from DiffContainerViewController to a protocol and protocol extension.
- Test that I didn't break anything in DiffContainerViewController.
- Make Article as a Living Doc conform to new protocol.
Looks like it's working well!
Wed, Oct 7
Mon, Oct 5
Sep 29 2020
Sep 28 2020
Hello! We've been doing something similar on our end, but it's definitely better to standardize this based on the way it's working for other repos.
This should be fixed/improved in 6.7.1. Please let us know if this behavior still occurs in this release.
Sep 24 2020
Sep 23 2020
Upon reading that thread, I'm thinking this one is either from:
- An iOS 14 issue (most likely)
- Some issue related to the periodic crashes we're seeing in widgets, which causes a refresh/crash loop. (For this one to be the case, all widgets in the gallery would have to be updated when one crashes. That seems like weird architecture, but who knows.)
Cannot replicate, and several folks have not seen this one recently. We believe/hope it was fixed by other widget tweaks. Will have QA do one final check on this release. (Of course, if this pops its head back up, we'll look into it.)
Several of us have seen this behavior at this point, including when not looking at any Wikipedia widgets. It seems like this also happens sometimes when looking at stock widgets. And if so, is it fair to guess this is on Apple to fix?
I can't seem to replicate this on device. Except for the device - a XR instead of an 11 Pro Max - everything is identical.
Sep 22 2020
Definitely a dup of https://phabricator.wikimedia.org/T261027, so closing this one.
From looking at the variety of links created on a test wiki page, looking at how they look on web (that link), after PCS parsing, and in the iOS app, it seems like the actual solution here is for us to detect if a URL is already encoded. This could be done on one of two levels:
- iOS app - if encoded, don't encode the URL ever
- PCS - if encoded, pass the unencoded version to the mobile apps
QA test instructions:
- Install app, open app, add a widget to homescreen.
- Tap widget, ensure app opens to On This Day screen scrolled to proper element.
- Change language to another one that supports On This Day (like French, Spanish, Arabic, Russian, and a few others). The widget should show the other language. Tap widget, ensure app opens to On This Day screen scrolled to proper element - in proper language.
- On a phone w/ a notch (iPhone X style), scroll to top of On This Day screen in app. Rotate phone so notch is on left side, ensure the header's padding respects the notch - the text shouldn't be hidden by the notch.
- Background the app (go to home screen). Hard quit the app. Reopen the app. Ensure that On This Day screen in the app still has a "back" button and not the "X" (which it has when the On This Day card is tapped on the explore screen).
If an editor uses an encoded version of a special character in a link, it automatically is converted to the actual character in the link when the edit is saved. So writing a link as https://commons.wikimedia.org/wiki/Duszniki-Zdr%C3%B3j?uselang=de or https://commons.wikimedia.org/wiki/Duszniki-Zdrój?uselang=de doesn't matter, as both will be saved in wikitext as https://commons.wikimedia.org/wiki/Duszniki-Zdrój?uselang=de.
This is happening when linking to off-wikipedia wikimedia-project site (wikiquotes, commons, wikidata etc.). That is the commonality between all of these.
In short: This is likely going to be fixed in PCS; I'm chasing it down that path now.
Sep 21 2020
Likely related: https://phabricator.wikimedia.org/T259902
Seems like a translation issue, given that they're seeing %1$@ unexpectedly.
I don't think we'd be able to have two different languages in the same sized widget (though there may be a hacky way to make it happen), but we could use different languages on different sized widgets of the same type.
Sep 19 2020
Sep 18 2020
PR is up for all of these: https://github.com/wikimedia/wikipedia-ios/pull/3705
This fix is being handled here: https://github.com/wikimedia/wikipedia-ios/pull/3703/
It's possibly a context issue. When debugging, you can see the new language being updated appropriately, then trying to get the language from the widget, and there it shows as the outdated language.
Sep 17 2020
Progress made: If this is threaded, it's a race condition. If it's not threaded, we're just pulling the data before we're setting the new language. It doesn't take two moves to get the language to update - it's always using the prior language.
PR for main part is merged: https://github.com/wikimedia/wikipedia-ios/pull/3701
Can confirm that the video is Russia's on this day for yesterday (when video was taken): https://ru.wikipedia.org/api/rest_v1/feed/onthisday/events/09/16
Sep 16 2020
Looks like the second time a cell loads (scroll down, then scroll back up) sizing is appropriate.
This happens within resetContentOffset() in SideScrollingCollectionViewCell.swift. It seems like the collectionView's sizes (especially collectionView.contentSize and collectionView.bounds) aren't being properly calculated before the function is called, even if you spam collectionView.setNeedsLayout() / collectionView.layoutIfNeeded() at the top of the function.
Also, the "X" to close the screen is on the wrong side in RTL languages.