@Halfak The patch is currently waiting to be reviewed.

Hm, it seems to me the way forward here would be to include python-logstash and then add it as logging handler via the deployed logging_config.yaml.

I think this grew from some discussion back then, but given it had no clear goals and I don't think this is as relevant anymore, let's decline it.

In T147169#4498457, @jcrespo wrote:

No need to be sorry, could this be a load balancer bug?

In T196297#4278095, @Addshore wrote:

This means https://www.wikidata.org/w/api.php?action=wbgetentities&ids=L4-S1 for example should work

Ok, so I just looked into this again and removing the redundant languages after the summary is not easily possible. These are needed as it's possible to add/remove/change several glosses at once and still be able to denote their respective languages.

After discussing this with Lydia, we decided to change the message content and no longer append the language key. The message should look like this: "Changed [de] gloss of Sense L1-F1: foobar".

This will need some more love.

Hm, the message key for this is wikibase-lexeme-summary-set-sense-glosses (which is in line with wikibase-lexeme-summary-set-form-representations for form representations). Form representation change edit summaries currently render as: Changed representation of Form L1-F1: de-at: foo.

Keeping this open as https://gerrit.wikimedia.org/r/450968 still needs to be resolved.

One question I just came across… what language shall we show the available languages in? Shall we use autonyms (native names)? What about languages that are not in CLDR?

The respective patch has been merged into master.

Talking to @Addshore, we probably want to go for something along the lines of action=query&meta=wikibasecontentlanguages&context=gloss.

It seems that we do this differently for Monolingual texts atm: There this is handled via wikibase.WikibaseContentLanguages which is basically an access wrapper for mw.config.get( 'wgULSLanguages' ) (some languages supported by the backed are missing, though). This is being discussed in T124758.

I talked about this with @Lydia_Pintscher today and we agreed that the most viable option for this is to simply track the number of calls to each Lua function when they happen. Tracking the number of function calls per page cannot easily be supported by our current infrastructure (attaching this information to pages/ parser cache entries in an easily queryable way is hard).

In T201418#4485482, @Lucas_Werkmeister_WMDE wrote:

Thanks, should I rebase the patch against master and upload it on Gerrit as a regular change? (I assume we don’t need to bother with a pre-release announcement or anything for this extension.)

Deployed the above patch and result looks good: https://test.wikidata.org/w/api.php?action=wbformatvalue&format=json&datavalue={%22value%22%3A{%22id%22%3A%22L99-F2%22}%2C%22type%22%3A%22wikibase-entityid%22}&options={%22lang%22%3A%22en%22}&generate=text%2Fhtml%3B%20disposition%3Dverbose&property=P75109 (the < in asldflkd<sdfsfjsdlfkjsdf is correctly escaped).

If you prepare the patch, I can look into deploying this (unless @Bawolff wants to).

Fixed (see https://travis-ci.org/wikimedia/mediawiki-extensions-Wikibase/builds/411804223).

The scripts ran through fine. As already mentioned above, this should be fully working in a few hours from now (after caches have expired).

As both Wikis are already in wikidataclient.dblist, I just needed to run populateSitesTable.php.

@MarcoAurelio These are both tracking tasks for what needs to be in future security releases, so nothing specifically relevant for this.

(1) Run the set of scripts for generating propertypairs against a database dump.

AFAICT this is fully done now.

In T176277#4449950, @Marostegui wrote:

@hoo is this still something to be done?

Probably caused by 92e96427425126ffe11beb999808de675d47e674

@Ladsgroup Can you please clarify the scope of this task? Is this just about the IDs (I presume no)?

I just tested this with a JSON dump containing the first 2,500 Wikidata entries: The file size was reduced by about 9% (from gzip -9 to pigz --iterations 1 -11 -p1), but pigz --iterations 1 -11 -p1 is about 50 times slower than gzip -9 (0m7.977s user time to 6m41.077s).

This works:

I don't really know what to do with the user's comment here… I can't find an actual error on the wiki.

Fix will be deployed on Wednesday evening (UTC).

These log entries are stored with the user's local user id (not the meta one, but the one from the wiki where the filter was hit).

@ArielGlenn I could confirm that this works correctly on the current dump run:

This looks fine indeed. Thanks for checking, @Dalba.

Taking this over, per discussion with Jonas.

I'll evaluate this with @ArielGlenn before we can further increase the number of shards/dump runners.

In T178652#3820967, @Addshore wrote:

I'm going to first make a change in the dispatch script to check a mediawiki config var to see if it should actually run or not and backport this first.

@Lydia_Pintscher @Lea_Lacroix_WMDE What's the status here? Is this good to go?

Moving this back to "to do" as this isn't fully addressed AFAICT.

In T179155#4293641, @Lydia_Pintscher wrote:

Has it been added to the Lua documentation page?

There might be some difference in memory consumption or or time to deserialize to consider, but probably nothing too bad.

Once this is deployed (Thursday this week), we should gradually ask people to use this.

Even though this is a known problem, I don't think we have any tickets for this… we never considered this important, running the script is not time critical.

This is very close to a UBN (if not actually a UBN) :/

{{#invoke:Wikidatahelper|wdmatrix|objects=Q6491450,Q11960880,Q1776724,Q1797162,Q1797158,Q1797160|langs=sv,en,de,fr,es,it,da,no,fi,eo}} is what's troublesome on https://sv.wikipedia.org/wiki/Wikipedia:Wikipediafr%C3%A5gor/Arkiv_2017.