While en.wikipedia uses the "ambox" class to flag issues, the class name is not consistent across projects, meaning most projects will not benefit from the page issue warning work and that this project is very English-Wikpedia-centric (which is bad!).
For instance, cswiki, uses the class "labelced" defined inside:
https://cs.m.wikipedia.org/wiki/%C5%A0ablona:Neov%C4%9B%C5%99eno and ultimately Template:Cedule
Even more problematic, these boxes look like content on mobile and are confusing
- https://fr.wikipedia.org/wiki/%C3%8Ele_Taraba (https://fr.wikipedia.org/wiki/Mod%C3%A8le:%C3%89bauche)
With new treatment
The new treatment causes some changes to various wikis that may be unexpected but is not avoidable, due to the fact we have optimised for English Wikipedia
Works (but broken iconography)!
("Questa voce o sezione sugli argomenti giornalisti italiani e politici italiani non cita le fonti necessarie o quelle presenti sono insufficienti....")
<same as current treatment>
- Make any adjustments to the code that prevent us from writing guidelines
- Provide a set of guidelines explaining how wikis can opt into the new page issues templates
ResourceLoaderLessVarFileModule.php provides a way to pass less variables from messages. This could be utilised to define the selectors inside resources/skins.minerva.content.styles/templates/ambox.less allowing editors to configure them, themselves. We can also pass in LESS variables from config variables if message parsing is a little too scary.
If we followed this approach the .ambox selector and .mbox-text-span, mbox-image selectors would need configuration.
The PageIssues parser also needs to be configurable via resources/skins.minerva.scripts/pageIssueParser.js
The cswiki template is actually much more mature than the enwiki template (it uses divs rather than tables), so it seems backwards to recommend cswiki adopt the enwiki templates.
Configure the ambox class
At minimum we should make ambox class configurable, identify the classes they use on all projects and make sure they all get hidden/stripped on mobile if the mobile standard classes are not used. If things are broken users are more likely to fix them if we give them instructions.
Add generic class clues so templates can opt in as they wish
We'll need to provide guidance on how projects can opt into the mobile issues treatment - e.g. which classes are needed and what they should mark up (e.g. image, severity level, issue, fix) so that our page issue parser can read them.