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.
Sat, Feb 15
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).
Fri, Feb 14
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.
As the policy of space is absolute, other users can not be invited to the task.
Thu, Feb 13
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?
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).
See also: T221774#5679907
Wed, Feb 12
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).
Mon, Feb 10
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.
Fri, Feb 7
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.
Sat, Feb 1
Fri, Jan 31
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.
Wed, Jan 29
It can be used to set the skin for unregistered readers too if there will be a settings screen or menu for readers.
Tue, Jan 28
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.
Sat, Jan 25
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]).
Tue, Jan 21
Currently you need to use "mis" as language code, or alternatively mis-x-Qxxxxx.
Jan 18 2020
Jan 17 2020
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"
Jan 16 2020
@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.
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.
Jan 15 2020
Jan 14 2020
Don't think it's true.
Jan 13 2020
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.
Jan 12 2020
Jan 11 2020
Jan 10 2020
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.
Jan 7 2020
- 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
Jan 6 2020
Jan 5 2020
Currently we use several monolingual text statement for multilingual text data. This is only a workaround.
Dec 31 2019
Dec 30 2019
Dec 29 2019
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?
Dec 28 2019
Dec 27 2019
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.
Dec 26 2019
Dec 25 2019
We also have a restriction at https://www.wikidata.org/wiki/MediaWiki:Titleblacklist, so the restriction in configuration may be removed.