That page works for me. I got the latest Alpha of the app, though.
Sat, Jan 20
Does MCS support generating summaries for non-wikipedia projects at all?
Fri, Jan 19
@ovasileva @phuedx @Jdlrobson I think eventually we need the summaries pre-rendered on all projects. But just for now, do we need to re-render the summaries for non-Wikipedia projects as well? Is Page Preview available for any of these? I've seen only the Navigation popups gadget on the other WMF wikis I tried, and I think that doesn't use the /page/summary endpoint.
I think for this one we need some input from the Services team, to tell us which ChangeProp events we should emit, and how to do that. IIRC @mobrovac said mobile-sections would need to emit an event to ChangeProp, so we can have an event chain:
/page/html -> /page/mobile-sections -> /page/summary
I don't think there is need for <nowiki>. I just used <syntaxhighlight lang="json"> for the whole output.
Thu, Jan 18
Now it shows the correct description.
I was thinking an #wikimedia-ri-ci channel, similar to #wikimedia-android-ci. Basically, a channel just for CI.
Yes, there is currently only one beta cluster test left, and we skip it since yesterday. I'm just saying IF we need to keep Beta Cluster tests they should go to the large tests, too. Ok, I guess that was implied. Just being explicit.
Wed, Jan 17
@Jdlrobson I think we can deploy to MCS what we have merged so far tomorrow. The switchover has to happen in RESTBase, which should happen after the DevSummit week anyways. There are a few more tasks in MCS outstanding, too. I believe there is a good chance we will have the extra space eradicated as well by then, too. But I'm ok if that happens after switchover, too. Same for the nested <span></span>.
Tue, Jan 16
Mon, Jan 15
Hmm, https://commons.wikimedia.org/w/index.php?title=Commons:Picture_of_the_day/all_languages&action=submit#10 or https://commons.wikimedia.org/wiki/Template:Potd/2018-01-10_(en) has multiple languages.
Sat, Jan 13
+ Performance team with the hope for some better ideas.
Fri, Jan 12
When looking at this patch I was also thinking if we should also keep inline style attributes. Thoughts?
Thu, Jan 11
We could use the Node Performance API for this. We have a few scripts which go through the top pages of a few wikis. I think I modeled the measure-payloads.js script to use the Node Performance API but ended up mainly checking the payloads.
This is what we currently have for Citations:
(Cite elements usually have some kind of type indicator in the class list, like "citation web" or "citation book".)
We show only one single value in the type field. If there is a single cite tag anywhere in the reference content or there are multiple cite tags with the same value we show that value. If there are none or multiple cite tags with different values we show "generic".
Wed, Jan 10
Not super urgent. Just would like this in the queue so Parsoid and friends can handle more pages eventually.
Tue, Jan 9
Hmm, that's strange. I just tried it a few minutes ago, then I saw the page deleted 404 on both the summary and the Parsoid version of this page.
Done. Added a checklist, too.
I think this should be in the payload, where we would use the revision number and tid we get from Parsoid.
The headers will have similar values embedded in the ETag. The revision would be the same but I think the render tid would be different for each endpoint.
A client can get only the latest summary, so the timestamp change should not make a difference.
Mon, Jan 8
We have a Wiktionary definitions endpoint, but that works only for English Wiktionary (examples bar, and). Other language Wiktionaries may use different page structures, which makes them more difficult to parse.
Sounds good to me. Updated the description.
Sat, Jan 6
The output format change is deployed so we can close this one. To be continued in T184316.
Fri, Jan 5
Thanks. I was just going through the log files to see if anything is up. I guess we can ignore these.
We're trying to come up with a JSON API for references. You may want to check out https://www.mediawiki.org/wiki/Page_Content_Service/References and leave feedback at T170690.
Not sure. That's really up to the Services team.
Thu, Jan 4
Related but not necessary to fix this issue.
Just curious what this is supposed to do. Is it adding git tags on the src repos (the submodules) after a successful deploy?
If so I would recommend to also have an indication where it was deployed (beta cluster vs prod), maybe inside the tag comment.
I usually deploy twice, BC then prod. Also curious if it would tag rollbacks, too.
Wed, Jan 3
This only happens in the Explore feed. When going to the page it looks correct.
The data for the explore feed is coming from https://en.wikipedia.org/api/rest_v1/feed/featured/2017/12/29.
I think this is an app issue. What's the difference?
It's correct for the full page view because the page content gets rendered inside a WebView.
The explore feed cards get rendered using native TextViews. It could be that this gets messed up. From what I remember it could be something like Html.fromHtml() or similar.
Update: Pchelolo wrote a script to rerender the outstanding pages. So, the pages have been updated.
Tue, Jan 2
@Pchelolo I cannot find any error log entries for the George_Washington article in the prod logs, and running this locally on my box and on a machine works, so it doesn't seem like an MCS issue to me. Would you see if this page was updated so far this year through ChangeProp?
@Pchelolo this instance is not about the featured feed. It's about a regular (albeit popular) page not getting updated after a template transclusion.
Dec 15 2017
Yes, 1.2.0 of the summary endpoint still calls TextExtract.
The implementation of the new version 1.3.0 will be radically different.
It will fix this by using all of the first paragraph (called intro) in the lead section. This new version is implemented directly as part of PCS using DOM transformations on top of Parsoid output. We plan to deploy this in January.
Done, see T182802.