In T425415#11889815, @Aklapper wrote:

Cannot reproduce when disabling Syntax Highlighting

@Jdlrobson, I experienced the same problem on ".skin-theme-clientpref-night .ns-100 .mw-parser-output :not(.notheme):not(a)"

@Jdlrobson, I'm not sure to have understood it.
The above "server side" CSS style is necessary and we should disabling it through the local MediaWiki:Wikimedia-styles-exclude page?

Since in 6 months I got no reply, I've changed completely the templates to solve the local issue, but I leave open the ticket to track it.

Checking the rendered code, I've noticed that Parsoid eliminate the symbol "#" from the color definition.
In this way, the CSS rule become invalid.

Same problem on https://en.wikivoyage.org/w/index.php?title=Special:LintErrors/night-mode-unaware-background-color
The real count is 18.370, while in https://en.wikivoyage.org/wiki/Special:LintErrors it show number that vary between 20.000 and 26.000 ... the number apparently changes randomly along each day.

Cleaning completed on https://it.wikivoyage.org/wiki/Speciale:LintErrors/duplicate-ids

After cleaning several occurrences on https://it.wikivoyage.org/wiki/Speciale:LintErrors/night-mode-unaware-background-color?limit=5000 now the counter shows correctly 1.234 lines.
Unfortunately, although the lines in https://it.wikivoyage.org/wiki/Speciale:LintErrors/duplicate-ids?limit=5000 are 2.022, the counter in the main page, still show "3.871 errors" that apparently is a number that doesn't make any sense.

The problem disappeared.
It could be interesting to track what has been changed or reverted to avoid the repetition of this issue.

FYI
Render bug seems to be solved on user page.

In an ideal world I agree with you :-)
The problem I see, is when (a minimum of) two un-experienced users work on the same page:

1. the first one, create the problem with the comment (...believe me is something quite common)
2. the second one, wants to to work on a specific section "as usual" but it's not possible because of that bug (...and the un-experienced user don't know where the problem is)

@Ammarpad in this specific case, the comment can be also removed, so it's not a matter to find a workaround, but to prevent that such comment, wrongly inserted by an user, can compromise the general usage of a page.

@JWheeler-WMF, since this bug affect ALL the wikis, are you sure that its priority shall be classified as "low"?

@JWheeler-WMF , I'm not skilled on video, so I've tried to do "something close to it" :-)

Ok, in this case I'm not able to support.
Thanks for your clarification.

In T361465#9686109, @TheDJ wrote:

Charinsert has a function that determines the last focused text input.

		$currentFocused = $( '#wpTextbox1' );
		// Apply to dynamically created textboxes as well as normal ones
		$( document ).on( 'focus', 'textarea, input:text', function () {

Clearly this does not get triggered when someone refocuses the syntaxhighlight area.

In the meanwhile I reopen the ticket to allow someone from SyntaxHighlight team to give a look

@Aklapper on Locating_broken_scripts is written that if the issue persist on safemode=1 I'm supposed to open a ticket here :-)

@Aklapper I've tried Firefox latest version on Windows and:

• If I'm logged I have the same issue
• if I'm NOT logger I don't have it

I suppose there's an issue with one gadget that suddenly create this issue.
In this case, which would be the best place for this support request?

@Aklapper, yes, in Wikipedia is "Under "Per inserire del testo tra questi segni selezionalo e clicca sul link:", while in Wikivoyage is next to "Inserisci:" and "Wiki markup:".

@Anoop I don't know how to reset my current default, but I've found the checkbox to set a new one. In a way or another I've solved my personal issue :-)
Now I see all the three NSs. Thanks

@Anoop, from the homepage, if I click on "Ricerca" (i.e. Search) button, I'll land to the page https://it.wikivoyage.org/w/index.php?search=&title=Speciale:Ricerca, and here, differently from your srceenshot, I can see only two NS pre-selected: "Template" and "Modulo". "(Principale)" (i.e. "(Main)") is missing.
Maybe is this the reason why I can't see "Firenze" within the search result.

Hi @Anoop,
I've noticed the following behaviors:

@Jdlrobson unfortunately also in en:voy there's the need for some user to show/use the TOC, so it's necessary to solve the bug server-side, restoring the previous behavior.
Thanks for contacting @cscott or whomever could be involved on its resolution.

@Anoop thanks for your support, NS:Portale (100) can be removed because is composed by old out-of-date content (not deleted only for historical reference)

@Aklapper , @Anoop , do you know if I should ping someone in particular to take in charge this task?

Thanks @Jdlrobson for mitigating the issue disabling the Listing Editor.

This will be managed locally

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 now that this behavior is desired, I don't understand why it doesn't work on articles like https://it.m.wikivoyage.org/wiki/Norvegia.
Apparently the only difference is on the "infobox template" QuickbarCountry Vs. QuickbarCity (both leverage on the same template and module).

@TheDJ any idea on who should be pinged to properly address 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.