@Zache are you able to describe what you are referring to above in a bit more detail? I want to make sure I'm understanding what you are saying before responding.
Sat, Oct 17
Thu, Oct 15
It seems that we could do spacing with nowiki also instead of html-comments. With nowiki broken comments would not fail silently.
Wed, Oct 14
In the enwiki's help page, the spacing between items should be done using comments. Like this in wikicode.
@ppelberg It was to make editing the wikicode easier. The original proposal was in the village pump discussion "Selkeyttävä ehdotus in 2005. It was low volume and contained only three comments. The next village pump discussion which referred to empty lines in discussions was in 2015 (Muistutus_keskustelusivukäytännöstä) when Otrfan notified that writers should follow the new line guideline to make commenting more easier.
Tue, Oct 13
Thanks. It however should be able to handle cases like this too (in wikicode) where comment is splitted to multiple dd:s.
At HTML-level it looks like this. So, with newlines, the extra margin between rendered comments comes from the margin between separate lists. However, as Whatamidoing (WMF) noted in village pump the separated lists are an accessibility problem for screenreaders etc.
Thu, Oct 1
Hmm, it seems to be working now though I tested the url before I submitted the bug report. If it stays up then this can ticket can be closed.
Wed, Sep 30
In Wikimedia Commons is language selector of old wgExtraLanguageNames languages is now broken. Those languages cant be selected from the user interface. If I understand code correctly currently those languages are defined in wbTermsLanguages.json for CaptionsPanel.js.
Sep 10 2020
@Marostegui can you check if problem exists in the production db too or just that we cant see those users in labs database because of sanitization?
Investigated little bit. I suspect that there has not been any edits for those users, but i cant confirm this edits could be deleted with oversight too. However, user_id 310454 was referenced from abuser_filter_log table and second user_id 318872 from logging table.
Sep 7 2020
T262196 seems to be related to same root cause too.
Sep 4 2020
Aug 31 2020
Aug 21 2020
Confirming, the map seems to work, thank you for everybody involved!
Aug 19 2020
So it would be just to add wikilovesmonuments.org to config files regexp?
Thanks, here is some screenshots from my computer.
Aug 18 2020
hmm, oauth works for with maps.wikilovesmonuments.org but not in monumental.toolforge.org
Aug 17 2020
I think that the reason is that there is still old callback url, but site itself is moved to monumental.toolforge.org and login security doesn't survive from redirection.
I can confirm the error
Quickfix could be to use https://monumental.toolforge.org which seems to be whitelisted. This doesn't work for all of the use cases (ie. main site is still broken)
Jul 10 2020
fixed by Para. Thank you.
Jul 9 2020
Jun 14 2020
If communities want to continue to use where they should contact to get some of the teams to be responsible? (afaik this is the current situation as there is no replacement and the communities like it as a tool)
Apr 8 2020
So,. if I understand correctly the problem is that the views used currently in the tool labs are fucked by design and because that everything is unusable slow?
Mar 10 2020
pushing this little bit up. It would be nice to get goodfaith working.
Mar 4 2020
Yes, the sql fiwiki_p connects to fiwiki.analytics.db.svc.eqiad.wmflabs .
Mar 3 2020
Bug: Try to edit a specific page on deWP throws InvalidArgumentException T246720
Feb 26 2020
One clear use case for Wikimedia editors who aren't coder but who can write/modify SPARQL queries is to sort and filter Petscan and Listeria results.
Feb 24 2020
Sorry, it had wrong quarry id. https://quarry.wmflabs.org/query/42368 is correct one.
Feb 23 2020
@Reedy I hava an idea why the autopromote is broken.
Feb 19 2020
Feb 18 2020
Feb 16 2020
Any hope that this would go forward?
Feb 14 2020
Feb 3 2020
Dec 26 2019
The second option could be to set wgFlaggedRevsHandleIncludes to FR_INCLUDES_CURRENT ( value = 0 ) in InitialiseSettings.php so that FlaggedRevs would not track the included pages. However, this would mean that there would not be notifications from the file, module or template changes in articles either. If you doesn't need those notifications then this would simplify the user interface and this would be my recommendation.
Probably related to edits made on MediaWiki-extensions-FlaggedRevs (MediaWiki 1.35/wmf.10)
Dec 24 2019
If we just want quickfix for autopromote with some features missing then it editor/autoreview/reviewer groups could just added via wmgAutopromoteExtraGroups or wmgAutopromoteOnceonEdit in InitialiseSettings.php
Dec 22 2019
I think that this is because page uses the talk page in a way that it is included as a template. (ie. there is a link in templatelinks database table between page and the talk page) the edits of the talk page will be handled like the edits to templates used in the article.
Dec 17 2019
Based on Manual:$wgExtensionFunctions: This variable is an array that stores functions to be called after most of MediaWiki initialization is complete. Note however that at this point the RequestContext is not yet fully set up, so attempting to use it (or equivalent globals such as $wgUser or $wgTitle) is liable to fail in odd ways. If you need to use the RequestContext, consider the BeforeInitialize and ApiBeforeMain hooks instead.
Tested that flaggedrevs_promote is still updated
Dec 14 2019
In plwiki it stopped working also at 23:17, 24 June 2019 ( log )
Dec 12 2019
This can be also reproduced in Finnish Wikipedia. (it reproduces always, but minimal ui will make it more visible in fiwiki)
Dec 10 2019
One thing to check would how the change affected the review workload and review backlog. Ie was there effect on the number of reviewers and how reviews per the reviewer are distributed between users.
Nov 28 2019
Autopromote is broken for FlaggedRevs, so it is one high priority bug more. T237191
Nov 8 2019
just note for myself. Wikimedia commons requires also local mediawiki:lang/langcode pages for https://commons.wikimedia.org/wiki/Module:Languages
Wikimedia Commons requires also local mediawiki:lang/langcode pages for https://commons.wikimedia.org/wiki/Module:Languages
Nov 5 2019
Nov 3 2019
Oct 25 2019
@Aklapper It is definitely something which is worked on so tagged WMFI to it.
Oct 13 2019
Oct 11 2019
Would it help for debugging if we could replicate this in test2.wikipedia.org?
Oct 6 2019
AFAIK all Flaproblems what i have seen can be explained with settings from wmf-config/flaggedrevs.php is not loaded.
Oct 1 2019
I tried to check yesterday if the patrolling is working or not too, but there are not many wikis where wgUseRCPatrol and FlaggedRews are both enabled. Also when revision is manually reviewed then it will be patrolled too which will mask the problem.
Sep 30 2019
@Reedy do you have any educated guess what is going on here?
Confirmed in fiwiki too (user Aulis Eskola is in 'editor' user group which have autoreview user right and his edit should have been automatically reviewed)
Sep 29 2019
Based on huwiki configuration I think special:unreviewedpages is allowed only for Administrators and Editors. Users with only autoreview right should see a permission denied error on Special:UnreviewedPages.
Sep 20 2019
pushing this little bit up. It would be nice to get goodfaith working.
Sep 17 2019
Sep 16 2019
Sep 15 2019
I would amend the patch and edit the task description to include removing the redundant nys.
Sep 3 2019
@Reedy I think that we are happy that you are maintaining it and thank you for fixing the configuration.
Aug 31 2019
Hmm, problem may be just because 'ukwiki' => false is missing from wgFlaggedRevsOverride setting in InitialiseSettings.php ?