Estimated at medium risk.

(medium is 3 apparently)

Change 625346 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Rewite MoveLeadParagraphTransform based on mobile apps approach

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

Test Result - Beta

Status: ✅ PASS
Environment: beta
OS: macOS Big Sur
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

✅ AC1: For the pages below verify that the lead paragraph is at the top of the page

Hooded Skunk	Albert Einstein	Ronald Reagan	Aleš_Kněžínek

Please see T277302 for a regression introduced by this change. I really wish that more wikis were used for testing changes like this one, and not just enwiki.

I will write a notice for T/N later if nobody beats me to it.

Change 672406 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/MobileFrontend@master] Reinstate "Rewite MoveLeadParagraphTransform based on mobile apps approach"

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

First of all, I've created the reverts on gerrit, so whenever this is ready to go it's just a CR+2 button to push.

As for Tech News (CC @Johan ?):

In two (?) weeks, there will be a change to how articles are displayed on mobile sites. The first paragraph of the article will be moved above the infobox templates. Some templates, like [[:en:Template:Hatnote|]] and derivatives of [[:en:Template:Ambox]] on the English Wikipedia, should stay at the top of the page. To make this work, ensure that the equivalent templates on your wiki are using the CSS class <code>hatnote</code> or <code>ambox</code>. A [https://w.wiki/35ur guide] is available. See [[:phab:T262093|]] for more.

It's probably unnecessary wordy, so it might need some trimming.

This has been reverted because of the new information provided in T277302.

I think we have a few options here

• Run a tech news post and reapply the change again in X days.
• Adjust the algorithm for the new edge cases and try again.
• Turn off the lead paragraph move feature on the impacted wikis (using the existing MFShowFirstParagraphBeforeInfobox config flag) . This could result in infoboxes at the top of the page but could be enabled later once the required mark up changes are there leaving it up to editors to opt into this
• Adjust the existing code to make classes like hatnote and infobox configurable, to allow editors to customize these special classes to their own understood language. e.g. instead of .hatnote the MobileFrontend code could be configured to look for .nota-disambigua

Discussed this yesterday during standup. Tentative next steps:

• Begin discussions with the community about the change - inform everyone via Tech News as well as reach out to a set of wikis directly to discuss preparation
• Create a list of wikis where this would break and exclude them from the changes
• Make a list of wikis that absolutely must be fixed

Once the above is in progress, we can set a date on when we would like to try this out again

Something like this for Tech News? Or do you need the editors or wikis to take any other action beyond making sure they use the right CSS class?

Articles on mobile will look different. The first paragraph will come before the infobox templates. Some templates will stay on top of the page. Two examples are [[<tvar|hatnote>:wikidata:Q5625128</>|Template:Hatnote]] or [[<tvar|ambox>:wikidata:Q5617634 | Template:Ambox ]]. They will need to use the CSS class <code>hatnote</code> or <code>ambox</code> on your wiki for this to work. You can [[<tvar|guide>:mw:Recommendations for mobile friendly articles on Wikimedia wikis#Use standardized class names in HTML markup for components in templates across projects</>|see a guide]] or [[<tvar|mobilephab>phab:T262093</> | read more]].

This assumes that the class names will remain like this, with all the styling issues that have been pointed out already. As already explained, I would have to use hatnote both for disambiguation notes and for message boxes on dewiki due to incompatibilities of the ambox class, which would not be in line with the logic of the linked recommendations.

So, before communicating anything about this, either the guide should be updated or the class names should be made customisable.

Do one thing, and do it well.

• Please use a class mw-page-position-top.
• That does say: This block shall be arranged before introduction section.
• Nothing more.

Those local ambox and hatnote and infobox are decoration classes. They define how this particular wiki is decorating things. That is not a statement on the exact position where to arrange it in a page.

• Structural global semantics are one thing.
• Local decoration is something different.

The ambox and hatnote are providing a particular decoration. They were never limited to certain structural declaration and effect on order of elements. Those are definitely the wrong class names to introduce a new capability. Nobody knows which templates in 1000 WMF wikis are equipped with such classes and which expectation and usage are supposed there.

In T262093#6924076, @Johan wrote:

Something like this for Tech News? Or do you need the editors or wikis to take any other action beyond making sure they use the right CSS class?

Articles on mobile will look different. The first paragraph will come before the infobox templates. Some templates will stay on top of the page. Two examples are [[<tvar|hatnote>:wikidata:Q5625128</>|Template:Hatnote]] or [[<tvar|ambox>:wikidata:Q5617634 | Template:Ambox ]]. They will need to use the CSS class <code>hatnote</code> or <code>ambox</code> on your wiki for this to work. You can [[<tvar|guide>:mw:Recommendations for mobile friendly articles on Wikimedia wikis#Use standardized class names in HTML markup for components in templates across projects</>|see a guide]] or [[<tvar|mobilephab>phab:T262093</> | read more]].

@Johan I'm not sure if the team wants to proceed this way. I wrote a proposal for T/N assuming that the change would be reimplemented in the same way, but this might not be the case if I'm correctly reading the messages above.

Yes, I didn't include it in the issue going out on Monday, awaiting more clarity in this task.

Change 672406 restored by Esanders:

[mediawiki/extensions/MobileFrontend@master] Reinstate "Rewite MoveLeadParagraphTransform based on mobile apps approach"

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

Talked about this one with Olga yesterday. We're still aware of it's existence, we just are waiting for a period of time where we are more focused on mobile site.

In T262093#6931777, @PerfektesChaos wrote:

Do one thing, and do it well.

• Please use a class mw-page-position-top.
• That does say: This block shall be arranged before introduction section.

This is how we would do it in an ideal world. In practice there are thousands of templates across hundreds of wikis that would need to be updated.

If this rewrites identifyInfoboxElement, please make the class name infobox configurable.

The French wiki hasn't been able to use this feature (and Mobile Page Issues, for the same reason ) because that class name causes problems there.
Other wikis may have the same issue, it's difficult to say which ones since unless I'm mistaken a way to track wikis which have implemented these new features doesn't exist yet.

In T262093#8039169, @The_RedBurn wrote:

If this rewrites identifyInfoboxElement, please make the class name infobox configurable.

The French wiki hasn't been able to use this feature (and Mobile Page Issues, for the same reason ) because that class name causes problems there.

The new approach should not care what class you use for the infobox.

@Esanders @The_RedBurn the infobox class is still important for various mobile optimizations so we do care about content being marked up in a machine readable way.

This prompted me to try and get this fixed: https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Questions_techniques/semaine_10_2024#Use_of_infobox_class so let's continue that discussion there.

@Esanders for changing how this works, the parser migration seems like a good opportunity to re-evaluate and dedicate time to doing this so I've marked this as a subtask!