User Details
- User Since
- Sep 19 2016, 7:13 PM (376 w, 18 h)
- Roles
- Disabled
- LDAP User
- Unknown
- MediaWiki User
- NHarateh (WMF) [ Global Accounts ]
Nov 19 2019
looks like an iOS 13.1 bug, appears to be fixed in iOS 13.2
looking at the arrow color bug, looks like there were some changes to nav bar appearance in iOS 13 - https://developer.apple.com/documentation/uikit/uinavigationbarappearance
Nov 16 2019
Nov 15 2019
thanks for the screenshot @ABorbaWMF! The centered headers seem off too - I added that as a bullet point to the punch list ticket - T237314
Nov 14 2019
Nov 8 2019
Nov 7 2019
Nov 6 2019
Nov 5 2019
@awight thanks for asking! it was already merged, should go out when 6.5 is released: https://github.com/wikimedia/wikipedia-ios/pull/3315
@cmadeo thanks for the review!
Nov 4 2019
Oct 31 2019
Thanks for catching this @Luky001, and thanks for the callout @MarcoAurelio! Pushed a fix: https://github.com/wikimedia/wikipedia-ios/pull/3311
Oct 11 2019
Great, thanks @cmadeo!
@cmadeo Selection flow question
Oct 10 2019
Oct 9 2019
BTW, in looking at the design mock-up currently in the description of that task I note that it does not seem to be using the counts of total actors or of reverted edits since the change in T228783#5439449, while it does seem to want to know the count of "user edits" (meaning non-IP?) and the count of revisions with rev_minor_edit set. The "user edits" could be calculated as total edits - IP edits,[2] but the count of minor edits would need a new endpoint.
Oct 7 2019
It's enough detail for me - one thing I forgot to mention is that the API offers only daily/monthly granularity as of now :(
If we want to use the edit metrics API, max queryable timespan is limited to 1 year (https://wikimedia.org/api/rest_v1/#/Edits%20data/get_metrics_edits_per_page__project___page_title___editor_type___granularity___start___end_)
@Aklapper Victor submitted a pull request with this change here: https://github.com/wikimedia/wikipedia-ios/pull/3291
Oct 2 2019
Thanks for clarifying @eprodromou! Yes, if it makes it easier for you, we can make multiple calls
Sep 30 2019
Are you planning to have one endpoint that combines all the count types? Something like /page/{title}/history/counts that returns all the counts or /page/{title}/history/counts?type=revertededits&type=botedits&type=anonedits that returns selected count types
Sep 28 2019
Same user also suggested that it would be useful to be able to add the Main page to saved articles.
Sep 27 2019
Sep 19 2019
Sep 18 2019
Sep 13 2019
Sep 12 2019
I couldn't find anything about a public API that lets us hook into the undo / redo actions as of iOS 13.1.
I couldn't reproduce this on a device running 12.4.1, here's a gif of what the flow looked like for me -
Sep 5 2019
Sep 4 2019
Sep 3 2019
Per 09/03/2019 sync, it'd be ideal to be able to restore the feed position.
Aug 30 2019
Aug 29 2019
The file appears to be unsigned.
When the language changes in Settings, the app is relaunched and (mostly) restored to its previous state.
Aug 28 2019
Aug 27 2019
Aug 26 2019
The solution to this is related to the modal presentation of Settings (T229489). If we stick with the full screen modal presentation (default < iOS 12), this will be fixed. If we use the new iOS 13 modal presentation (card that can be dismissed), this will require further investigation - the swipes seem to be interfering with each other (dismissal vs font size slider swipe).
The PR that excludes the app from dark mode was merged into the xcode_11 branch (https://github.com/wikimedia/wikipedia-ios/pull/3165).
Some system controls end up being too dark/light when there's a system/app theme mismatch.
The reorderControl caught by @Tsevener is not exposed via a public API so we can't adjust its tint color. Setting a custom editingAccessoryView results in not being able to drag & reorder items.
Aug 23 2019
On iOS, we append 2 special items to TOC - “About this article” (https://github.com/wikimedia/wikipedia-ios/blob/ca4df05eaeab29aaa9c023aa8bb9ce59f5feb39e/Wikipedia/Code/WMFArticleContainerViewController%2BTOC.swift#L124) and "Read more" (https://github.com/wikimedia/wikipedia-ios/blob/ca4df05eaeab29aaa9c023aa8bb9ce59f5feb39e/Wikipedia/Code/WMFArticleContainerViewController%2BTOC.swift#L127).
If the user taps on “About this article“, we scroll them to pagelib_footer_container_menu. For “Read more”, it’s pagelib_footer_container_readmore (https://github.com/wikimedia/wikipedia-ios/blob/ca4df05eaeab29aaa9c023aa8bb9ce59f5feb39e/Wikipedia/Code/WMFArticleContainerViewController%2BTOC.swift#L60).
Aug 22 2019
This is not reproducible on a device (iPhone 7 Plus) running iOS 13 beta 8, only on a simulator.
This is not reproducible on a device (iPhone 7 Plus) running iOS 13 beta 8 (or previous), only on a simulator.
Aug 20 2019
Aug 16 2019
Thanks for all the clarifications @MusikAnimal, it's very helpful! Moving this spike to Blocked & Waiting now so that the iOS team can reassess. Related development work continues in T228783.
Aug 14 2019
Thank you for all the information @Mholloway, that's super helpful!
Aug 9 2019
Aug 8 2019
User added that the problem is occasional and it occurs when editing the references and/or external links sections
Aug 7 2019
If "Open app on Search" is on and I leave the app with a stack of articles pushed from Search, should I have the stack restored or not (assuming it happens before the cutoff date)?
@Eholshouser Thanks for looking into this. I'd expect the "Open app on Search" setting to override state restoration. cc @JMinor
Aug 6 2019
- Sparkline: https://wikimedia.org/api/rest_v1/metrics/edits/per-page/www.en.wikipedia.org/Ching_Shih/all-editor-types/daily/20170404/20190806. Queryable timespan is limited to 1 year. We could assume that the start year is current year - 1 but if a page was created less than 1 year ago, we'll get a 400 response (https://wikimedia.org/api/rest_v1/metrics/edits/per-page/www.test.wikipedia.org/Young_page/all-editor-types/daily/20170806/20190806). We could get page's creation date using https://xtools.wmflabs.org/api/page/articleinfo/en.wikipedia.org/Ching_Shih (created_at).
- Getting total number of edits for page: https://xtools.wmflabs.org/api/page/articleinfo/en.wikipedia.org/Ching_Shih (revisions)
- Getting total number of editors for page: https://xtools.wmflabs.org/api/page/articleinfo/en.wikipedia.org/Ching_Shih (editors)
- Count of minor/ip/bot/reverted edits for page: XTools API doesn’t expose those in the API response for articleinfo, looks like it could be included:
- Building the response: https://github.com/x-tools/xtools/blob/6d8f265ec0aecf6f3a6909b742cc4cda0d28d94f/src/AppBundle/Controller/ArticleInfoController.php#L238
- Gettings counts https://github.com/x-tools/xtools/blob/19bcac6775a8302273a4314bbfe1b0e753458255/src/AppBundle/Model/ArticleInfo.php#L485
- Talk page question: https://www.mediawiki.org/wiki/Topic:V4x15ga6upb875w1
- It's possible to add an option to get the number of minor & IP edits. Getting the number of reverted edits would be too slow for an API endpoint (it's an approximate figure anyway).
- Total number of edits for user: https://xtools.wmflabs.org/api/user/simple_editcount/en.wikipedia/Badylek (live_edit_count). API docs state that To ensure performance and stability, most endpoints related to users will return an error if the user has made an exceptionally high number of edits. (https://xtools.readthedocs.io/en/stable/api/index.htm)
- Sending thanks:
- api.php?action=thank&rev=16543&token=%2B\, https://www.mediawiki.org/wiki/Extension:Thanks#API_Documentation
- Python example: https://gist.github.com/notconfusing/460d6ffb6682439ebe6b70b78e7759af#file-flask_thank_app-py-L60
Aug 2 2019
Aug 1 2019
Jul 19 2019
It looks like the endpoint we're using to get languages for articles in the main namespace doesn't return languages for user talk pages.