In T232716#5496614, @MarcoAurelio wrote:

From a quick look I think some message keys at https://github.com/wikimedia/mediawiki-extensions-Patroller/blob/master/i18n/en.json conflict with already-existing keys both in MediaWiki core and translatewiki.net extensions. I'm not sure that'd be a blocker here. Ping @Raymond.

In T232892#5494397, @matmarex wrote:

People are already re-translating the wrong message: https://translatewiki.net/w/i.php?title=MediaWiki:Visualeditor-linkcontext-label-change/pl&diff=prev&oldid=9005128. Can I do anything to help resolve this?

It happens still with 300 seconds as timeout:

In T230100#5473808, @abi_ wrote:

Couple of things,

1. Calculating group stats is quite fast, and the exporting the languages is what takes time.
2. The first export at 6:42 on the 6th Sept, 2019 actually took 380 seconds. Much higher than my manual run timings of 159 seconds. This could be due to,
   • Running multiple simultaneous exports slows down the speed of each individual one, possibly due to IO constraints.
   • Larger amount of translations performed.

I'll wait this week and keep monitoring.

BlueSpiceBlog disabled on translatewiki.net

Today was the first time since ~ 10 days that the export of core exceeds the limit of 600 seconds. Maybe the new log shows relevant information?

Yesterday and today the export worked well. I used above command without --quiet. No useful output.

The new timout of 10 minutes is not sufficient :-(

Increasing the timeout from 120 to 180 with https://gerrit.wikimedia.org/r/#/c/translatewiki/+/525803/ helps for the moment.

@Raymond , @abi_: What is to be done?

• I don't see ais, ami, or szy in Names.php, so I guess that szy should be added there.

After adding categories manually the warning/hint is still shown.

In T224812#5234276, @Jdforrester-WMF wrote:

In T224812#5232484, @Raymond wrote:

@Jdforrester-WMF Thank you for the very fast patch and deploy. But I am still getting the same error on Firefox. Purging page does not help and loading the page with denug=true neither.

Oh, sorry to hear that. I tested in production and re-confirmed just now on Chrome 74 and Firefox 68.0b7. Possibly ISP-level caching?

@Jdforrester-WMF Thank you for the very fast patch and deploy. But I am still getting the same error on Firefox. Purging page does not help and loading the page with denug=true neither.

Another user reported the bug to me for a webm file. Upload with special:upload worked instead

In T222546#5179312, @Nikerabbit wrote:

This was done in https://gerrit.wikimedia.org/r/c/translatewiki/+/509760 – again I am interested in reports about the duration.

@Nikerabbit Tested it this morning again. Happens again :-(

@Nikerabbit Again getting "Received disconnect from 2620:0:861:3:208:80:154:85 port 29418:12: Too many concurrent connections (4) - max. allowed: 4"

In T124758#5177460, @Lucas_Werkmeister_WMDE wrote:

It looks like @Raymond periodically adds them to our CLDR MediaWiki extension, as an addition to the upstream CLDR data (example change). I don’t know why they’re not displayed on the monolingual statements themselves (example statement, currently shows “sjn” instead of “Sindarin”), but we seem to have them in some form or other. (I guess this also answers @Sascha’s last question?)

In T222944#5174921, @Nikerabbit wrote:

I believe @Raymond did the renames.

Issue related to WBMI? Related to T221071?

Does this patch results into T222997?

In T220309#5160353, @WMDE-Fisch wrote:

In T220309#5155047, @Raymond wrote:

But I have another candidat to check: https://de.wikipedia.org/wiki/Datei:Bilet_RATT_1994.JPG . Two days ago I gave an OK for Commons but still I am unable to move it. Getting "The file cannot be imported, because it is not marked with one of the required licences.". Could this be a cache issue?

The file does not have an accepted template configured on https://www.mediawiki.org/wiki/Extension:FileImporter/Data/de.wikipedia . Although Bild-PD-Schöpfungshöhe is part of the Transfer section the FileImporter does not automatically consider this moveable in the current setup. There must be a template from the Good section present.

In T222309#5159912, @Nikerabbit wrote:

In T222309#5156677, @Jdforrester-WMF wrote:

oh, wow, yes, ExtraLanguageNames is not an appropriate disposition for this stuff (as it only works on one wiki, Wikidata, so e.g. clients of Wikidata won't recognise it). New language support for actual content should always go in MediaWiki itself in the normal manner.

That means putting them in LocalNames in the CLDR extension?

In T222546#5158738, @Nikerabbit wrote:

The above change is deployed. I would be curious to hear from @Raymond and @abi_ that 1) it works 2) how much it affects duration of exports.

Short test: None of the languages (besides nys for whatever reason) added via wmgExtraLanguageNames can be used as language in WBMI.
Furthermore they do not work together with the parser function {{#language:xx}}:

• Testpage Commons Beta

But they works on Test-Wikidata:

• Testpage Test-Wikidata.

It looks like https://en.wikipedia.org/wiki/File:High-water-392707_640.jpg could be moved now to Commons. I have *not* done it yet to let have @Lea_Lacroix_WMDE and team a look into it why it was not possible at time of reporting the bug.

The new repo EntitySchema is live on translatewiki.net now: https://translatewiki.net/wiki/Special:Translate/ext-entityschema?group=ext-entityschema