Regarding the problem with point 1, the field author-link3 may appear when you FOCUS in author-link2, and author-link2 when you focus in author-link1, etc

Hi! I'd like to help but I'm not sure to what file I have to add the mediawiki-i18n-check-docker directive. Seems like YAML syntax but there're no YAML files in MediaWiki extensions. Would you mind explaining, or better yet submitting a patch for me to merge? Thanks!

In T121470#5638768, @Tgr wrote:

Without raw you get back a HTML blob rendered by a different parser, there is no end to the exciting bugs that could cause (local interface changes would get ignored, for example; links would be blue or red based on whether they exist on the templatecommons wiki). If you prefix all template names with raw:central_wiki_name, they won't work on the central wiki itself (I guess that would be not super hard to fix). It will also break cache invalidation and maybe performance, plus Parsoid would have to be updated to support it. Functionally, this is more or less what the shadow namespace proposal was aiming at (but it was a wishlist item and wasn't finished within the year, so I imagine there must be much more complexity to it than I can see at a glance).

I think that images in the lead section are closely correlated to images above the fold, especially considering that the table of contents usually pushes all other images below the fold. So, not lazy-loading images in the lead section is probably a good way to solve this issue!

The two paths to fix this I can think of are:

Any reason why this was never reviewed and merged? For what it's worth, I just reviewed it and added my +1, but a +2 is still needed.

I just sent a patch-for-review that enables @import for whitelisted domains. There was a comment in the code that said that @import was disabled for security reasons, but I couldn't find an explanation of the reasons, considering that @import rules only work for whitelisted domains. It may have been just a precaution with no specific reason, but now that there's at least some users (the supporters of the Wikitemplates project proposal) interested in that this feature is enabled, I trust that the patch can be merged and the feature enabled. Cheers!

Sorry, maybe I should have clarified: support for @import is documented at Extension:TemplateStyles (even though it doesn't work), but the external domains need to be explicitly whitelisted via $wgTemplateStylesAllowedUrls, so there's no security/copyright/reliability risk at all unless the wiki admin is willing to accept it. I just updated the task description to clarify this.

In T131516#2169424, @Nikerabbit wrote:

As far as I can predict, that markup is going to remain as long as wikitext is the primary format for content. [...] Once HTML content is better supported, we can consider using some heuristics to automatically detect translatable parts (with option for manual user invention where it goes wrong).

In T270377#8031707, @Sophivorus wrote:

Having this issue in a fresh 1.38.1, see https://wikivideos.org/wiki/Main_Page?veaction=edit
I also had it in 1.37 (updated to 1.38.1 hoping it would fix itself but didn't).
The issue doesn't occur on two 1.35 wikis I have on the same server (https://sophivorus.com and https://mediawiki.solutions)
I'm running PHP 7.4.12 and identical setup everywhere, AFAICT.
Page creation works fine, the issue happens only when editing existing pages.
Looking at https://wikivideos.org/info.php it's pretty clear I have php-bz2 php-zip php-bcmath php-gmp php-pspell php-tidy
But php-pear is disabled. It feels very unlikely this be the cause since my 1.35 wikis work fine without it but I'll report back when I manage to enable it.
Also I can't switch to PHP 8.1 to test if this fixes the issue, I'm afraid.

Hi! Yes I'm OK with this, thanks!

Having this issue in a fresh 1.38.1, see https://wikivideos.org/wiki/Main_Page?veaction=edit
I also had it in 1.37 (updated to 1.38.1 hoping it would fix itself but didn't).
The issue doesn't occur on two 1.35 wikis I have on the same server (https://sophivorus.com and https://mediawiki.solutions)
I'm running PHP 7.4.12 and identical setup everywhere, AFAICT.
Page creation works fine, the issue happens only when editing existing pages.
Looking at https://wikivideos.org/info.php it's pretty clear I have php-bz2 php-zip php-bcmath php-gmp php-pspell php-tidy
But php-pear is disabled. It feels very unlikely this be the cause since my 1.35 wikis work fine without it but I'll report back when I manage to enable it.
Also I can't switch to PHP 8.1 to test if this fixes the issue, I'm afraid.

Thanks for the report! Please reopen if any issue remains.

@cscott Thanks so much for your thoughtful reply! I was finally able to resolve it via the API, so I didn't try your solution yet. I still want to try it and reply here but it seems @ssastry is a bit in a hurry. I'm closing this task as resolved then, and if I try your solution I'll post here for future visitors.