2. Alright, that makes sense. (I’m more used to opening pull requests from forks, but I guess that wouldn’t scale well for you – I didn’t consider that.) Access should be granted now.

1. I forgot about qqq.json, I added some now. (I also noticed the i18n files were using underscores in the message keys, when hyphens would probably be better for you. Changed to hyphens now.)
2. Is this a requirement? I would prefer if translatewiki opened pull requests against the repository, rather than pushing directly. I need to manually do something to deploy the changes in either way, and this way, test failures due to translation issues won’t immediately break the build on the main branch.

In T275973#6867105, @Herald wrote:

As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!

As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!

Is there anything I can do to help move this along? As far as I can tell, with the work in the i18n branch, no tool-specific changes to translatewiki.net should be needed anymore – the JSON files should use the same format as everywhere else.

I would suggest to first try how the SDC UI fares with large statement lists, e.g. on a test wiki (Test Wikimedia Commons hasn’t been deleted yet), and see what kind of problems emerge, before implementing a solution.

Will this test suite also contain the objects needed to evaluate the inputs (functions, types, etc.), or are those expected to live somewhere else (e.g. WikiLambda’s data/ directory)?

This happens occasionally in the Wikidata Lexeme Forms tool as well, though I don’t have number for how often it happens. (Counting requests in ~/uwsgi.log would be misleading, since “bulk mode” requests can make hundreds of API requests, each of which can (apparently) fail with this error.)

Any chance you can take a look at that i18n branch and see if the message files look alright?

In T272243#6771813, @LucasWerkmeister wrote:

The formatters have some documentation in formatters.py; apart from that, the messages are plain text – there has been no need for any kind of markup (wikitext, markdown, …) so far.

I looked a bit into the code and I’m pretty sure that this is because Wikibase’s StatementEntityReferenceExtractor is stateful (has $this->entityIds, never clears them). WikibaseLexeme’s NoCrossReferencingLexemeStatements uses the same LexemeStatementEntityReferenceExtractor to extract referenced entity IDs from both lexemes, and the LexemeStatementEntityReferenceExtractor contains a StatementEntityReferenceExtractor which, due to the way it’s written, will return any IDs it already found on future extractEntityIds() calls, so when WikibaseLexeme has

See also T202725: API: When creating a Lexeme with wbeditentity API the result is confusing and mixed.

I see translations are currently here: https://github.com/lucaswerkmeister/tool-lexeme-forms/blob/main/translations.py. Would it be possible to have them in one per language? Also something like JSON would be easier to parse.

I suppose so, yes.

Yup, AC/DC CI is also back up. Thanks @Daimona!

AbuseFilter seems to be having issues on the Beta cluster – doesn’t look like something that would be Beta-specific, so probably worth keeping an eye on: T272248: AbuseFilter-triggered API errors on Beta Commons: FilterRunner::checkFilter() must be an instance of ExistingFilter, instance of Filter given