User Details
- User Since
- Nov 19 2014, 8:27 PM (243 w, 1 d)
- Availability
- Available
- IRC Nick
- bearND
- LDAP User
- BearND
- MediaWiki User
- Unknown
Today
Yesterday
-1 are uneditable sections, -2 are Pseudo sections, as determined by Parsoid[1].
One approach could be to not include these in the actually displayed ToC.
Tue, Jul 16
MCS deployed with new pagelib release 8.3.0 and
purged:
Mon, Jul 15
The deploy keeps failing due to the talk page endpoint timing out.
Check 'endpoints' failed: /{domain}/v1/page/talk/{title} (Get structured talk page for enwiki Salt article) timed out before a response was receivedhttps://github.com/wikimedia/wikimedia-page-library/pull/218 is merged and will be released soon.
Fri, Jul 12
@NHarateh_WMF where in the iOS app or lite app code is this used so I can better understand this?
We left that out since we wanted to have something platform agnostic. Is there a way you could do the conversion to whatever is needed on the iOS native side?
Thu, Jul 11
For testing it might be easier to have another example from srwiki. 1st) It might work earlier. 2) Seeing the difference between Cyrillic and Latin is easier for most westerners.
I think I ran into issues with that but I'm not sure anymore. That would require some testing.
I think we could just rename the property from areTablesCollapsed to areTablesInitiallyExpanded. Then it should work.
Yes, @Mholloway is correct. I remember having to work around this issue. Not sure what the latest about storing these kinds of results is but I suspect we don't store featured feed results anymore and just do Varnish caching. Adding @Pchelolo to confirm.
Mon, Jul 8
Sat, Jul 6
The PR has been merged and is released as part of pagelib v8.0.0.
Wed, Jul 3
FWIW, template info is included in Parsoid output. So, once iOS moves to /page/mobile-html this could be theoretically possible.
Tue, Jul 2
Mon, Jul 1
Wed, Jun 26
Tue, Jun 25
To make the RB implementation easier the MCS version of the spec is in https://phabricator.wikimedia.org/diffusion/GMOA/browse/master/spec/page/talk.yaml.
Thu, Jun 20
Wed, Jun 19
@JoeWalsh Ok, thanks!
@JoeWalsh Thank you for updating the description. One part is not clear to me yet. Maybe I have missed it.
Where are the readMore items coming from? Is the app providing this list or is the JS layer expected to query that?
Yes, the saved state could be handled as part of the interaction handling, in a follow up to T219998.
Jun 18 2019
Just talked with @JoeWalsh about this. For now we're planning on injecting the translated strings from the client. That should be easier to do than setting up I18N server-side and mapping accept-language header values to the right message catalog. Updating the description to reflect that.
Probably not needed for now. The apps can request the summary and usually have it first anyways.
I assumed we would not need to support different strings for Android vs. iOS inside the WebView content. It's probably best to ask the PMs. If this becomes a requirement then it would be best to have the clients pass those strings in since that would be bad for caching and storage to serve two different platform variants for each page, as you mentioned. It wouldn't be ideal from a performance aspect to have this done by clients, though, because that would add more client side DOM changes.
Jun 17 2019
The mobile-sections endpoint and most of the other MCS/PCS endpoints were built to support the Wikipedia apps. So, most endpoints have only been tested with *.wikipedia.org domains. (The exception is the definitions endpoint but you probably don't care about that one.)
May I ask what features of mobile-sections you are most interested in and are the reason for not using Parsoid directly?
It hasn't been deployed yet. Should be today, though.
Jun 14 2019
Jun 13 2019
Jun 12 2019
Not sure what level this should be best resolved. My guess is probably Parsoid or upstream from that.
Parsoid also 404s: https://en.wikipedia.org/api/rest_v1/page/html/User:JoeWalsh_(WMF)
The reason why I mentioned mobile-html and the other PCS endpoints is that those will replace mobile-sections in the future.
Jun 11 2019
Then we can close this. Thanks, @NHarateh_WMF and @Sharvaniharan!