I instead think (only in my opinion) we should support we should continue to make it work in Fandom (1.19.21) for an unspecified time.

For older MediaWiki Pywikibot compat is more usable but it is no longer official maintained. It may be still an idea to (unofficially) port the compat to newer version of Python (though no new feature will be added).

By default pywikibot will do one edit every 10 seconds (or longer if you use parallel processes). This may be overrided by setting -pt:1 (or 0) and some bots runs under it. This task will unconditionally throttle it when lag is high (but they can still edit in a high speed when lag is low).

Currently Widar use a policy of sleeping 3x+1 second if the lag (x second) is higher than one second. PetScan run batches five in parallel, so for a lag of 10 seconds PetScan make 5 edits every 31 second.

This will be T240442: Design a continuous throttling policy for Wikidata bots.

As the policy of space is absolute, other users can not be invited to the task.

In T245201#5883301, @mmodell wrote:

btw: I really don't like the the acl* convention because it doesn't normalize consistently. I really don't see why we can't use only the icon as the indicator of ACL projects and then we won't need a naming convention.

I'm not in love with it either. I think the original idea was the prepend and special char would prevent it from polluting project search ahead, and it's more or less done that, but iirc you said we could do it another way if the icon is consistent? Seems sane to me. For the moment though, I don't want to mix that work and this. I'll make another task for addressing ACL naming convention.

So, is it really required for all stewards to have access to security issue?

We already have acl*stewards. Is it nececessary to make a second group? (per T131766, T163260 and T217361 stewards may often require accessing security issues)

The only way to resolve the issue is increase the rate of edit Query Updater can handle.

I once suggested you should at least retry 1000 times (https://www.wikidata.org/wiki/User_talk:Andrawaag#WikidataIntegrator_and_maxlag), but Multichill suggests T221774#5679907. It seems this is still not a good idea (see my analysis at T245144#5880941).

In T221774#5679907, @Multichill wrote:

In T221774#5679442, @Bugreporter wrote:

Currently multiple tools are broken because the time that make maxlag back to normal is much longer than the total time the tool retries edits (see this and this).

Good that this change works as intended? Tools should be updated to handle maxlag in a graceful manner. Retry time should not be something fixed, but something which increases if you get it or not. So 5, 10, 20, 40, 80, etc. This also makes sure that not all tools restart at the same time.

See also: T221774#5679907

If the rate of edit Query Updater can handle is a constant, changing the factor will not affect the average edit rate, nor the proportion of time the lag under a specific maxlag (assuming the rate of edit over maxlag and under maxlag are constants independent of the actual maxlag).

I think increase the factor will not make thing better, it only increase the oscillating period. It even make query service worse (more lagged).

This issue is already reported in 2014 at https://en.wikipedia.org/wiki/User_talk:Equazcion/SidebarTranslate#Titles_with_en_dash. I proposed an edit request: https://en.wikipedia.org/wiki/MediaWiki_talk:Gadget-SidebarTranslate.js#Interface-protected_edit_request_on_10_February_2020

This is https://en.wikipedia.org/wiki/User:Equazcion/SidebarTranslate. I enabled this gadget and do reproduce the issue.

Note in this task I propose that some queries lasts for up to 30 minutes may be able to run (asynchronously).

Probably related to T241972: wmgUseEntitySourceBasedFederation true for Wikidata.org.

See also https://www.wikidata.org/wiki/Wikidata:Project_chat#Missing_labels_again, items higher than Q74000000 are not in new term store at all and are broken.

It may be helpful if a new service (T232240: New service to shorten wmflabs URLs) will also support creating custom short URL for WMF production URLs.

It can be used to set the skin for unregistered readers too if there will be a settings screen or menu for readers.

In T243844#5836700, @DD063520 wrote:

Hi,
I think I use a bot account. I created it using Special Pages / Bot passwords. And I set high volume editing. In this scenario, is the rate limit not set? i.e. should I be able to edit more?
Merci
D063520

You can remove the limit entirely, if you are watching your server's health.

This user probably does not use a bot account to import, so it is affected by defaule MediaWiki rate limit (90/min).

Please use an account with "bot" flag to do the import. Otherwise the rate of edits may not exceed 90/minute. Note anything described in T184948: limit page creation and edit rate on Wikidata is no longer in effect.

Watchlist shows recent changes of all entities a page use, though the label is confusing (T125768: [feature request] Watchlist display of wikidata edits (of items connected to a page via arbitrary access) is a bit confusing [add label of linked item]).

Currently you need to use "mis" as language code, or alternatively mis-x-Qxxxxx.

In T221774#5680891, @Addshore wrote:

Due to the apparent differences in lag pattern between some of the nodes we need to try to get T238751 done so that we can use the max lagged server rather than the median (which we currently do).

If nobody is going to work on this, it should be Lowest. Declined means it should not happen even if someone is working on this and maintaining this.

maxlag is currently based on median (not max) of lag of all public servers.

Then someone introduces a "Global custom short URL policy"

@Aklapper This is a different task than T242464: Feature Request: Expiration date for short links. In this task it's not proposed to make non-persistent short URL.

Possible duplicate with T207683: Wikibase Repo api modules and special pages should be conditionally loaded based on entity types enabled (or at least, not crash)

I don't think we should encourage users to create (or edit) large number of poorly watched and maintained talk pages. We should have some way to aggregate the discussions.

Don't think it's true.

Should bugs of this tool be reported to here or GitHub? if the later the bug should be exported to GitHub and closed here.

The correct place to report issue seems to be https://github.com/lucaswerkmeister/tool-lexeme-forms/issues. (also @Lucas_Werkmeister_WMDE )

Please reopen and fill the placeholder if you still need the task.

I don't think such a tour should live in production Wikidata (instead, use test Wikidata). See https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2014/06#Wikidata:Tours for concern.

@Legoktm Do you think it is still inappropriate to do so even if only admins can create custom short URLs and creation of custom short URLs are logged?

I do think we can add (though not enable) this function, and than discussion how it can be used.

See also https://en.wikipedia.org/wiki/Wikipedia:Request_a_query

• There are no activity related to the scope of the project as defined in the project description since 2014.
  • Per recent activity, some people are confusing this project with Data-Services
  • The Wikitech page is marked as obsolete

See also T46773: property search in entity selector should not be prefix-only

In T230103#5764141, @DannyS712 wrote:

Will template protection also be renamed?

Currently we use several monolingual text statement for multilingual text data. This is only a workaround.

Further digging:

bugreporter@tools-sgebastion-07:~/mediawiki-extensions-CirrusSearch$ git checkout origin/REL1_34
Note: checking out 'origin/REL1_34'.

Actually the file is at https://extdist.wmflabs.org/dist/extensions/CirrusSearch-REL1_34-a86e0a5d.tar.gz but the extension redirects to CirrusSearch-REL1_34-a86e0a5.tar.gz

Do you see an empty page on https://en.wikipedia.org/wiki/Special:Contributions/Thatoneweirdwikier? what if you logged out?

You may upload an image of the display here (directly drag the file to this page). This helps debugging.

What's the URL?

See also T105570: Remove old user groups from Wikimedia wikis (afttest, afttest-hide, etc.)

hmm we even have a dedicated extension that add a right bypassing all abusefilters: https://www.mediawiki.org/wiki/Extension:AbuseFilterBypass

In my opinion this require a backport to previous MediaWiki branches.

We also have a restriction at https://www.wikidata.org/wiki/MediaWiki:Titleblacklist, so the restriction in configuration may be removed.

We also have Parsoid-PHP - We should merge them.