Page MenuHomePhabricator

Show HTML summaries on cswiki
Closed, ResolvedPublic2 Estimated Story Points

Description

Background

In T173639: Hovercard text extract is broken for `* ` sequence in parenthesis, cswiki community members proposed testing the HTML summaries produced by the new Summary API. We would like to release it to cswiki first and do a round of QA prior to switching all projects to showing HTML summaries.

Acceptance criteria

  • Switch cswiki to showing HTML summaries
  • Prepare test articles for QA
  • Do a round of QA (full test plan) on cswiki
  • Ping @bearND and @Mholloway when this has happened.

Sign off steps

  • If any bugs are discovered during QA we may want to revert the change (Olga's decision). Bugs should be captured. We shouldn't rush to fix anything while the code is in production.

Done in https://www.mediawiki.org/w/index.php?title=Reading%2FWeb%2FRelease_timeline&type=revision&diff=2721756&oldid=2720598.

Developer Notes

  1. This is as simple as adding $wgPopupsGateway = 'restbaseHTML'; to the config. Note that this gateway is different from the "RESTBase Plain" gateway, which is currently in use on all of the Wikipedias.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson added subscribers: Mholloway, bearND.

Probably blocked till at least Wednesday

Deploy now delayed until Monday.

Here's the latest comparison run for the Czech html extracts from TextExtracts vs the MCS summary implementation: http://wpsummary.surge.sh/1.2.0-b0be98c/html/cs.html. See also T179875#3986429. Starting soon.

ovasileva raised the priority of this task from Medium to High.Feb 21 2018, 4:05 PM

Summarizing: @EddieGP's config change patch can be merged pending verification (see QA notes above) of the summary v1.3 rollout.

The summaries for all pages on cswiki are now rendered using MCS.

The summaries for all pages on cswiki are now rendered using MCS.

I found no problems with the summary texts so far. But I stumbled across a lot of pages for which I see in the summary a blank space in the place of (expected) picture. E.g. Douglas MacArthur‎, Benito Mussolini, Chester Nimitz, Prezident Spojených států amerických, Labradoodle and others.

The thumbnail in this page preview looks definitely wrong:
On https://cs.wikipedia.org/wiki/Donald_Trump hover over "prezident Spojených států amerických"

Screen Shot 2018-02-21 at 3.17.03 PM.png (646×933 px, 381 KB)

The thumbnail URL in the summary for the target page (https://cs.wikipedia.org/api/rest_v1/page/summary/Prezident_Spojen%C3%BDch_st%C3%A1t%C5%AF_americk%C3%BDch) looks right, though: https://upload.wikimedia.org/wikipedia/commons/0/0e/Donald_Trump_Pentagon_2017.jpg

I can also reproduce the same on a few enwiki pages, see new subtask T187955.

The thumbnail in this page preview looks definitely wrong:
On https://cs.wikipedia.org/wiki/Donald_Trump hover over "prezident Spojených států amerických"

I see a blank space instead of icon. But that could be a matter of different browser. I am using Firefox 52.6.0 ESR.

Correct. I can repro it on FF showing blank space. What I showed above was with Chrome.
Thank you for reporting this.

The cswiki page summaries have been re-rendered with the correct thumbnail size. We're still working through other wikis but for cs the blank thumbnail image issue should be resolved.

The cswiki page summaries have been re-rendered with the correct thumbnail size. We're still working through other wikis but for cs the blank thumbnail image issue should be resolved.

The situation has improved, but I am still getting blank spaces instead of thumbnail for some of the above mentioned pages:

Douglas MacArthur‎
Benito Mussolini
Prezident Spojených států amerických

Thumbnail is served correctly now for:

Labradoodle
Chester Nimitz

@bearND - we're planning on switching html previews on today during the European mid-day SWAT.

The cswiki page summaries have been re-rendered with the correct thumbnail size. We're still working through other wikis but for cs the blank thumbnail image issue should be resolved.

The situation has improved, but I am still getting blank spaces instead of thumbnail for some of the above mentioned pages:

Douglas MacArthur‎
Benito Mussolini
Prezident Spojených států amerických

But these seems like rare exceptions. The only other failed thumbnails I've found so far are for Friedrich Engels and Adolf Hitler. Perhaps some lokal cache issue? I'll try with another browser.

@Vachovec1 - just checked through some of these as well - I'm seeing thumbnails on Prezident Spojených států amerických, Friedrich Engels, Benito Mussolini

Change 396318 merged by jenkins-bot:
[operations/mediawiki-config@master] Show HTML summaries on cswiki

https://gerrit.wikimedia.org/r/396318

@Vachovec1 - just checked through some of these as well - I'm seeing thumbnails on Prezident Spojených států amerických, Friedrich Engels, Benito Mussolini

Definitely caching issue. It worked as expected in Chrome. But for the Firefox, the cache was very persistent. A simple purge may not be enough, I needed minor edits for Prezident Spojených států amerických and Benito Mussolini's summary thumbnails to work.

Mentioned in SAL (#wikimedia-operations) [2018-02-22T14:26:53Z] <zfilipin@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:396318|Show HTML summaries on cswiki (T182321)]] (duration: 01m 13s)

It seems there is some collision between the page previews code and "Zvýrazňovat přesměrování" (highlight redirects) gadget now. The redirects in the text extract are now highligted with rose background and overline. See for example previews for:

Anna
Ctiborův dub

If the gadget is disabled, the page previews behave as expected.

html previews now live. math looks great!

Screen Shot 2018-02-22 at 3.22.43 PM.png (429×409 px, 105 KB)

some small issues detected (listing them here and we can move to appropriate bugs later):

Screen Shot 2018-02-22 at 3.28.37 PM.png (272×389 px, 75 KB)

Screen Shot 2018-02-22 at 3.29.35 PM.png (299×425 px, 94 KB)

Screen Shot 2018-02-22 at 3.42.37 PM.png (291×570 px, 146 KB)

that's all I've noticed for now, but will keep testing.

(@Vachovec1) After switching HTML previews on, should we maybe inform Czech Wikipedia community about what happened and how to track bugs right?

(@Vachovec1) After switching HTML previews on, should we maybe inform Czech Wikipedia community about what happened and how to track bugs right?

It would be definitely helpful to post an appropriate message in our Village pump (technical): Wikipedie:Pod lípou (technika).

@Vachovec1, @Dvorapa - yup, we'll be posting a message later today. Next step here would be to QA internally but we'll be asking for some help in identifying edge cases in our message as well

@ovasileva - T182321#3992796 is an example of an edge case or a bug? The preview should probably not accept css definitions designed for the normal article text. The above mentioned gadget may not be the only one that will influence the preview.

@Vachovec1 - good catch. I don't think we had thought about how all the gadgets might work with the feature. I'll open a separate task for this. For posterity, here's an example of the preview:

Screen Shot 2018-02-22 at 4.35.45 PM.png (263×409 px, 48 KB)

issue now logged here: https://phabricator.wikimedia.org/T188005
@Vachovec1 - I'm a bit conflicted on whether this is a bug or not. I can see a case being made for an editor who enabled the gadget to expect redirects within previews as well.

@ovasileva - T182321#3992796 is an example of an edge case or a bug? The preview should probably not accept css definitions designed for the normal article text. The above mentioned gadget may not be the only one that will influence the preview.

that should be fixed in the gadget. The styling introduced by said gadget is very generic. Vachovec1 would you be so kind to flag that to the gadget author(s)?

Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task from Doing to Needs QA on the Readers-Web-Kanbanana-Board-Old board.

over to you Anthony!

@ABorbaWMF - this would require going through all the page previews test cases (they should now have relevant articles on cswiki)

IPA not always removed (https://cs.wikipedia.org/wiki/Geometrie, hover over Jánosem Bolyaiem

This is by design. We don't scrub any content inside square brackets and we do not scrub parenthetical with one word. This would need to be marked up on wiki with the desired behaviour.

fading with mathematical formulas can be confusing (for example, go to https://cs.wikipedia.org/wiki/Geometrie, hover over algebraických variet
longer formulas not appearing correctly (https://cs.wikipedia.org/wiki/Geometrie, hover over polynomu)

We should open tickets for these and put them in the design backlog. We cannot change the preview content but we can change the presentation.

@ovasileva - T182321#3992796 is an example of an edge case or a bug? The preview should probably not accept css definitions designed for the normal article text. The above mentioned gadget may not be the only one that will influence the preview.

that should be fixed in the gadget. The styling introduced by said gadget is very generic. Vachovec1 would you be so kind to flag that to the gadget author(s)?

Well, the gadget definition is here:

MediaWiki:Gadget-HighlightRedirects.css

It's actualy very simple/basic code. So what would you propose?

The en-wiki has something very similar:

MediaWiki:Gadget-DisambiguationLinks.css (author: @kaldari)

I presume that the behaviour would be the same.

@ovasileva - T182321#3992796 is an example of an edge case or a bug? The preview should probably not accept css definitions designed for the normal article text. The above mentioned gadget may not be the only one that will influence the preview.

that should be fixed in the gadget. The styling introduced by said gadget is very generic. Vachovec1 would you be so kind to flag that to the gadget author(s)?

Well, the gadget definition is here:

MediaWiki:Gadget-HighlightRedirects.css

It's actualy very simple/basic code. So what would you propose?

The en-wiki has something very similar:

MediaWiki:Gadget-DisambiguationLinks.css (author: @kaldari)

I presume that the behaviour would be the same.

This conversation continues in T188005.

Looks good so far for me. Here are some examples with different previews (images, math, bold, parens, etc) on different os/browsers:

image.png (768×1 px, 427 KB)

image.png (768×1 px, 606 KB)

image.png (768×1 px, 412 KB)

image.png (768×1 px, 226 KB)

Screen Shot 2018-02-23 at 8.45.07 AM.png (1×2 px, 2 MB)

Screen Shot 2018-02-23 at 9.06.47 AM.png (1×2 px, 1 MB)

Screen Shot 2018-02-23 at 9.07.33 AM.png (1×2 px, 2 MB)

Screen Shot 2018-02-23 at 8.56.30 AM.png (1×2 px, 1 MB)

Screen Shot 2018-02-23 at 8.56.55 AM.png (1×2 px, 1 MB)

Screen Shot 2018-02-23 at 8.35.12 AM.png (1×2 px, 1 MB)

I have some reservations about the "fading" logic. Look at the following previews:

Previews 001.jpg (446×687 px, 130 KB)

Previews 002.jpg (418×653 px, 97 KB)

Notice the fading. This is not good. The fading should definitely not be applied to the first line of the text. Another thing: it would be great if the fading would not be applied to the last word of the sentence.

A remark: this happens mostly for the previews without the picture or with the "horizontal" picture. The previews with the "vertical" picture have usually much more room for the text before the "fading" is applied, so the short text summaries are usually presented as whole, without fading.

I agree, the first sentence should not fade like this in the middle of the object:

"Jonathan Kuck is figure ska..."
"Brian Hansen is figure skat..."
(skater? skateboarder?)

The fading should definitely not be applied to the first line of the text

We could potentially define "min-height" to content to 40px to solve for this particular case. if you apply 40px as a min-height, it won't apply the fading to the first line. I find this way a bit unreliable and of course I will speak with an engineer to figure out what is the downside.

No new bugs observed - resolving this for now. Logged the issue with longer formulas (T188734), although I'm not sure we can do much about it. All else looks good!

@ovasileva And T188581, but all the original issues were solved by HTML summaries, so this task is resolved

@ovasileva And T188581, but all the original issues were solved by HTML summaries, so this task is resolved

yes, that's the other one. Thanks @Dvorapa, @Vachovec1 and everyone else for all your help with QA