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.

However, it's operating without any redundancy, in terms of both individual hardware failure, and datacenter failure.

I guess the latin magic words would need to be added as aliases for the translation to Cyrillic script .

They seem to have one: https://github.com/wikimedia/WikimediaUI-Style-Guide (maybe it is already in gerrit?)

Improving FeaturedFeeds seems the way to go…

@Legoktm pointed out that "Gerrit would probably not be able to talk to things in cloud services" and indeed, it seems undesirable that Gerrit login page (an high security context) included content from a lower security one. (E.g. a naive implementation copies html produced there into Gerrit login page, then someone compromises the toollabs project and uses it to steal developer credentials)

I guess the existing विकिविद्यालय should be kept as an alias, so that existing links don't break.

It would be nice to have a generic solution that can be used by other sites wishing to include the POTD, ie. keep the Gerrit-specific part as small as possible.

In T185160#3913793, @bmansurov wrote:

• Some users may have the same babel info in multiple wikis. This may have resulted in duplicate counts in the final result. Let me know how we should deal with identical usernames in multiple databases. Should we consider them different users or the same?

Alternatively, give them a real cookie containing a temporary token, which is what we will be using.

Note we'd then have to vary on that cookie, at least for views served via EditPage.

In T184749#3896917, @Anomie wrote:

The "utf-8" flag is set in the DB, yes. But the text itself is already mojibaked when saved in the DB. The reading back from the DB works fine.

On the BebasNeue typeface, the design agency wanted to use it for certain graphics so it's use is limited. Because the majority of the site is in our open source brand font (Montserrat) we had accepted this artistic choice as a "limited decorative" element.

Ah, okay. So those pages are currently cache-bypassing without being session-starting. I assume the patch would need to change this to do both. Or is there another way? I haven't checked the numbers, but I imagine we should be able to handle the increased load from that (basically, anon bounce rate of edit page; possibly inflated by crawlers).

This bug only happens when $wgLegacyEncoding is set. But the variable doesn't seem to be checked anywhere!

Anomie said:

EditPage::internalAttemptSave() → WikiPage::doEditContent() → WikiPage::doModify() → Revision::__construct() calls RevisionStore::newMutableRevisionFromArray()

I don't think the file license would be compatible with scaps run by WMF employees. Could be used by those run by volunteers, though.

I guess your manager at WMDE should confirm here that you are indeed a WMDE developer?

This task says: We have docs at https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki and https://www.mediawiki.org/wiki/Manual:Upgrading Someone should try installing using that documentation, and see if they are outdated or is wrong with such documents.

The extension seems to work with the provided changes. A Special:WatchSubpages special page is added, and it allows adding pages to the watchlist.

I expect other developers would be interested on this as well, but I can help mentoring this (added).

In T177809#3813320, @Reedy wrote:

I suspect, it's possible to grep for this... But I imagine it would need some post-processing...
Grep for php files with a class in it, get the file name, group and order by file name.... and exclude if after grouping it's just 1?

Maybe it would be possible to extract from swift the list of files stored there? Then no HTTP requests would be needed (unless this shows that the problem lies on a different layer, of course).

Completely confusing indeed.

Rather than "prevent", I think the UI should offer to "replace" the existing request (conceptually equivalent to cancel + open new one, but nicer UI)

There is a third extension fighting for 'v' accesskey on edit page: FlaggedRevs.

I don't think it makes sense to have different actions depending on browser, either.

Thanks fo the answer, @Sagorika1996!

Let me also support the position of not restricting <templatestyles> to a specific namespace.

No problem. I was just reporting that the assumption that it was issued just once and never again turned out to be false.

Is this expected to be a private tool (only showing your own contributions) or a public one (you can view the contributions of any user)?

I just received this ghost notification a second time. This time with &uselang=en version:

I don't think there are any news to investigate here.
I get a "new device" notification every other day or so (but I don't login to the wiki everyday), since I enabled it as stated on T174263#3574597

I remember suffering silly self-conflicts. An additional issue is that ~~~~ magic expansion almost ensures that there will be a conflict, even if it could otherwise be automatically resolved.

@IKhitron By definition, if the system does something that it shouldn't be doing, it is a bug. You may consider it unlikely, or even that the reporter was wrong. But if we admit that it happened, well, how else would you categorize it? :)

I wonder if it is worth creating a course on Visual Basic 6 on 2017 (19 years after release, unable to create 64 bit apps, unsupported for ~12 years…).

1- That captcha is not accessible, is annoying (all captchas are to some point, though), slow to solve, sometimes ambiguous, and generally a pain to pass (even in the best case).

That's the bug. Supposedly, that shouldn't happen…