Thanks for caring about this. I was a little worried about how this task might be reacted to so thank you :)
@VolkerE code is here: https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/resources/mobile.editor.common/EditorOverlayBase.js#L313 and it's using the default OO ui widget. I'd argue the defaults should be sensible and in line with our palette. I'd hate to decide further down the line they should all be purple and have to update in say 10 places the color.
I've put this patch on staging per request from @alexhollender and putting in design review.
Minor follow up in https://gerrit.wikimedia.org/r/425570 needs to be merged. Once that's done we can move this to QA.
Over to you @ABorbaWMF !
Note testing should happen on the beta cluster, but as well as https://en.m.wikipedia.beta.wmflabs.org/wiki/Spain you will also need to test on the wikivoyage version of the beta cluster (https://en.m.wikivoyage.beta.wmflabs.org/wiki/Spain) - testing steps should be concise but let me know if anything is not clear.
We tried to estimate this and landed on 8, 13s and 20s. There's a lot of work and risk here. Recommend setting up a specific meeting or repurpose a grooming specifically to talk through the data. I'll update the task folding in the answers to the open questions.
We'll split out the removal of the A/B testing code and the instrumentation code. We are still undecided about the latter.
The fact the lead paragraph of Holy Roman Empire and thus the summary is short is the problem here (. cc @Nirzar ). Note increasing the size of the summary is not really an option as it won't help pages where the lead section only contains one lead paragraph.
@Anome it's fragile in the sense that any client that is not MediaWiki needs to know and workaround this. MediaWiki is not the only thing that displays our content.
I don't know enough about screen readers to know if that's a problem or not, but I see several options here:
- Move rotation onto the pseudo before element like we do for mf-mw-ui-icon-rotate-anti-clockwise
- Adapt icon so that it can be rotated a denomination of 90 degrees. A 90 degree rotated icon will still appear like a box unlike a 72 degree one.
There's an older card with more conversation on this that was opened just after the release of lazy loading images. Let's keep the conversation there.
Options here would be:
- make the sure the mouse is at standstill when showing the popup
- move the popup with the mouse (potentially tricky due to the different rendering rules we have)
- do nothing
This should be fixed on wiki.
The fact that [[:en]] resolves to the English Main page is very brittle and we shouldn't work around such things in our code.
I don't understand why this is a bug.
We rotate the watchstar 72deg when watched via css transform, hence that's why the focus state gets rotated and the visual effect is correct.
This is actually a user script https://en.wikivoyage.org/wiki/MediaWiki:Common.js working around T113642
Could the feature be enabled at other projects on links towards wikipedias (e.g. Wikidata, but only for interwiki links, wikivoyage, but only for [[w: ]] links, etc.? That should be easier than making summaries work for other types of content (I am just guessing)?
I don't see any technical reasons why "intrawiki links" would not be possible, however I believe we would need to parse the href of every link on hover to determine which wiki it belongs to. However, this would require additional config and code complexity to disable the normal links case while the summary endpoint was missing.
Mon, Apr 23
Thanks for flagging @Tbayer!
@alexhollender I think this can skip QA but I wanted to give you the opportunity to verify this is fixed: http://reading-web-staging.wmflabs.org/w/index.php?title=Barack_Obama&mobileaction=toggle_view_mobile and that we haven't broken anything relating to image styling. Be sure to test with JS disabled and enabled.
^ @ovasileva let's talk about this when you get back.
@hashar Can those messages accept HTML/emojis/wikitext?
I think dropping the sad face would be a good start.
I think everyone knows that this would involve some work, but it has been my assumption that it would be orders of magnitude less effort than coding a new instrumentation usually requires. Does that sound plausible?
We have git history now, so restoring the current setup will be a lot easier than writing from scratch, yes, but I wanted to make clear that we should expect getting it up and running again to not be trivial regardless of whether we keep it or not - maybe 2-4 weeks. It sounds like that's clear so we're good.
I walked @Mooeypoo through this.
Apparently the existing view does not look strange or broken from an i18n perspective and she wouldn't have noticed there was any problem had we not raised it. It only becomes broken when you know how English Wikipedia looks and thus from a consistency purpose. Moriel points out that it's only broken from a design perspective if @Nirzar has decided it is extremely important for the summary to appear before the image.
@demon there will be less data stored on the short term but on the long term, only activating this for new accounts is going to lead to a magnitude more rows in the database, so I strongly recommend we find some way to do "b".
We notice the screen pops back into place when content near "Post-presidency (2017–present)" loads so probably a local wiki issue.
Piotr to provide guidance on the PHPy bits.
@ovasileva we originally estimated this as a 1 but after looking into this it's turned out to be a lot more complicated and risky as the rendering code still predates the rewrite and doesn't make this easy. We feel we'll need to rewrite the entire rendering code here (a 8 pointer potentially) @Jdrewniak will create a task/link tasks relating to the problem here about what needs to be done. I'm going to thus throw this back into the backlog for further analysis.
@alexhollender will sign off.
Fri, Apr 20
This is in the ooui library i believe.
I'd day yes. It's a depreciating asset if it's not deployed.
I have ticked the last box "Subtasks should be resolved." after reviewing the remaining 3 subtasks.
^ Twitter went a bit crazy so we can consider that checkbox done :)
FYI although the main report is done, we're keeping this open so that Tilman can do some follow up analysis!
This is rolled out everywhere now so I am resolving. Let me know if any problems with that. https://phabricator.wikimedia.org/T192622 captures the remaining work here!