completely outside of the "mobile user" UX here, if this was contained to mobile most of this discussion wouldn't be ongoing.

Per T230657#5438248 maybe we want to decline this and document the decision?

Nick will take a look

I will add some QA steps.

And the QA steps 1&2 appear to contradict:

Thanks for pointing this out. The URL was correct but not the link label.

This is now provided. A skin should make use of the ResourceLoaderSkinModule class and define the set of features it wants to include.
We can create specific tasks for pulling out the remaining baggage, but that's for another task :)

This is now done. The mediawiki.skinning.interface module is now an instance of ResourceLoaderSkinModule::class - any extension or skin (although I heavily recommend the latter) is now able to define it's own module with the ResourceLoaderSkinModule class and pick and choose which "features" it wants to support.

cc Growth team

I've tested https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/549919 pretty extensively and I'm pretty sure this covers all the edge cases we've highlighted. I've updated the QA steps and have been relying on these to confirm the new patch works as expected - please let me know if any edge cases are missing from those QA steps.

In T233649#5649829, @Nikerabbit wrote:

In T233649#5648517, @Jdlrobson wrote:

@matmarex I can't find where you said this but I noticed your comment (whereever it was!) about semicolon-separator in some cases having an extraneous trailing space. I think having the space in the message is a symptom of bad separation between the presentation and content.

What there is presentation? Japanese and Chinese don't use space after (full-width) semicolon, and French seems to want space also before: https://translatewiki.net/wiki/Special:Translations?message=Semicolon-separator&namespace=8

We'll need to run through the QA again once this latest patch has been merged so I've unchecked the boxes in the description.

@matmarex I can't where you said this but I noticed your comment about semicolon-separator in some cases having an extraneous trailing space. I think having the space in the message is a symptom of bad separation between the presentation and content.
Special:LinksHere seems to be the only other user of the semicolon-separator. I'd like this page to also use pseudo elements in future, so I think the extraneous space needs to be removed in translations rather than from the CSS. It should not be part of this message.

@Dvorapa I only see one semicolon on the history page but your bug report suggests there may be more than one per row. Can you confirm that your bug report is identical to T237705 ?

Im actually on the bus home and am finished for the day. I will check in on this tomorrow but I wanted to make sure the conversation stayed centralised to this ticket.

I guess we should qa the specific problems in the above bugs too but let's not have multiple bugs for the same issue.

See qa in https://phabricator.wikimedia.org/T237500
I think we just need to verify no semicolon on mobile

Thank you so much for the QA and the swat @Zoranzoki21

In T233649#5646548, @Huji wrote:

Instead of using a hardcoded semi colon, let's use
.mw-title:after { content: '; '; }

Let's not! There was a reason the original code was calling $this->message['semicolon-separator']: not every language uses the same semicolon as Latin-script languages like English (e.g. compare ; for English versus ؛ for Persian). I think this change needs to be redone or undone.

I hadn't clicked that was an actually a message because it's non-standard use of message display. New patch fixes it. In mean time you'll need to ship a site style to translate that.

The issue with the notifications menu is also happening on master, so I've spun out https://phabricator.wikimedia.org/T237677 to look at that separately. My initial guess is that it might relate to recent changes to the OverlayManager.

The client side check for this would be:

mw.config.get('wgPageContentModel') ==== "wikitext"

In PHP

$title->getContentModel()

The value for Flow is flow-board, but that doesn't matter as we'd only ever want to do this on wikitext pages.

@matmarex true - this probably could be moved into the show method for completeness - I think the reason it's not is that some Drawer's get added to the DOM and don't call the show method (ideally we are trying to get rid of the show method as part of https://phabricator.wikimedia.org/T214647 but I don't know if that will ever be prioritised :(

The code at fault is src/mobile.init/editor.js - @JTannerWMF let me know if this is editing team or web responsibility. Until then I'll assume the former.

Ok I can replicate here: https://wiki.lavinya.net/?useformat=mobile
but I can't seem to replicate locally with the same versions of MobileFrontend and Minerva :(

The web team doesn't really have the right expertise here to work on this :(.

Hmm I can't seem to replicate this issue. Does the issue occur in an incognito (private) browser window?

@nray @alexhollender seems relevant given our current work on talk pages
Compare https://en.wikipedia.org/wiki/Talk:Torridincolidae with https://en.m.wikipedia.org/wiki/Talk:Torridincolidae
Should we turn off the page issues code on talk pages so that the content is revealed when you click "read as wiki page? "

@nray @alexhollender seems relevant given our current sprint work.

Whoops. This overlay is still around - my bad :)

This overlay has been removed from the codebase.

This now looks fixed thanks to @nray work on T230695 so moving for QA

Per the plan to replace the need for this button in T151115 and remove beta (T237290) we will be removing this feature.

Per the plan to replace the need for this button in T151115 and remove beta (T237290) we will be removing this feature.

Per the plan to replace the need for this button in T151115 and remove beta (T237290) we will be removing this feature.

Is this a third party wiki or a wikimedia-hosted wiki? it looks like the mediawiki instance might be running incompatible Minerva and MobileFrontend versions. Is there a public URI you can share?

That did it! Thanks!

In T191706#5566720, @Masumrezarock100 wrote:

@alexhollender The button is destructive, and primary or just only destructive. I am fine with either way. The design looks good. But as a mobile user, a lazy one at that, I don't wish to go through a confirmation screen like in the desktop version to undo a diff. Are you planning to make it automatic?

Okay, I got this. I was misunderstanding your bug report. I thought you were talking about a different element on the page.