Note MSSQL support is planned to be removed in 1.34, and you are strongly adviced against using it.
Mon, Aug 19
CC subscribers of T14251: Read restriction support
Sun, Aug 18
Fri, Aug 16
Thu, Aug 15
Wed, Aug 14
Tue, Aug 13
Not a task.
Mon, Aug 12
Sat, Aug 10
An alternative solution is make blobs of each abusefilter page encrypted with a specific per-filter key (stored in abuse filter table), so that any mechanisms (including extensions) that reads content objects directly can not expose private filters, and decryption of AbuseFilter content are handled in AbuseFilter extension with a permission check. As abuse filter rules are also stored in the table, Decryption will not be done in each edits.
Fri, Aug 9
Yes this is used to map sysop=>editprotected and autoconfirmed=>editsemiprotected. But in my opinion this should not be kept indefinitely.
This may be a combination of T224845: Write Wikibase page props for MediaInfo entities and T200860: Possible to search page property via search box.
Thu, Aug 8
Yes we can just modify the page_restrictions table. But the log may be broken once the old message key are removed.
By the way, are there any maintenance script to rename a protection level? We may need a task if no such script exists
See also T217005: Fix wgRestrictionLevels for all Serbian projects to fully work for another disparity (in its extreme)
I think we should consider T169626: Deprecate 'autoconfirmed' and 'sysop' value from $wgRestrictionLevels and related settings, though this will be a huge breaking change.
Wed, Aug 7
Did you find the issue while logged out?
Tue, Aug 6
It refers to https://www.wikidata.org/wiki/Special:EntityData/E10, and Special:EntityData is served by Wikibase, but EntitySchema is not based on Wikibase.
Mon, Aug 5
EntitySchema is not relies on Wikibase so it should not use Special:EntityData in Wikibase. Probably we should use www.wikidata.org/entityschema/Exxx
Sun, Aug 4
Sat, Aug 3
Fri, Aug 2
Probably we can override it in WIkimediaMessages?
Make sure the error message of Special:UrlShortener in other wikis does not break.
Thu, Aug 1
Wed, Jul 31
Probably related to T228886: Wikidata main page can't be accessed using non-English language
Mon, Jul 29
I don't think LDF request is a proper way to get the full result. Currently one page requires 27 seconds to load, so we need 53 days (if the request not run in parallel) to get all results, and the result set will change significantly in the interval.
This may be moved to a seperate endpoint, probably in Toolforge.
Toolforge is an alternative for long tasks.
@wmr You should use Toolforge instead. Suggest to decline.
It's already in Wikistats, though not displayed normally.
Sun, Jul 28
Fri, Jul 26
Thu, Jul 25
I'm proposing the project in requesters' perspective only. They should find the correct project easily. A form may be preferred so that it takes no efforts to categorize these things once there's adequate instruction.