Moving this back to incoming (as this is not worked on right now)… not sure we even want this in the hearth currently.

In T309695#7988339, @awight wrote:

[...]
I'm proposing a new attribute and URL parameter that would look like,

<mapframe latitude="35.677" longitude="139.774" zoom="6" width="400" height="300" align="right" marker="center" />

and an URL like, https://maps.wikimedia.org/img/osm-intl,6,35.677,139.774,400x300.png?lang=en&marker=center

For most of the current problems the given patch should be good enough though (and it's definitely an improvement)!

In T277836#7909397, @Manuel wrote:

Yay, that was quick, thank you @hoo! I wonder what we could do to not get out of sync again in the future? Can we reduce the redundancy or do we need it and this is ultimately a process thing?

Done (rebased and deployed the above change by @Mbch331)! Now the lists match up:

hoo@deploy1002:/srv/mediawiki-staging$ mwscript eval.php --wiki wikidatawiki> $langs = \Wikibase\Lib\WikibaseContentLanguages::getDefaultTermsLanguages()->getLanguages();
> sort( $langs );
> echo md5(implode(':', $langs));
21b09a49bab76999c274d42a76c96d44

This causes the following inconsistency:

In T300667#7843473, @Simetrical wrote:

This should only be set if Title::loadFromRow is passed a row that has page_restrictions set. But, sure, cache eviction sounds like a reasonable idea here.

In T300667#7827144, @Simetrical wrote:

Yes, RestrictionStore doesn't manage its cache and it could in theory grow boundlessly. This is true for all the cache entries there -- I'd think oldRestrictions should be the least of the problem, since the vast majority of titles with restrictions shouldn't have an entry in it.

Even just adding empty string entries to the array can be troublesome, if done a lot.

I wrote a one-off script for this and ran it on tool forge:

I'll have a look soon (probably in early March, as I'm away-ish now).

I just created T301904 for finding and removing these invalid sitelinks. I suggest to close this task in favor of that one, as the specific issue mentioned here is solved.

The rebuildItemsPerSite script has finished for now and we got a total of 463 results. I ran the script for these results again, and two conflicts have been resolved now (thus we have a total of 461 conflicts).

This doesn't happen on master. After some looking, I found the context: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Kartographer/+/757913.

I found the bug leading to these site links: T301247.

Can the Community remove the remaining sitelinks on their own? If so, what would be an appropriate place where we could ask for this (and share the remaining cases)?

Could be caused by T300667, depending on how many title objects the dumper creates.

The problem here was that Q4039395 had a link to incubatorwiki (which I removed with https://www.wikidata.org/w/index.php?diff=1572146206&oldid=1572145482 … and that was fairly tedious). As we don't support linking to incubator, the client doesn't know about it (and there should be no sitelinks to it, ever).

Moving back to doing: The change will (probably) be deployed on Wednesday evening, after that I can start the script again.

Just for the recored: I needed to kill the script after it went through a big portion of Wikidata on December 16, as it was suffering from a massive memory leak (and it was threatening to OOM on mwmaint1002).

In T297347#7648387, @Lucas_Werkmeister_WMDE wrote:

The script looks alright to me – I remember reading something about how ORDER BY RAND() isn’t an ideal way to shuffle a collection (especially depending on the sorting algorithm), but it’s probably good enough here.

I wrote a one-off Python script for this which I ran on stat1007: It used a SQL query to get 10k random revisions from the last year (that were on non-redirect items). The "classifying" is a little hacky here, but probably good enough (also this is impossible to get fully right).
Script:

Related: T296014 (although this will only be available in the RDF output at first).

https://github.com/wmde/wikidata-mismatch-finder/pull/20

I'm not aware of a problem of any concrete issues we could tackle, other than T122520 which seems fine now. Mid-term we should really try to get rid of this, though, as Amir pointed out.

In T277862#7093619, @Michael wrote:

Can we robustly detect replication lag via the API? It might make sense to skip tests (or assertions) in those cases, rather than accepting them to flake because that will train us to ignore the real failures as well.

https://github.com/wmde/wdio-wikibase/pull/33

https://github.com/wmde/wdio-wikibase/pull/33

In T281587#7087337, @Ladsgroup wrote:

Technically this is done but it's test renable patch got reverted. I let you decide how to proceed here.

Moving this back into TODO to give someone else the chance to pick this up (as I wont work much more this week).

I superficially looked at all tests in question, and I think they all serve a value. The only test that is a little redundant is Lexeme:Lemma can be edited (which is mostly redundant with can be edited multiple times).