@Smalyshev I've finally rebased https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/489447/ to be able to try this out.
I am setting up WikibaseMediaInfo extension locally now, but maybe you'd have a chance to give it a try before that.

I might not understand the particular problem clear enough, but regarding options listed

Update the baserevid when edit is saved

dupe of T223995 I believe.
If this is a deployment blocker now, we'll prioritize fixing.

Next steps:

• ArticlePlaceholder behaviour to be changed to skip missing/incomplete results for an input ID
• Investigate problems with the CirrusSearch/ElasticSearch index

Some archeology in ULS code bases has lead us to https://phabricator.wikimedia.org/T51847 and the related code change https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/UniversalLanguageSelector/+/69613/.
Based on our interpretation of the said bug report, and in particular the behaviour of the new code in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/UniversalLanguageSelector/+/69613/7/resources/js/ext.uls.init.js@123 (implementation details later changed, but behaviour seem to not have changed), we believe to have established that getFrequentLanguageList should include fil language code, in case it is provided by any of numerous data sources considered by the method.
In cases where both fil and tl are provided by the sources of language codes, both fil and tl should be included in the result of getFrequentLanguageList
It seems then, that filtering out language codes which are redirects should be the responsibility of the code using getFrequentLanguageList.

Thanks @Legoktm !

dumping a reference here so I am able to find in the future
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/511074/ (and the related commit in Wikibase https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/511076/ ) is some result of my lame attempt at the Prague Hackathon to get some PHPUnit tests of Wikibase running without loading MediaWiki. I've been doing this with the intention to try out parallelizing the unit test run, hoping for some speed improvements on multi-CPU machines.

http://wikiba.se/ontology-1.0.owl is now update.

I've add you to the Property creators group. I hope this helps

FWIW, https://wikidata.beta.wmflabs.org/wiki/Special:ListProperties?datatype=quantity lists number of Quantity properties, e.g. P937, and https://wikidata.beta.wmflabs.org/wiki/Special:ListProperties?datatype=wikibase-item provides a similar list of Item properties, e.g. P694

@matthiasmullie I'd happily make you a property creator on beta wikidata. What'd be your user name there?

Having looked at the gadget code and Wikibase API code briefly it might be tempting to see this as an issue with the "add sitelink" API call happening too fast after the removal. How often does this happen? Could we have some more data on failing cases (i.e. responses posted above are very useful, I'd still be a bit interested in the respective requests). I couldn't quickly reproduce the situation myself, I also don't want to make random edits on Wikidata to just debug the issue.

Thank you sir. So yes, it does look like oldid could go. And probably should, as what's the point of the additional complexity and source of errors, if it is not intended to be used?

This seem to have been done. Therefore closing this ticket. Feel free to re-open if I missed something.

This seem to have been fixed. Therefore closing this ticket. Feel free to re-open if I missed something.

Subtasks created (at least some), hence this investigation seems done to me. Therefore closing this ticket. Feel free to re-open if I missed something.

@Topway.it feel free to reopen if above suggestions, including updating your fork don't help. It seems to us the problem is no longer a case in the current state of the Docker repo.

@Addshore that sounds like an easy choice then. Would you say it makes sense to see number for some past month or so, to be 100% sure it was not some kind of one-day anomaly? On one hand, the difference seems so huge that I could see that it is not necessary, OTOH it is this huge difference which makes me think about an anomaly in the first place. To be clear, I don't have a strong preference on doing further analysis topic.

In T220402#5183351, @Krenair wrote:

May 14 08:24:34 <_joe_> and thanks for helping with that. In an ideal world, the teams developing new services would install them on beta
May 14 08:24:56 <_joe_> it might work out most of the times, but then we have people with no beta access, like wmde folks for termbox
May 14 08:31:15 <Krenair> Well, that's trivial to fix.

Looking at the WMDE people subscribed to this task...

Already have access:
Addshore
WMDE-leszek

Missing:
Matthias_Geisler_WMDE
Pablo-WMDE
Tarrow
Lea_WMDE
Jakob_WMDE

Are all the people on the 'Missing' list software engineers on the termbox project?

@BBlack @Dzahn: I have passed the topic of domain ownership transfer to the C-level ranks here at WMDE, and I have to inform that WMDE is not going to transfer the ownership of wikiba.se domain to WMF.
As I understand your statements above, this basically invalidates the whole idea of moving the hosting of the said website to WMF cluster.

@Mrjohncummings apologies for the suboptimal response time. At WMDE we're in the middle of getting two bigger features through the door, which steals the most of my focus currently.
I will personally have a look at those two bugs at Wikimedia Hackathon this weekend. I hope I will get some of my WMDE colleagues into the fun two. I believe I understand the description you were kind to provide above.
Will any of you folks @Mrjohncummings @NavinoEvans @Sebastian_Berlin-WMSE happen to be in Prague this weekend? It would be fun to poke this thing together!

FWIW, the PoC patch I've put together a while ago that should "fix" this is https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/489447/.
I am working my way to get the patch reviewable again

I’m also curious about your thoughts on T89432#5173026

Oh, It reminded me of WikibaseLexeme. https://github.com/wikimedia/mediawiki-extensions-WikibaseLexeme/tree/master/tests/phpunit/composer and https://github.com/wikimedia/mediawiki-extensions-WikibaseLexeme/tree/master/tests/phpunit/mediawiki (See https://github.com/wikimedia/mediawiki-extensions-WikibaseLexeme/blob/master/phpunit.xml.dist) We can do similar in core as well.

In T89432#5172991, @kostajh wrote:

I may work on this at the hackathon, help welcome!

@sbassett I'd agree that situation is not perfect even after our recent changes.
I believe the additional dependencies didn't add known vulnerabilities, but they're additional packages indeed. Also, some new issues have been discovered in "old" dependencies since the time you've checked.

@sbassett updated the comment above with the full set of new reports.

Hi again @sbassett. Hoping this would be useful update for you, I'd like to report on some improvements and changes that have happened in the last couple of days.

Hey @akosiaris and @mobrovac we've been wondering if you had a chance to look into our service again.
As reported above, to our best knowledge, we've made changes that have been stopping you from moving on with the helm chart.

Claiming this done as long as not proven otherwise in T215380.

We believe to have fixed to change the behaviour in T217741 so that the error is handled in the UI (i.e. exception is caught).
Is the error still occurring in logs?

Okay, so updating the site is remaining here.

Seems to be working

I closed it with sloppy fingers before checking, hence reopened right after noticing my mistake. Now looked again, and this looks done to me. Sorry for the noise.

Per discussion above, I'd call it declined as it does not seem to be sensible thing to do.

Nicely documented @Michael!