I've applied the naming convention of the classes for infobox, ambox and hatnotes (found in the page you mentioned) and it seems that the output has been now uniformed. Thanks!

@Jdlrobson also https://it.m.wikivoyage.org/wiki/Hammerfest has the same content but it doesn't cause that issue. Do you know why?

@Jdlrobson assuming that this behavior is desired, it doesn't work on articles like https://it.m.wikivoyage.org/wiki/Norvegia

@TheDJ any idea on who should be pinged to highlight properly this issue?

Looking at the wiki-text, it's the very first sentence after the infobox and before the first section.
In desktop view is show correctly in its position, but in mobile view of https://it.m.wikivoyage.org/wiki/Hammerfest is shown before the infobox, instead of being shown after it.

Thanks @TheDJ, your patch solved one part of the issue (the title inside the infobox), however there is still an issue on https://it.m.wikivoyage.org/wiki/Hammerfest: the incipit is shown before the infobox instead of after it, as it happens on the desktop view (i.e. https://it.wikivoyage.org/wiki/Hammerfest) or in another mobile view article like https://it.m.wikivoyage.org/wiki/Norvegia that use a QuickbarCountry in place of QuickbarCity.

@Jdlrobson I've taken a look but I don't understand why https://it.m.wikivoyage.org/wiki/Norvegia (that use QuickbarCountry) looks good while https://it.m.wikivoyage.org/wiki/Hammerfest (that use QuickbarCity) don't.

@TheDJ do you know who can support?

In T297443#7626783, @ssastry wrote:

In T297443#7625213, @Andyrom75 wrote:

I still see thousands lint errors on https://it.wikivoyage.org/wiki/Speciale:LintErrors/inline-media-caption; is it normal?

The fixes that revert this haven't yet rolled out into production. They will ride this week's train and these will then gradually clear out.

I still see thousands lint errors on https://it.wikivoyage.org/wiki/Speciale:LintErrors/inline-media-caption; is it normal?

Thanks @Izno, just done.

This morning I've found this new lint error category: https://it.wikivoyage.org/wiki/Speciale:LintErrors/inline-media-caption
but honestly I haven't understood the issue in most of the cases. If I show a File: without thumb/right/left the image, its link and its caption are rendered inside a SPAN so it's fine to show them inline.
But if I use thumb/right/left the same image is rendered inside a DIV so I can understand where the issue is and I know how to solve it.
Any comment?

Thanks again @Ladsgroup.
This morning I've found this new lint error category: https://it.wikivoyage.org/wiki/Speciale:LintErrors/inline-media-caption
but honestly I haven't understood the issue in most of the cases. If I show a File: without thumb/right/left the image, its link and its caption are rendered inside a SPAN so it's fine to show them inline.
But if I use thumb/right/left the same image is rendered inside a DIV so I can understand where the issue is and I know how to solve it.
Any suggestion?

Thanks @Ladsgroup, it seems that the statistics now are almost perfect!

@Jdlrobson any update?

@Sbailey since I got this issue on 3 pages of https://it.wikivoyage.org/wiki/Speciale:LintErrors, I was wondering if there's a way to force the refresh of the counters. Consider that 2 page counters out of 3, are stuck since a couple of week (+ or -). All of them should be zero.

@Jdlrobson I've started two discussions:

• it:voy: https://it.wikivoyage.org/wiki/Wikivoyage:Lounge#Argomenti_correlati_e_spazio_vuoto_nella_parte_inferiore_degli_articoli
• en:voy: https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Related_topics_%26_empty_space_in_articles_bottom

In both cases there is no objections on proceeding.

@Jdlrobson so if I'm understanding it correctly, by default it will be shown certain article bases on "similar text", is it right?

@Jdlrobson unfortunately I'm not enough expert to fully understand the implication of such configuration change, however, if you think that passing from "no API" to "API" will solve the issue and all the pages with 1 or more related articles, will keep on showing them (hence no side effect), well, yes, let's change the configuration for the whole project.

@Jdlrobson I've taken a look at the code you highlighted.
Although I'm not able to put my hands on that I have few questions:

1. Is that code only for Wikivoyage or for any wiki-project?
2. If only for Wikivoyage, does make sense to put the line $data .= \Html::element( 'div', [ 'class' => 'read-more-container' ] ); inside into an if-block where the condition is the presence of at least one related page? I suppose that $relatedPages[] at line 182 could help

@Jdlrobson it seems that the patch works!

@Jdlrobson actually some pages use the "related features", like https://en.wikivoyage.org/wiki/Hawaii_Volcanoes_National_Park, but it seems that this mechanism is buggy.
If I reload that page whan I'm at the bottom I'll see the empty space, but if I pgup + pgdown, that spaces is filled with the related article. It's a kind of magic :-D

In T296374#7540013, @SHB2000 wrote:

@Aklapper I've improved the description provided by @SHB2000, check if you can see the issue now.

@cscott as per @Jdlrobson request, I've added you on this ticket to check the issue during his two weeks absence. Thanks in advance for your support.

@Jdlrobson just opened T295632 as requested. If you can, give a quick look to be sure that as been correctly opened.

@Jdlrobson I've noticed another strange behavior. As previously mentioned, when visualizing an article everything is fine now, but during the preview the standard TOC is still visible. This is quite annoying because "what we see is NOT what we get" after publishing the content.
Do you want me to open another ticket or can this bug managed here with the same ticket?

@Aklapper thanks for your suggestion but I'm only "skilled" on client side JQuery/JS not server side, hence I'm not able to elaborate the @Tgr's input

@Jdlrobson you can successfully close this ticket. Thanks a lot for your quick support!

