&diff=&oldid=' requests [15:36:31] and their User-Agent header is "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0" [15:37:46] my team guess this is a web crawler, how we should refuse this? [15:38:18] What about using robots.txt_ [15:38:19] ? [15:38:45] https://raw.githubusercontent.com/femiwiki/docker-mediawiki/main/resources/robots.txt is the robots.txt [15:41:58] though I don't know if that crawler cares about robots.txt. [15:43:08] my team have long term plan for horizontal scaling, but not prepared now [15:44:34] lens0021: Firefox/45.0 seems quite old. Try to block the user agent on the webserver [15:45:37] You can also block the IP, if you find all requests come from the same IP address or range [15:45:52] Doing it in MW (or trying to) is probably too late. So ^ [15:45:53] Of course, block it at server level, either iptables or webserver [15:48:19] Vulpix: the IPs of the requests are various. I have delivered the blocking user agent policy to my team member. [15:49:15] Speaking of spam, if you would like to hear about some anti-spam strategies, you can join the MediaWiki Stakeholders meeting happening right now [15:49:24] https://mwstake.org/mwstake/wiki/Event:138 [16:07:34] Can anyone join the google meet link? [16:32:30] kedar_apte: anyone could but it is over now :( Sorry we missed you. [17:37:29] Reedy: why have an override just transclude the actual page [17:38:03] Because they want it to fall back to the canonical at https://en.wikipedia.org/w/index.php?title=MediaWiki:Emailpagetext&action=edit [17:38:12] not use the en-gb version in MW core [17:38:20] ie what you'd see at https://en.wikipedia.org/w/index.php?title=MediaWiki:Emailpagetext/en&action=edit [17:39:07] Reception123: right [17:39:12] Reedy: * [17:39:17] https://en.wikipedia.org/w/index.php?title=MediaWiki:Emailpagetext/en-GB&action=edit exists too [17:39:42] Who should I trout [17:39:49] I'm not sure en-GB does anything [17:40:02] deleted en-GB [17:40:45] Actually [17:40:53] There's no Emailpagetext en-gb message in MW core at all [17:41:30] Oh, but stupid fallbacks [17:41:42] so it does fallback en-gb -> en, not the non suffixed [17:42:23] We need to fix the main one as per https://phabricator.wikimedia.org/T247550#6962241 [17:43:25] Are you allowed to use the powers or should I ask an int admin? [17:47:28] language-variant fallbacks make no sense as currently implemented. When a new language variant is added, users using it won't see the customized messages for that wiki [17:47:43] I think there's a task about it [17:48:29] I thought brexit was going to fix all the en-gb problems [17:51:16] https://en.wikipedia.org/w/index.php?title=MediaWiki:Emailpagetext&diff=prev&oldid=1031625689 [17:51:30] T217357 [17:51:31] T217357: MediaWiki:Talkpageheader message does not handle language fallbacks - https://phabricator.wikimedia.org/T217357 [17:52:25] That looks like a workaround for something that needs a fix [17:52:33] T229992 [17:52:34] T229992: Locally created fallback should take precedent over config fallback - https://phabricator.wikimedia.org/T229992 [17:52:40] someone was complaining in #translatewiki the other day about this too [17:53:52] You can't expect to create messages for all variants for messages you've customized, so users using those variants see your customizations. And repeat everytime a new variant is added [17:56:36] yep [17:57:01] I don't see why we wouldn't implement T229992 [17:57:42] default message in UI language <-- default message in fallback language <-- override message in content language <-- override message in UI language [17:58:02] I think that chain would handle most/all cases? [17:58:12] maybe the last "override message in UI language" should also consider fallbacks? [18:13:08] Ty legoktm