Fri, Jun 21
Thu, Jun 20
@schoenbaechler @cmadeo sounds good! I should also clarify, this doesn't necessarily have to stay within the article content area, it could live somewhere else as a native panel on both platforms if you'd prefer. If it stays in the article content area, native views are problematic so should be avoided, an implementation in the content area should be HTML/CSS. This PR has an image and a gif of the initial rough draft footer implementation utilizing a modified version of the existing iOS app HTML/CSS approach. Mobile-html pages are available using the existing endpoint if it'd be helpful to mock up in situ.
Wed, Jun 19
For whoever picks this up - I did a rough initial implementation here: https://github.com/wikimedia/wikimedia-page-library/pull/208 feel free to take over that branch and run with it or close the PR if it's not useful
@bearND JS layer would query for that - it looks like that's already in pagelib
@bearND I was thinking the fetch should happen when the clients call a method like pagelib.c1.PageMods.fetchAndAppendRelatedPages(). That way there wouldn't need to be a determination when to append the related pages, the clients could decide if and when they wanted to fetch them.
Tue, Jun 18
Will be taken care of with work for T219998
Mon, Jun 17
@Mholloway works for me
@MSantos this should be fixed by https://github.com/wikimedia/wikimedia-page-library/pull/192 - I should have marked this as resolved. Feel free to confirm that patch fixes the issue though.
Fri, Jun 14
If there's no significant performance penalty on the MW API for getting additional fields, I'd say it's worth just returning everything
Thu, Jun 13
Wed, Jun 12
Could potentially help with the fix for T225443
Mon, Jun 10
Thu, Jun 6
@alaa_wmde thanks for the response. A separate endpoint like wbgetentitiesfordisplay would also be a good solution, doesn't need to be a parameter on wbgetentities. Added other answers inline below.
Wed, Jun 5
If we ever wanted to get the user's current signature as HTML: /w/api.php?action=parse&format=json&text=~~~~&pst=1&contentmodel=wikitext
@Jdlrobson it looks like this change https://en.wikipedia.org/w/index.php?title=MediaWiki:Mobile.css&diff=865253065&oldid=864403077 leads to this issue on mobile web
Tue, Jun 4
Thu, May 30
Wed, May 29
Tue, May 28
May 24 2019
May 23 2019
Took a quick look - the height of the navbar is jumping around during scrolling. It looks like removing the title text field and the description text field from the stack view and temporarily putting them as subviews of the main view in ReadingListDetailUnderBarViewController fixes this. Maybe something with how the text fields are interacting with the stack view to determine the overall height?
Sounds good, it seems like we should move forward with forwarding the Accept-Language header in all cases. From there, we can see what we need to workaround or try to get changed in MediaWiki.
@JMinor Any other information? Wiki language?
May 22 2019
May 17 2019
For reference, here's the wikidata entity: https://wikidata.org/w/api.php?action=wbgetentities&format=json&ids=Q403 The desired description for the BCP 47 code sr-Latn is under the MW code sr-el
It looks like action=mobileview on srwiki respects both the uselang parameter and the Accept-Language header to provide the correct displaytitle, but the description is still sr-Cyrl: https://sr.wikipedia.org/w/api.php?action=mobileview&page=Србија&format=json&redirect=yes&prop=normalizedtitle|description|displaytitle&uselang=sr-Latn
Focusing on the summary endpoint, it looks like neither the uselang parameter nor the Accept-Language header affect the title or description returned by action=query on srwiki. Testing with https://sr.wikipedia.org/w/api.php?action=query&titles=%D0%A1%D1%80%D0%B1%D0%B8%D1%98%D0%B0&format=json&prop=coordinates|description|pageprops|pageimages|revisions|info|langlinks|categories&lllimit=max&piprop=thumbnail|name|original&pilicense=any&pithumbsize=640&inprop=protection&rvprop=ids|timestamp|user|contentmodel&rvslots=main&clprop=hidden&cllimit=50&uselang=sr-Latn and seeing Cyrillic instead of Latin characters for all fields. Assuming the description source is "central", maybe a separate call to wikidata would be required to get the correct description? Is there any way to get the title in the desired language variant?