Private account of @Lucas_Werkmeister_WMDE (he/him, Berlin timezone). Anything I do here is on volunteer time, even if it looks work-related :)
- 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.
- 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.)
- 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.
Sun, Feb 28
Sat, Feb 27
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.
Fri, Feb 26
Wed, Feb 24
Sat, Feb 20
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.
Fri, Feb 19
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)?
Thu, Feb 18
Tue, Feb 16
Sat, Feb 13
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?
Thu, Feb 11
Wed, Feb 10
Sat, Feb 6
Fri, Feb 5
Wed, Feb 3
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
Mon, Feb 1
Jan 28 2021
Jan 27 2021
Jan 24 2021
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.
Jan 18 2021
Jan 17 2021
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