Are there strong arguments against just adding a second parameter to the function and default it to false? This way, it's not breaking anything and the new functionality is just introduced in a very smooth way. It occurs to me it would be the safest solution.

The HTML of the ArticlePlaceholder generated content pages look like this so far:

We might want to announce that to actually get feedback from the editors. Otherwise we can just assume what and how it changed from the numbers in the graphana board.

My Bachelor's thesis on Generating Article Placeholders from Wikidata for Wikipedia - Increasing Access to Free and Open Knowledge can be found here:
https://commons.wikimedia.org/wiki/File:Generating_Article_Placeholders_from_Wikidata_for_Wikipedia_-_Increasing_Access_to_Free_and_Open_Knowledge.pdf

Can you test if that's still the case @hoo ? Doesn't overlap for me.

I -2'ed the patch because we said it will bring up too many things in general and is a mess for performance reasons. We might say the $term string passed from special search to the AP's search hook should be longer than 5 characters to be considered for not prefixed search. This is an easy fix, but I'd need to know first whether it'd actually make a different performance wise. ( @hoo and @aude )

I have sadly no notes either. I vaguely remember something including "property" but honestly would prefer "statement" since it's more descriptive about the functionality and I think that weights for me more than making clear with the name how it is connected to {{#property:…}}

How should we proceed here? Should we wait for more translations? Or are we ready to enable the ArticlePlaceholder extension?

\o/

Thanks, I will look into it!