Do you show the number of language links in the toolbar button? If not we could probably consider delaying getting the languages list for this until the user actually clicks on it.
I'm assuming that this is relatively rare. Do we have any data showing this?

PR 244 has been merged and published, and MCS deployed plus the JS and CSS of the pagelib URLs purged from Varnish, but doesn't show any noticeable improvement.

@cmadeo Should there be a different icon used for the RTL direction?

FYI, JoeWalsh added minification of the pagelib CSS in https://github.com/wikimedia/wikimedia-page-library/pull/244 and pagelib version 9.1.3.

MSantos is correct

@JoeWalsh I don't see description_source in https://en.wikipedia.org/api/rest_v1/page/summary/Dog.
I think we want to avoid adding more to /page/summary without the web teams consent. They use the summary endpoint for their page previews.

Do we have icons for opening the native References sections?

How do we best go about this? Should we re-image the current system or create a new one?

The things we can't get from Parsoid are:

• language links
• protection
• description source

Doesn't happen with the media-list endpoint.

curl "https://de.wikipedia.org/api/rest_v1/page/media-list/Wikipedia%3AHauptseite%2FSchon_gewusst%2FZeittafel"

Not sure who to best ping about this at this time.

One idea, just to throw out there, would be to check if the title has any parentheses. If so we could just skip stripping any parentheses. I think that could be an easy check to make. The downside would be that the extract may have parentheses we might have removed otherwise.

I haven't heard about this until now. My guess is no but probably better to ask @Jhernandez or @JoeWalsh.

The example mentioned in above link is

Thank you for submitting the task and the patch!

I doubt it.

I think on the RESTBase side it would be nicer to expose the endpoint under /page/transform/html/to/mobile-html as it will fit into the current structure of the transform endpoints.

What we have right now ready to deploy:
pagelib: added Page.setEditButtons(isEditable, isProtected)
PCS server: stop showing edit pencils by default

Yes, these pages are accessible in the app. You can search for them (e.g. "User:Pchelolo") or open them through a link.

@Pchelolo I don't think that would be acceptable because it would not allow us to render these pages on demand. Stopping pre-gen is one thing; not being able to view those pages in the apps is a breaking change IMO.

The pagelib PR[1] is ready for review but we might need some server side code to make sure we start out with hidden edit pencils to avoid FoUC.

Which part is missing? When I compare the mobile-html output with the mobile web page it appears to be there.
Granted, mobile-html runs slightly different DOM transformations than mobile-sections, but it should be similar enough to get a rough sense of how the page would look like and is much easier to look at. Both mobile-sections and mobile-html are based on Parsoid output.

The root cause is the same. This is just a different manifestation.

Forgot one (not insignificant) thing that we also need:

• Move some of transformations from PCS to the pagelib code base. Then we could run those from inside the app.

That is needed unless we're fine displaying pure Parsoid output for the edited section.

Currently have it as a simple Page.getRevision(). Let me know if that works out or if you need it routed through a callback.