More related or duplicate seems T214551: RevisionDeletion log does not move to new title after page move.

Related task T23175: Displaying relevant log directly on page instead of linking to log. This also needs to work with moved pages.

https://wikitech.wikimedia.org/wiki/Help:Toolforge/Running_Pywikibot_scripts_(advanced) might be better for running your own pywikibot scripts.

Fixed following the instructions at https://wikitech.wikimedia.org/wiki/Help:Toolforge/Running_Pywikibot_scripts_(advanced)

I removed the cronjob scheduling tasks with jsub. Hopefully I can get something working using instructions at [[wikitech:Help:Toolforge/Running Pywikibot scripts]]. But first attempts were not successful.

In T341917#9017534, @JohanahoJ wrote:

Ok. Ticket number for "be" is CLDR-16876.

I see that my web browser (Firefox) gets a json file from an url with "&uselang=en" to get these descriptions and labels:
https://fr.wikipedia.org/w/api.php?action=query&format=json&origin=*&formatversion=2&prop=coordinates%7Cpageprops%7Cpageimages%7Cdescription%7Cinfo%7Cpageterms&inprop=url&colimit=max&generator=geosearch&ggsradius=10000&ggsnamespace=0&ggslimit=50&redirects=no&uselang=en&ppprop=displaytitle&piprop=thumbnail&pithumbsize=150&pilimit=50&codistancefrompage=Mont%20Blanc&ggspage=Mont%20Blanc

In T282981#7173897, @Reedy wrote:

Reopen the task that it was duplicated against, then.

I created this task using the preformatted Phabricator task link on Mediawikiwiki:Contributors/Projects/Columns_for_references#Requesting_this_feature.
I don't know why the Visual Editor tag is included there, but it is the same as many other subtasks of T159895.
This is not about editing, it is only about how <references/> are displayed. What is needed is setting wgCiteResponsiveReferences to true for svwiki.

r72424 fixed this by almost duplicating the button code. Making one string for the buttons without accesskey to be returned by getStartBody(), and very similar code making a string for buttons with accesskey that is stored in $this->buttons for later use by getEndBody().

Should this really be low priority? It is a really annoying bug that was fixed in earlier search versions and worked fine but was then broken again.

The fix for T78637 was only one line of changed code. Is this much more complicated to fix now?

In T66315#5402390, @Lea_Lacroix_WMDE wrote:

I got an interesting question: "will the keyboard shortcut (ALT+SHIFT+G) still work after the move?" -> I didn't know about this shortcut, it's awesome :') Anyway, we should make sure it doesn't break in the process.

This is now broken.

It looks like this change removes id "t-wikibase" without adding any other id. That breaks the accesskey and tooltip from messages "accesskey-t-wikibase" and "tooltip-t-wikibase" in the i18n files.

I think this was fixed with https://gerrit.wikimedia.org/r/#/c/384197/

The setting could look something like this

Which underlying problem would such an option solve?

Same problem that is solved for unanonymous users with a setting in their preferences. For different reasons many users prefer to see all languages without having to click "X more" and scroll through the languages popup.

Opening one of these pages for editing I also see that no templates are listed below the edit area.
And following a link from the page and looking at [[Special:Whatlinkshere]] the link from the page is missing.
So neither templatelinks nor pagelinks are stored in the datebase.

Now it works fine. Thanks.

I first saw this at Swedish Wikipedia. But also on French, Icelandic and Dutch Wikipedias.

Is there a reason why Vector and Monobook use different names for the portlet/portal and pBody/body classes? It looks like the classes have the same purpose, so different skins should be able to use the same class names.

Bug T85787 is that CharInsert uses insertTags() which is marked deprecated which gives warning messages. This is not a big problem until the deprecated function is removed, but I think it is nice to avoid warning messages.