IMHO at least the license issue and the logo image would have to be fixed before.

I have reduced the template text to this failing wikitext:

This exception was added at abd3c02d0811.

I don't think it should report any block if no pages are selected. It should report an error instead. Magically making "blocking from no pages" mean that they can't do an undefined "something else" upload, move, use certain Special page...?) is a bad idea. If we want to disable upload, the revoked rights should be explicitly stated somwhere.

Worth asking the community to be sure, but I think it could fit.

A crazy idea was to use Wikidata entities, but wikitech doesn't have Wikibase Client.

ie. namespaceDupes.php

All of these seem things to be fixed (made parametrizable) at TitlesMultiselectWidget level.

I also agree that T203171 would be more important than admin actions not functioning completely in such case.

Can the people that uploaded designs state the license for their stickers? (you can choose Edit Comment at the dropdown menu for when you added it)
I have noted that on the GCI task description.

Usually I would leave the old values in place, so that things linking to the old content don't break. But in this case, I don't see how it could be useful to link to a stopped RSS feed, so actually replacing would be fine, too.

It is to be added, where it had the https://blog.wikimedia.org url, which is the old blog.

Removing the second image per prtksxna request. bawolff also agreed it seemingly was duplicated.

If a user needs to be blocked, does it really merit the amount of trust that is needed for holding the CheckUser privilege?

While we review all the messages with the new UI, it seems appropriate to also use the opportunity to evangelize about password managers...

(note: they are pages 13 and 67 are according to the internal document numbering, add 10 pages for the absolute page in the pdf)

If each user is given a different public IP, there shouldn't be throttling problems...

Looking at the University of Maryland page (which is 21 years old!), and the mention of eight character passwords, they talk a limit of 8-character in the passwords, which is clearly because of the old DES-based crypt(3):

Currently, the maximum password length on many Unix systems is eight characters, but if you want to add a few more characters to make it easier to remember, go ahead. Just bear in mind that anything after the eighth character will be ignored.

Would love to see some papers on that area.
The links on that section are 10 years old ☹

I would also add a check for the HIBP Pwned Passwords blacklist.

Is there a reason to for increasing the pwlength for new accounts only to 8 ?

Assigned, @Aklapper

@Aklapper: yes.

I can reproduce it with the version downloaded from wikipedia:

As mentioned on irc, this text corresponds to https://es.wikipedia.org/wiki/Usuario:Danielalfredo/Taller (however, it parses fine ☹)

Hmm, reviewing that the READMEs are right and updating these little bits would do a nice GCI task.

Not sure about including it in the emails by default, but seems sensible that it _can_ be included, and it would be easy to create a patch that allows that.

As a user of the 2006 editor,¹ I would like to echo what Legoktm asked more than a year ago on T30856#3629674, regarding removing from core vs removing from wikimedia sites (where I expect many people will be using it, some of them as an informed decision).

I don't see that deleteLocalPasswords checks if there is an account on CentralAuth. Do all users have an account there with the password hash copied ? Or would an ancient user that never got migrated and suddenly decide to return not be able to login after the password deletion?

This is a Wiki Loves Monuments banner Campaign.
Seems it would benefit from having a <div dir=ltr> around it.

I'm not familiar with VCL, but parsing the accept-language header (correctly) is more complex than most headers.

In T202759#4530963, @Krenair wrote:

In my experience the main problem with this process is that event organisers neglect to give enough information (e.g., IP address) before the next eligible deployment window.

The code to review seems to be https://github.com/guzzle/guzzle

Well, probably they should be their own queues, even if it will then be handled per-language by the same existing groups. But before that it would be interesting to know the volume of such emails, and the types. Keep in mind that for certain emails (eg. a password recovery), maybe we don't want to blindly add such replies (probably containing the temporary password) into OTRS without a clear usecase.

Looking at the profiles, I don't see why the email is needed.

FWIW: here is the wiki-based content we have been using in Spain for several years:¹ https://www.wikilm.es/en/

The second instance of Wikipedia should be replaced with the project name in each case. I don't like the explanation "Wikipedia is making the site more secure." (how so? Wikipedia content caused the singularity in the servers? ☺), preferring something like "We are making Wikipedia connections more secure.", but I'm afraid it's the kind of sentence most visitors would expect…

Thanks @Zeko for his work tackling this development. We have quickly tested the current plugin and it seems there is still ample room for improvement. In particular, the entire lists of tags and categories disappear from the UI each time you access, and the search for items in Wikidata does not seem to work. :/

Maybe you could try not ending the message with "-- Legoktm" ? Just prepending a space would do. Lines starting with a dash would be mangled in traditional PGP. It shouldn't really matter with PGP/MIME, but that's the only slightly odd thing I see with your message.
Failing that (as it is likely to do), could provide the original email you sent (which should then validate), as extracted from your MUA? That would allow comparing it with the one that ended up being sent, to figure out what the mailing list did.

Account creations there are already logged on #central, not sure about renames

@Niharika: It is acceptable. MIT license is compatible with GPL v2 or later.

Another instance: «Anexo:Temporada 2018 de Junior de Barranquilla»

Note that the description shouldn't be "When a person is accessing" but "When it is attempting to edit" (or equivalent), which is when we check for blocks. Attempting to check blocks on every page view would kill the site ☺

I would think this is public info. Looking at the pastebin, this doesn't even attempt to be a leak, it's a script for mapping usernames and emails on git. It's very likely that it was made by someone on our community.

I suspect it may be looking for the src attribute look at most at N characters, while in your post there are many characters before it.

I prefer the first mockup, I'm not convinced about the others.

The proprietary nature of Google Chat isn't just a philosophical issue with regards to using the service. It also means that the features (in this case notifications) developed for Google Chat won't be available to developers not directly contracted by WMF.

In fact, those timeouts appear even on the early hops. The ticket also includes a successful tcp traceroute, and no explicit mention of timeouts.

Well, if the server itself is needed, it will be doing its work with a different IP address than the one of wdqs1004, since it would have been suffering the same connection issues as wdqs1004 (just the other half time).

@Huji that is a utf-8 name shown as latin1. Seems there is an extra or missing conversion somewhere.

In T188160#4037130, @jrbs wrote:

Right now it would be incredibly confusing to admins if they see edits from a range that's currently blocked.

Please remember to 301 /wiki/.* to the new url…

Agreed, this is something to fix.

Well, getting notified by SineBot doesn't seem _that_ bad, since the user should have signed the comment themself. OTOH, the admin mentioned by CommonsDelinker doesn't need the ping at all.

Should it really accept pm commands?

Why does this need a second task. I see this as one issue.¹ Whenever the entry on user_groups is removed from there (either by another user_groups action or by the cron job), that must add it into user_former_groups (if not already there).

Use $dbw->insertId()

@Hugi: I think CheckUserHooks::logLoginAttempt will need to be public, not protected.

I would actually find that a that system provides a signed copy (such as a pdf of the edit with some boilerplate explaining the contents) would be more useful.

@Huji I think the point is that nothing can use that User-Agent. You are setting a variable that cannot be read…

The hint for mcrypt.so is

undefined symbol: spprintf

Cool anchors don't change.

I was just trying to address the stated concern, not make it a perfect solution (we will probably still have irc.wikimedia.org for some time, so it would be good that things were better). Also, I am assuming bots will reconnect and rejoin with near-zero downtime, trying several A records as needed.