It's fine to broaden the advice of this piece of interface, but the original text is not wrong, it just doesn't address the requirements beyond the attribution to the author. That "manner specified by the author or licensor" is a reference to 3(a)(1)(A)(i) of the 4.0 license.

We got a report from Canada on #wikimedia-tech and I confirm I see the connection closed here in Finland as well, so it doesn't depend on the ISP.

$ LANG=en wget https://upload.wikimedia.org/wikipedia/commons/8/8e/Sunset_Toronto_Skyline_Panorama_from_Snake_Island.jpg
--2018-12-02 22:59:28--  https://upload.wikimedia.org/wikipedia/commons/8/8e/Sunset_Toronto_Skyline_Panorama_from_Snake_Island.jpg
Resolving upload.wikimedia.org (upload.wikimedia.org)... 91.198.174.208, 2620:0:862:ed1a::2:b
Connecting to upload.wikimedia.org (upload.wikimedia.org)|91.198.174.208|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 41624009 (40M) [image/jpeg]
Saving to: 'Sunset_Toronto_Skyline_Panorama_from_Snake_Island.jpg'

The test instance currently causes trouble: https://github.com/ipfs/distributed-wikipedia-mirror/issues/55 https://github.com/ipfs/distributed-wikipedia-mirror/issues/48 .

I've not seen this bug again, while I used to see it from time to time, so it might be fixed. I cannot find the original error in the logs so I cannot tell whether it stopped occurring...

I had to manually remove this suggestion yesterday and it still fails now.

I still see only Latin script usernames in https://tools.wmflabs.org/oabot/stats but I've not tested.

A workaround is now to alter the pywikibot generators manually in prefill.py. I'm fine if someone closes this, but I'll do so only after a test run.

In T194813#4211452, @Pintoch wrote:

As a lower hanging fruit, we can also "run OAbot on Wikidata", which would basically mean importing the ids to publication items. @Tpt and I started making a distributed game for that but I think a lot of these could be fully automated.

The local streaming works pretty well. I've tested many domains yesterday and there are only a couple where it just fails for whatever reason.

There are about a thousand left from previous bot runs:

$ ack-grep -l '"proposed_change": "url=http://www.ncbi.nlm.nih.gov/pubmed/' | wc -l
945

It was just a matter of low memory (I had reduced the parameter in jsub because the grid is overloaded). It needs at least 3 GB.

This is a valid report, thank you: it's very hard to collect such information.

https://commonsarchive.wmflabs.org/w/api.php commonsarchivewmflabsorg_w-20181019-history.xml.7z Error when uploading?

In T44318#4703281, @fdans wrote:

@Nemo_bis hey, is there a list of metrics you have that we could maybe develop with the current infrastructure?

This works (thanks bstorm and Platonides):

In T204503#4685608, @Krenair wrote:

Hey @Nemo_bis @Hydriz! Just a friendly reminder that you should get rid of your Trusty instances as described in https://wikitech.wikimedia.org/wiki/News/Trusty_deprecation#Cloud_VPS_projects.

In T204499#4678193, @zhuyifei1999 wrote:

@Nemo_bis I'm thinking of using WikiTeam to backup this wiki to archive.org. Do you think that would work? And could you assist with that?

I wonder if this is going to change the default URL as well:
https://www.zotero.org/blog/improved-pdf-retrieval-with-unpaywall-integration/

If scap now has problems with the l10n updates, it should be reverted to the version which did not have such problems, so that l10n updates can run while the rest is fixed.

FYI translatewiki.net is not a company or a product, it can't be "purchased".

To clarify: that discussion was about changing the "canonical" URL for all DOIs.

Google is known to not respect our canonical URLs, see T93550: Fix canonical URL issues (tracking). There might also be some special handling for the mobile site. It's not so much of a problem in itself to have extra URLs indexed as long as only the "right" ones actually show up in search results (e.g. mobile site to mobile user), but that's harder to track down.

The interwiki is discussed at https://meta.wikimedia.org/wiki/Interwiki_map .

I vaguely recall someone raising this point on wikitech-l some months ago, people asked for at least indicative figures on what kind of speed improvement you expect (10, 1, 0.001 %?).

Yes, there are a number of problems in the English text which make translation unnecessarily hard; thanks for reporting some. I was hoping to get a Phabricator component for the extension so that reporting is possible as normal.

The extension (and skin) needs a dedicated component in Phabricator for bug reports about the code itself.

In T203297#4562975, @Nikerabbit wrote:

@Nemo_bis says that the list of languages I took from the language selector is incomplete, though.

The weird language selector has:

The best way is to not ask an exception, since I doubt anyway that WMF has anyone to check dozens or hundreds of languages. But we can add the extension now and figure out the export later in the evening, before export time.

In T112715#3238144, @Nemo_bis wrote:

In T112715#2759884, @Ash_Crow wrote:

Instead of a URL shortener, wouldn't a Quarry-like (quarry.wmflabs.org) interface a solution? It would permit to save queries, share them, even fix typos in them without changing the public URL.

There was some more discussion about this at https://phabricator.wikimedia.org/T108557#3056937

Note that similar service provide their own URL shortening, such as osm.org short links

I'm sorry but having a non-accessible website whose HTML doesn't comply with standards and directly attacks disabled people *is* an important thing.

In T58845#4538197, @IKhitron wrote:

It was because clicking on this area calls "open user's talk page un read view" instead of "open user's talk page diff between last watched revision and the current one". It is just not helpful - you can't recognize all the changes.

In T200176#4534576, @stjn wrote:

If there’s any way to also include undelete, it should probably be done if we’re allowing deletion of those pages.

No more preferences please.

Now I see

Internal server error
<ExceptionInfo [oursql.PermissionsError: (1045, "Access denied for user 's52467'@'10.68.18.52' (using password: YES)", None)] (12 frames, last=Callpoint('oursql.Connection._raise_error (oursqlx/oursql.c:5885)', 183, 'oursql', 'connection.pyx', -1, ''))>

In T200297#4516990, @stjn wrote:

[...] The problem with some deployments is that they are irreversible. If Judgments will be rejected by any community in any events, will it leave a permanent unremoveable namespace for a wiki? [...]