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 [[ https://cs.wikipedia.org/wiki/%C5%A0ablona:Cedule | Template:Cedule ]]
Even more problematic, these boxes look like content on mobile and are confusing
{F24946459}
Examples:
* https://cs.m.wikipedia.org/wiki/V%C3%ADno
* https://cs.m.wikipedia.org/wiki/Slezsko
* https://fr.wikipedia.org/wiki/%C3%8Ele_Taraba (https://fr.wikipedia.org/wiki/Mod%C3%A8le:%C3%89bauche)
Find more examples:
https://cs.m.wikipedia.org/w/index.php?title=Speci%C3%A1ln%C3%AD:Co_odkazuje_na/%C5%A0ablona:Cedule&limit=500
= 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
French Wikipedia:
{F25203747}
CZ Wikipedia
{F25203776}
Spanish wiki
{F25203804}
== No change
German:
<same as current treatment>
{F25203793}
= Acceptance criteria
[] 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
= Developer notes
== Allow customisation
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.
See also:
https://m.mediawiki.org/wiki/Topic:Ueubfzql99uwvorl