Seems so. I suspect this is considered LanguageConverter syntax because -{ and }- get escaped, but { or } alone don't. Some other inputs also get escaped, like <script>alert("");</script>.

In T278658#6991639, @Func wrote:

In T278658#6991622, @Func wrote:

Oh, the problem is that title with big quote isn't a valid title, and unpaired big quotes broke the parsing process. Maybe we can check the title in lua module, with mw.title.new and check the return value...

And all wikitext with plain $2 (without nowiki marks) should move to lua module to not break parsing process.

T260699 demonstrates a use case for this in Sorani Kurdish.

In T278658#6984320, @Func wrote:

Maybe add <nowiki> mark around $1 can slove it.

In T274982#6965003, @Lea_Lacroix_WMDE wrote:

@matej_suchanek We thought of you because you are the creator of this module https://www.wikidata.org/wiki/Module:Constraints/SPARQL that uses the Query Service.

In T274982#6957815, @MPhamWMF wrote:

cc: @matej_suchanek @Mike_Peel
Not sure if you saw the announcement for the new WDQS Streaming Updater a couple of weeks ago, but it might be relevant to you that it no longer supports fetching constraint violations (I was informed you are among people who use this importing a lot). You may want to update your modules/bots in the near term.

In T249893#6700257, @Sophivorus wrote:

As an implementation note: the relevant edit to thank can surely be deduced out of the timestamp.

Reopening because I don't know how to solve it locally (other than by reverting T263258 or even T132729).

In T276668#6894185, @Patriccck wrote:

BTW when I click on the setting button, it will open #mw-prefsection-rendering. Would it be possible to add a link to the concrete section? For example, this link referees to the concrete section: #mw-prefsection-editing-discussion. Thanks in advance.

It would be good to find an example to reproduce this problem. I cannot reproduce it with the ones from the merged tasks. Perhaps it was recently fixed with T272712: property selector fallback is not falling back from language variant to major language.

Still getting an exception for the same query, although the fix is already in prod:
[YEOXDU@rKc0oxE97ffWbOAAAANU] 2021-03-06 14:51:57: Fatal exception of type „Error“

The first vertical dashed line corresponds to T271344#6833606, i.e. 1.36.0-wmf.27 -> wmf.30 deployment on group2 wikis.

Moreover, ChangesListHooksHandler::onOldChangesListRecentChangesLine is supposed to add some CSS classes (damaging, ores-highlight), but they cannot be found in the recent changes list as well. So I suspect from the code that the problem is in ChangesListHooksHandler::getScoreRecentChangesList (used in ChangesListHooksHandler but not in ContributionsHooksHandler).

I don't know how to submit translations for them, {{edit request}}?

They are translatable on Wikidata:

Whether it's a bug depends on whether the bot includes bot=1 in requests.

When I started working on this, I realized the following. Filter updates are much less common than filter runs (which happen in real time). So the cache will usually contain only a few entries if any. If we attempted to update the key for every filter after every action, it would be a no-op in 95-99%. Therefore, we should also have a cache entry which tells for which filters it makes sense to update the cache entry (probably one key for each filter group). @Daimona What do you think?

putting global variables in a fake "filter 0" would be a simple option that also denies the need for schema changes

I believe there is an error in Module:WikidataIB.
If you expand {{#invoke:WikidataIB|getValueByLang|P856|qid=Q1071969|fwd=ALL|osd=no|maxvals=1}} (used in Infobox software), it returns https://www.gnu.org/software/bison/, https://savannah.gnu.org/projects/bison/. These are two values, despite maxvals=1.

Still does not work in either backend (old and grouped)...

I requested one more improvement to improve compat. with BCE dates. But it solves a todo, it isn't really high priority: https://github.com/wmde/Time/pull/148

Well, I had some dirty untested stuff before I created the task, but don't have time to rebase it now. Feel free to go ahead.

My ideas are related to privacy. We have different privilege levels for viewing and editing public and private filters. If someone cannot see/edit private filters, but can create a public filter, they should probably see the shared variables. So they would have to be public. Per description:

+1

I think this is T61973. I believe Pywikibot should not handle this exception in any way (but a dedicated subclass wouldn't harm).

Patches are welcome.

rEWLE8282b1aa3ce468810b535cc966049f47c8381013

Verified, they are not shown on Special:NewPages.

FYI, I have just disabled all section links on the page in the task description using the magic word. But before doing so, I verified this was still the problem (described in detail by @matmarex above).