It is on Firefox.
So, you can reproduce it.
It is on Firefox.
In T431942#12193675, @Jdlrobson-WMF wrote:Note the jump to top for tools is intentional so that the user sees where it has moved to.
So, you can reproduce it.
In T432098#12118596, @Nikerabbit wrote:git already keeps changelogs on who changed what
qqq is editable on translatewiki.
In T432063#12117677, @Bugreporter wrote:We can instead hide all closed wikis by default (but still allow users to display them).
Deleting tables is considered (as title suggest)?
In T415237#11621530, @Bugreporter wrote:See also: T39992#424332 - one of points to emphasis is if someone use etherpad to distribute illegal (e.g. child porn) content, we have no meaningful way to prevent so (no meaningful way to find either pad by content or recently changed pad, no meaningful way to block a user, and takedown needs sysadmin action and is thus not scalable for large scale abuse).
So, at least we should have change to another similar system or stop using this service at all.
In T415237#11613170, @Pppery wrote:There are a bunch of pages using templates that dynamically generate etherpad URLs, which I still need to process.
Here are some various features this system would have that Structured Discussions does not:
Currently not, but could have.
In T415237#11607285, @jeremyb wrote:idk how much of the problem is old stuff no longer needed vs. spam but if it would help oauth authenticating against a wiki shouldn't be too hard to do and I can work on that. (I figure authenticate for writes. reads can be anon.)
The integration with MediaWiki, like oauth or extension, could give chance do be able to do other operations to maintain Etherpad. Most important may be the button to export pad to MediaWiki, even with some history attributions.
Please send me copy of this database on drive to my home address.
This is generated in JS. Message used is Thanks-confirmation2. It is not parsed as wikitext. Should?
So, it would not break tools.
New changes also breaks. Like no IP Reveal buttons.
This should apply to all of these popups.
Regarding Tech News, I prefer to say it allows high traffic on other wikis than the local bot. The current phrase about not adding permissions is confusing about effects, even it is not about MediaWiki permissions.
In T409027#11585704, @Samwilson wrote:"View watchlist" suggests I would see items on my watchlist. This is what is done on Edit Watchlist.
Maybe. But when people talk about opening their wachlist they mean Special:Watchlist, i.e. the "watchlist" is technically the list of watched pages, but people more commonly use the term to mean the list of recent changes to pages on their list of watched pages.
What label would you suggest instead?
Note other configurations and extensions. Test AbuseFilter reactions too.
TitleBlacklist checks account creations rather than edits (in the latter case, a temporary account has already been made for the user).
Creations of Named Accounts. We need this performer to create log. AbuseFilter uses this approach.
This is because temporary accounts do not have a username displayed
But we should display them on all skins, with the notice about what it is, like in vector-2022.
Now I know this happens when CodeMirror is enabled.
"View watchlist" suggests I would see items on my watchlist. This is what is done on Edit Watchlist.
What with unlabeled pages? Choosing all and excluding them is good idea or there should be easier option?
No API endpoints need be changed for this work (we think).
API "edit" has "watchlist" and "watchlistexpiry". Why not this? :)
There is no decision to stop using and undeploy.
Some use cases?
Maybe separate installation on Translatewiki would be better?
As a CampaignEvents Developer I want a list of these links to know if they are appropriately linked.
Find for addHelpLink.
At time of creation of this task there was no user-help page. Theres is now, we can link it.
Yes, it is MediaWiki:Allevents-helppage
Good idea.
Yes, random translated/translatable pages are OK. Tested on mediawikiwiki and testwiki.
In T415725#11563488, @brennen wrote:I've seen it claimed that ?action=purge for a given page fixes the error, but @Lucas_Werkmeister_WMDE says not always, so maybe people are seeing a coincidence with something dropping out of cache?
Also
TypeError: MediaWiki\Extension\Translate\MessageGroupConfiguration\HookDefinedMessageGroupFactory::appendAutoloader(): Argument #1 ($additions) must be of type array, null given, called in /srv/mediawiki/php-1.46.0-wmf.13/extensions/Translate/src/MessageGroupConfiguration/HookDefinedMessageGroupFactory.php on line 60
Difference between user_type should be explained.
So, it is now not intended to be a shourcut? What with translations? See /qqq to check whether to update.
Note the Unsuppress will unhide all the logs. Should be warning somewhere or the logs until unflag should stay hidden?
Can't reproduce as of today.
In T241691#5769742, @DannyS712 wrote:The $oldContent created when getting content for revid -1 is:
PageContent::getContentForRevIdif ( $revId !== -1 ) { [...] } return $this->getContentHandler()->makeEmptyContent();And that empty content's level is then checked for changes.
@marrivs Do you still plan to work on it?
Only solution is to change hook mailPasswordInternal to set additional property to new/reset action.
The auto-reveal may exhaust it, and if auto-reveal will have less limits, it may encourage to use it instead of manual check when needed so it will result in more IP displays.
In T412644#11463769, @Lorlam wrote:Shall I report a new bug report to describe this ?
In T220764#6806614, @Daimona wrote:The main problem with this addition is that these variables would be very large if the diff is also large, and the details view might be filled up.
This can be used, but not is not in core: https://meta.wikimedia.org/wiki/User:Msz2001/AbuseFilter_analyzer
This can be modified to do this: https://meta.wikimedia.org/wiki/User:Msz2001/AbuseFilter_analyzer
Can be "filter groups" used for this?
The use case of this change is also poorly documented.
Thanks for reporting!
And these words inside included messages are also depended on both the number and presence of word "last".
Because Catalyst does not update Patchdemo's tables.
So, the reason is not providing (or bad) context to Parser. Does Xml::buildForm support it?
Can't reproduce Badtitle in editing filter or on saving page edit when filter triggered on test wiki.
It seems you want to produce links to Wikipédia:Filtro_de_edições/NUMBER_OF_FILTER. Currently it would create link to Wikipédia:Filtro_de_edições/PAGE_WHERE_TRIGGERED if on editing some page and Wikipédia:Filtro_de_edições/MEDIAWIKI_MESSAGE on preview available on editing filter, but it is not intended format I guess (also not Wikipédia:Filtro_de_edições/Especial:Filtro de abusos/200).