Page MenuHomePhabricator

Page issues: Simplify class selectors we support to provide more sustainable support for severity parsing
Closed, ResolvedPublic3 Story Points

Description

Per https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis#Use_supported_ambox_classes_to_clarify_severity we should provide an easy way for editors to register severities on templates and opt-into Minerva's issue code. This will allow us as part of deployment to engage community to address these problems.

Right now our code does this sort of thing:

			LOW: /ambox-style|avviso-stile/, // en, it
			MEDIUM: /ambox-content|avviso-contenuto/, // en, it
			HIGH: /ambox-speedy|ambox-delete|ambox-serious|avviso-importante/ // en, en, es / ru, it
			// ..And everything else that doesn't match should be considered DEFAULT.

Having different classes for every language is unsustainable, in particular when used like this:

POINT_OF_VIEW: new RegExp( [ // en
				'ambox-Advert',
				'ambox-autobiography',
				'ambox-believerpov',
				'ambox-COI',
				'ambox-coverage',
				'ambox-criticism',
				'ambox-fanpov',
				'ambox-fringe-theories',
				'ambox-geographical-imbalance',
				'ambox-globalize',
				'ambox-npov-language',
				'ambox-POV',
				'ambox-pseudo',
				'ambox-systemic-bias',
				'ambox-unbalanced',
				'ambox-usgovtpov'

so I suggest we provide some opt in classes

We should aim to simplify the regexs inside pageIssuesParser.

Right now we recommend the following classes. While these provide editors a way to opt in, the classes don't really make sense for what we're using them for and it's not clear at all they are needed for mobile.

Purpose	Class to use
POINT_OF_VIEW	ambox-POV
MOVE/MERGE	ambox-move
Medium severity issue	ambox-content
High severity issue	ambox-serious
Low severity issue	ambox-style

These recommended class should be more neutral and descriptive and look like this:

Purpose	Class to use
POINT_OF_VIEW	mobile-issue-pov
MOVE/MERGE	mobile-issue-move
Medium severity issue	mobile-issue-severity-medium
High severity issue	mobile-issue-severity-high
Low severity issue	mobile-issue-severity-low

Acceptance criteria

  • mobile-issue-pov, mobile-issue-move, mobile-issue-severity-medium, mobile-issue-severity-high and mobile-issue-severity-low are all recognised class names

QA steps

Visit https://en.m.wikipedia.beta.wmflabs.org/w/index.php?title=T206177 and make sure all the icons show as expected in all the linked pages.

Sign off step

Event Timeline

Jdlrobson triaged this task as Normal priority.Oct 3 2018, 10:20 PM
Jdlrobson created this task.
Jdlrobson moved this task from Incoming to Triaged but Future on the Readers-Web-Backlog board.
phuedx removed a subscriber: phuedx.Oct 4 2018, 10:34 AM
Quiddity removed a subscriber: Quiddity.Oct 4 2018, 10:35 PM
Jdlrobson renamed this task from Provide more sustainable support for severity to Page issues: Provide more sustainable support for severity.Oct 5 2018, 5:48 PM

To help estimate this more accurately it has been requested that there are more concrete details of the approach.

Jdlrobson renamed this task from Page issues: Provide more sustainable support for severity to Page issues: Provide more sustainable support for severity (simply pageIssuesParser code).Oct 10 2018, 10:07 PM

Right now I'm struggling to flesh this out.
Most of the code in page issues seems to relate to T206178
After that, this task seems the most important focus area. We should re-evaluate the code here. From what I understand the main bulk of this code relates to screen scraping page issues and trying to work out an icon to replace the community provided icon.

In essence, we are incurring an awful lot of tech debt to turn


into

or


into

@ovasileva @alexhollender this code is coming at an unacceptable maintenance cost that we will either need to resolve or remove. How attached are we to this, and might we reconsider our approach here to use the community provided icons (or not show icons at all)?

What I would prefer to do is work with template editors (or us in that role) with a mechanism to specify a mobile friendly icon. A case can be made that these community-generated icons are not good at this resolution as a motivating factor.

What is the problem we want to solve here using these icons?

I had a lovely chat with @alexhollender today and we agreed to find a way to keep the icons.
I'm gonna chew on this some more about a way we can make template changes to support these mobile icons.

Jdlrobson renamed this task from Page issues: Provide more sustainable support for severity (simply pageIssuesParser code) to Page issues: Simplify class selectors we support to provide more sustainable support for severity parsing.Nov 12 2018, 10:25 PM
Jdlrobson updated the task description. (Show Details)

New description reflects my recommendation going forward, based on the fact we want to wrap up this work as quickly as possible.

Jdlrobson updated the task description. (Show Details)Nov 12 2018, 10:26 PM
Jdlrobson updated the task description. (Show Details)
Nirmos removed a subscriber: Nirmos.Nov 12 2018, 10:46 PM
ovasileva raised the priority of this task from Normal to High.Nov 13 2018, 12:09 AM
ovasileva moved this task from Triaged but Future to Upcoming on the Readers-Web-Backlog board.
Elitre removed a subscriber: Elitre.Nov 13 2018, 1:41 PM
Dvorapa added a comment.EditedNov 13 2018, 11:05 PM

First I'd like to mention Czech Wikipedia (and some other Czech projects, which adopted ours) system:

Articles (base: "labelced labelced-page"):

  • High: labelced-speedy, labelced-delete
  • Medium: labelced-content, labelced-move
  • Low: labelced-protection, labelced-notice, labelced-maintenance

Talks (base: "labelced labelced-talk"):

  • High: labelced-featured
  • Medium: labelced-noticed
  • Low: labelced-protected

other classes: labelced-image, labelced-message, labelced-note_text...

OK. From my point of view I can think of multiple possibilities:

  1. TemplateData maps (that's how Citoid does)
  2. MediaWiki JSON messages (that's how Citoid here and there does too)
  3. any prefix, but standardized suffix: languages could define their prefixes (ambox, labelced, avviso), but the suffix would be standardized (*-content, *-speedy, *-image). CSS would then work like [class$=-content], with a little bit of JavaScript like "anything>anything-content"
  4. fully standardized with mw- prefix: mw-box-content or mw-banner-speedy or mw-notice-image
  5. a combination of two or more

If standardized, I would suggest to follow BEM CSS conventions or similar.

Jdlrobson removed Jdlrobson as the assignee of this task.Nov 20 2018, 5:17 PM
Jdlrobson updated the task description. (Show Details)
ovasileva set the point value for this task to 5.Nov 20 2018, 5:25 PM
ovasileva changed the point value for this task from 5 to 3.

Change 476169 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Provide some recommended (opt-in classes) for projects not opted into page issues

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

Change 476169 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Provide some recommended (opt-in classes) for projects not opted into page issues

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

phuedx added a comment.EditedNov 29 2018, 6:12 PM
Priority/IssueActual
High
Low
Medium
Move
POV
Jdlrobson assigned this task to phuedx.Nov 29 2018, 7:04 PM
Jdlrobson added a subscriber: phuedx.

^ @phuedx I'm going to assume that is you QAing? Ready for sign off?

phuedx removed phuedx as the assignee of this task.Nov 30 2018, 12:11 PM
Dvorapa added a comment.EditedDec 2 2018, 6:40 PM

First I'd like to mention Czech Wikipedia (and some other Czech projects, which adopted ours) system:
Articles (base: "labelced labelced-page"):

  • High: labelced-speedy, labelced-delete
  • Medium: labelced-content, labelced-move
  • Low: labelced-protection, labelced-notice, labelced-maintenance

Talks (base: "labelced labelced-talk"):

  • High: labelced-featured
  • Medium: labelced-noticed
  • Low: labelced-protected

other classes: labelced-image, labelced-message, labelced-note_text...

Ahh, it was already said in T201975: Make page issue and hatnote classes names configurable so we are not English-Wikipedia centric

Dvorapa added a comment.EditedDec 2 2018, 6:42 PM

Both tasks seem to handle the same issue, but provide different solutions. Both should be merged as one issue to find a consensus on a solution.

ovasileva reopened this task as Open.Dec 3 2018, 10:33 AM

I think it should be the other way around. Merging T201975: Make page issue and hatnote classes names configurable so we are not English-Wikipedia centric into this and resolving.

Dvorapa added a comment.EditedDec 3 2018, 10:47 AM

@ovasileva Is it solved also for hatnotes?

(and what exactly is the solution?)