In mobile/desktop mode, when previewing or saving an edit, we have the opportunity to flag problems to the user. For example when editing pages in the Schema namespace errors are shown in both mobile and desktop that prevent saving:
{F24390465}
{F24390471}
I'm assuming that it should be possible to "warn" against certain problems and surface these warnings in previews and upon saving (with an override button"). If, so we could flag mobile issues to editors at time of editing
= Strawman proposal
The [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/transforms/IMobileTransform.php | IMobileTransform class ]] would have a method doesApply that takes a DOMElement and returns a boolean expressing whether the transform applies
On every edit we would run MobileFormatter::checkContent( htmlstring ) where htmlstring corresponds to the parsed wikitext that is about to be saved.
This method would run certain MobileFormatter transforms with the purpose to identify issues with wiki content.
To start with we'll focus on the LegacyMainPageTransform which will only run on edits to the main page to facilitate implementation of T32405. This will also allow us to measure the impact of doing this on every edit.
When previewing an edit for the main page, if the legacy main page transform, is needed it will render an error like so:
{F24390536}
A link will be provided to read more.
If this proves successful we can expand this for other purposes (see below).
Thank you for @TheDJ for the poke which reminded me to make this task.
= Possible transforms
* When an infobox appears before a lead paragraph we can guide editors to reposition it
* When page issues are not using the "fix" parameter, report a problem e.g. T197047,T197049,T197048
* When page issues are using long issues and truncation we are doing in T197931 is likely to impact readability - flag that to the editor.
* When multiple page issues are present on a page and are not wrapped in a "multipleissues" template, we can instruct editors to fix this
*When certain inline styles are used e.g. width or float that are known to cause problems in mobile we can flag them
* When certain elements are larger than the available viewport (e.g. T160946) we could flag this to editors, rather than rely on ad-hoc app reports (note this issue is extremely common)
* One we have a framework in place we can add various other use cases from https://phabricator.wikimedia.org/project/view/1682/
= Possible iterations on this idea
# When an article has issues that an editor doesn't fix we could store that information as a page property to allow editors to discover problematic articles and fix them.
# If a page has a problem, the mobile site could render an automatically generated page issue "This page may not be mobile friendly".
= Downsides
* This will increase the time it takes to preview an edit. If this proves to be problematic, this could be run at request of an editor e.g. not on every edit, but via a specific button in the editor or be opt-in via Special:Preferences.
We could also run the test as part of the existing render, storing the result as a page property. The warning would then become "This page was recently reported to have a mobile issue" rather than "This page has a mobile issue".
* Note: the transform would run for all transcluded templates so in some cases it might not be clear where in the page the problem is. For instance, the Barack Obama article may report an error for a Template that it uses rather than an issue with the article itself
* Some changes may be too technical for some users. We thus might want to limit certain messages to users with the TemplateEditor user group or use an opt in user preference.
* Certain issues are so common (e.g. Template:Navbox not being mobile friendly) it doesn't make sense to render the issue on every edit. We'll need a way to limit issues to constructive and actionable use cases or to scope those problems to the template itself.