- es.wiktionary logo in SVG seems to be ready. Upload pending.
- es.wikinews logo in SVG is pending community review and fix of a couple of minor things.
Tue, Oct 17
This shouldn't be lowest priority, as we run across this issue so often.
@bd808 Yep, that's them https://wikitech.wikimedia.org/wiki/Special:ListUsers?username=&group=importers. Should they still need to do XML importing they should be added to the 'importer' group instead via Special:UserRights.
Mon, Oct 16
I tested this on production and this gives:
This needs someone with access to silver I guess. @bd808 do you have access there and can run the SQL query?
I wonder how MassMessage behaves when sending the job. There are lists with hundreds of subscribers yet never timeouts. Maybe the same behaviour should be used here for the feature to get usable again? Ping @Legoktm for analysis.
I agree this would be a helpful feature.
Thanks @Huji. If you can take care of the second part, feel free to. My PHP is so scarce that I won't even bother in giving directions to myself :-)
I just did the i18n part (create the new messages). Unfortunatelly I won't be able to do the AbuseFilter code use each message for each action.
Sat, Oct 14
@dmaza Thanks. I was just wondering about the RuntimeProfile flag. For now I'll get the normal profiler as intended. Spanish Wikiquote is a small wiki with few activity so I don't expect performance issues.
Rangeblock does block the entire /16 IPv4 range of the triggering IP for
infinite, and I'm not sure if it does support IPv6 nor if it respects
BlockDuration/AnonBlockDuration from abusefilter.php. Maybe we should
investigate that first.
Fri, Oct 13
Thu, Oct 12
Hmm. So we've got $wgAbuseFilterProfile in abusefilter.php, and now in InitialiseSettings we have also a $wgAbuseFilterRuntimeProfile -- which are the differences between them. Ping @TBolliger. I've always used AbuseFilterProfile, not Runtime. Not sure which one to enable now.
Hi @demon Can you delete https://github.com/wikimedia/mediawiki-extensions-AntiBot when you've got a minute? Thanks.
Due to extension being archived and patch being abandoned as well.
Tested. The suppress option only appears if you select an 'infinite' expiry time (which is okay as temporary hideuser blocks make no sense). Behaviour of the blocking hasn't changed apparently so I'd say it now works :)
Sure, I can test. I'll check a random group 0/1 wiki and will report back to you. Stay tuned :-)
Mon, Oct 9
@MoritzMuehlenhoff Does that help or ease the suggested migration? Thanks.
Weird. I've tested on the Beta Cluster this, which was not rolled-back as it runs in master, and the option appears when selecting an "infinite" expiry time. I did that too on Production but it didn't worked back then when I reported this. Maybe this can be included again in the next MediaWiki train.
Sat, Oct 7
Thanks @Reedy -- I'm going to sleep now so I won't be able to report if the reverts have brought the feature back. If other stewards/oversighters (or you should you have access) can check that it'd be appreciated. I'll ping the stewards' list so at least one of us can stay around and see if everything works as expected.
@Reedy IMHO it is UBN as we're now exposed to not being able to remove abusive usernames when blocking them (if developers disagree, feel free to readjust the priority). OOJS UI conversions are purely a design change that IMHO should not take over when a function that has been working as of now and that operates in the area of project privacy has been broken by the change. That said, I'd hate to request to "ruin" Amir's work, though if there's no option... I'd rather avoid not being able not to suppress accounts for the whole weekend... Your call. Thanks.
Not sure what do you mean @Reedy - In case I was not clear I think we need to fix this in master and after that patch the current MW branch we're using on WMF projects to recover the function as soon as this is repaired. Does that make sense? Regards.
Tagging as UBN due to the current problem of not being able to suppress user accounts with abusive usernames or private information. I'd also suggest that the fix be backported to the current wmf MW branch as soon as possible so we can recover this function. Thank you.
Fri, Oct 6
And we need a Task for this?
Thu, Oct 5
If T177082: Archive the AntiBot extension goes forward, this won't have much sense BUT I see no harm in leaving it converted. Nothing prevents that somebody in the future can revive it. Thanks.
If we go with subproject road, I'd suggest instead:
Pretend you saw nothing :D
It's working fine for me. What do you exactly tried to do?
Thank you. Do we do Apertium work from Phabricator or it's something that is handled elsewhere. If that's out of our control, then yes, I'd agree with @Aklapper on closing not because it's not a bug, but because we can't fix it ourselves.
Thanks, I'll inform the user accordingly. Hopefully one day we'll have proper usermerge support for Wikimedia (T156584).
Added parent and subtasks for tracking. As you can see, DPL is not being deployed.
whenever the user makes an edit, instead of waiting for someone to change their groups
Wed, Oct 4
I'm okay in general with the proposal. However its purpose is defeated if virtually anyone can join the group IMHO. Which abilities do you plan to assign to this ACL if created? Thanks.
I don't understand such behaviour. When you mean "there's no en -> fr" avalaible, what do you exactly mean? I'm confused. Thanks.
Sometimes we need to create private pastes. I don't see much of a fuss in allowing (some?) users to do so. What if they can't be seen by administrators (not true as they can change ownership via CLI should they need to do so afaik; Spaces are different). The "nothing-hidden policy" is not workable in an absolute way. We sometimes need to create private Tasks, Pastes, Conpherence rooms, etc. Thanks.
@kaldari Tool Labs is mentioned here because I discovered the 'root' of this issue via a toolforge tool. The issue here is that MediaWiki is keeping, with regards to temporary user rights, old and incorrect data as you correctly mention as well as others. I'm certainly sorry if my meaning was not clear, and as @EddieGP mentions, tool mantainers should, in addition to this work, amend their DB queries so their results are more accurate; but this is all about how MediaWiki works, not Toolforge tools. Regards.
I asked and configured Livvi-Karelian wikipedia to use uca-fi as the language is very similar to Finnish and there's no uca-xx-olo. See T147064: Determine category collation for Livvi-Karelian Wikipedia (olo.wikipedia.org).
Seems like an issue with Apertium or the automatic translating feature. I'd love to see it removed for Spanish as it sometimes "translates" to nonsense.