Thanks @Jdlrobson! I've removed the patch several hours ago on it:voy and checked now to avoid cache issues; all works correctly. I've just removed the patch in en:voy and asked fr:voy & ru:voy to do the same. Without comments from their side I would say that we can close the ticket within tomorrow.

@Jdlrobson since recently someone (successfully) worked on the WikidataPageBanner (T295003), could be the right time to ask to try to solve also this issue?

@Jdlrobson is not possible to use the suggested CSS on MediaWiki:Common.css because it will affect ALL the pages, not only the ones that use the banner. That's why, the applied temporary patch use a dynamic JS that looks first for the ext-wpb-pagebanner class, introduced by the extension.
As well is not possible to use __NOTOC__ because it will hide also the custom banner menu (the one that replace the standard TOC)

@SHB2000 see my clarification above

@Aklapper This one: https://www.mediawiki.org/wiki/Extension:WikidataPageBanner

@Omondi , @Aklapper ,
the issue is on the pagebanner extension.
The reason why you didn't see it:

• on fr:voy is just because of cache. Now I've purged the page and you can see it
• on pl:voy is because they DON'T use the extension, so pl:voy is not affected.

https://en.wikivoyage.org/w/index.php?title=Main_Page&action=credits is an empty page while in april 2021 its content is visible in this archived page https://web.archive.org/web/20210414182218/https://en.wikivoyage.org/w/index.php?title=Main_Page&action=credits

@Tgr, thanks for your reply. If I understand correctly, the only way to format a SiteNotice (not a CentralNotice) is to change MediaWiki:Common.css (and/or MediaWiki:Mobile.css I suppose) all the time I need a specific style, because the .css configuration files will affect all the sitenotice (not just some as I need). Is it correct?

@Tgr answer to question 1 is clear, but I haven't understood how to solve the problem asked with the second question.
Could you provide me few links or write here some practical examples?

@bd808 Great job! Now the whole site works!

Thanks @matmarex, I think it's enough. At least, in the unlikely case that it would happen again, we know where to look.

No problem @Aklapper , for completeness, also IE works fine now.
As said above, it would have been good to know what fixed the problem, to avoid the same issue in the future, or at least to fix it in less time.

All the three browsers I've previously mentioned worked correctly, so it's not a matter of their improvement, but a WMF patch has been delivered.
I was curious to know what solved the problem before closing the ticket.

I've test it on it:voy, en:voy, it:w and en:w and now It seems that the issue has been solved.

@matmarex I don't know if it can help with the debug, but I've noticed this different behavior in the following two situations:

This problem affect ALL wikis, I'll be glad to support on debugging, I just @matmarex feedback on how to test "a version + a set of patch" to find the one that caused the problem.

@matmarex AFAYK there is an easy way (e.g. web interface) to test a specific version with/without certain patches? I'll be glad to spend time on trying to find which is the patch that causes this problem to save your debug time, because editing an article in this way is very annoying. Once found, clearly I need someone else support to fix it :-)

sob...
I've looked into https://www.mediawiki.org/wiki/MediaWiki_1.36/wmf.1 more for curiosity than for expertise.
May CodeEditor or WikiEditor repository affect CharInsert? My guess is because I experience the problem during edit phase.

@matmarex thanks for your high level screeening. Unfortunately I'm not able to support you on debugging, so I just limit myself to share one consideration.

According to https://www.mediawiki.org/wiki/Editing_team you (@Whatamidoing-WMF , @JTannerWMF, @MFlorence, @Esanders, @iamjessklein, @Ryasmeen, @dchan, @DLynch, @matmarex, @Mvolz, @MNeisler, @ppelberg ) are the team in charge of CharInsert tool.
I'm disturbing you since I've seen in the https://www.mediawiki.org/wiki/Developers/Maintainers page that there is no maintainers associated to CharInsert.

@Aklapper it's a feature request.

On Italian Wikivoyage it still doesn't work: https://it.m.wikivoyage.org/w/index.php?title=Speciale:UltimeModifiche

@Aklapper could you help me to find out who works recently on Charinsert? Maybe they can check this out easier than other users.

@Aklapper this task still needs triage, could you support?

The issue occurs also with Safari on smartphone (I'm not able to determine its version)

You are right, but my point is another. If all the three major browsers experience suddenly the same issue, maybe the version is not relevant, and the bug has been introduced in a recent code update.
Furthermore, since it affects ALL the wikis in ALL the languages, I hope that someone would start working on it soon before any browser version would change ;-)
By the way:

• Chrome 85.0.4183.102
• Firefox 80.0.1
• IE 11.508.19041.0

Today, all is fine. I would consider this issue closed and solved.

~15min ago connection has been restored. I'll test it again tomorrow.

The lastest

In T262869#6460813, @CDanis wrote:

Today we had reports of an issue from @Andyrom75 that was happening all the time on their Wind (AS1267) mobile connection, and was happening under some circumstances on their Vodafone (AS30722) connection, but we did not get a full traceroute or an IP address, so it's very hard to say what was going on or if the issue was related.

Inside the mentioned page, I've added a case that show where the parser has inserted the second row outside the LI tag creating a layout issue and the graphical fix will generate a lint error.

@Jdlrobson, @Tacsipacsi referring to one of the previous discussed point about title area space, I would highlight how in en:wp has been managed:
https://en.m.wikipedia.org/wiki/Taumatawhakatangi­hangakoauauotamatea­turipukakapikimaunga­horonukupokaiwhen­uakitanatahu
(it dinamically adjust the horizontal leght of the title according to the actual size of the screen)