Opinions posted here are my own, unless stated otherwise
Apr 28 2021
Mar 20 2021
@dcausse: will anything bad happen if the URL comparison that is currently failing is removed? And is that applicable to people running their own Wikibase?
Mar 18 2021
@dcausse is it realistic to expect this bug to be fixed by Wikimedia in the near future? Several institutuions that we are helping with Wikibase adoption are running into it.
Mar 15 2021
Mar 12 2021
I've added the description message: https://github.com/ProfessionalWiki/EDTF/blob/master/i18n/en.json#L2
Mar 10 2021
Mar 9 2021
Thanks @Reedy. We now have message docs in qqq.json. Anything else that needs to happen?
Mar 8 2021
Mar 6 2021
We now have the messages in JSON format similar to MediaWiki: https://github.com/ProfessionalWiki/EDTF/tree/master/i18n
Mar 2 2021
Thank you abi_! We will use the MediaWiki i18n JSON format.
Mar 1 2021
The library now has GPL license and should be ready for TranslateWiki.
Feb 21 2021
And is there some recommendation on what to do in PHP? Is there a standard implementation we can use? Is using something like https://packagist.org/packages/gettext/gettext recommended, or is it better if we create our own thin wrapper?
Is there an technical documentation on how to interface with TranslateWiki? I guess there should be message files in _some_ format at _some_ location, but am unsure if there are any restrictions, preferences or best practices we should be aware off.
Feb 2 2021
Jan 22 2021
Use cases for DNB:
Looks like this is a QuickStatement issue that is already tracked: https://github.com/magnusmanske/quickstatements/pull/1
After the latest fix the extensions/OAuth/maintenance/createOAuthConsumer.php script is running without error.
Jan 19 2021
Props for the fast response!
Jan 16 2021
Jan 11 2021
Dec 23 2020
Dec 4 2020
Does anyone know to which degrees MW 1.35 and master run on PHP 8.0? (I understand there is no official support)
Sep 28 2020
We put the data type in a new extension. In retrospect perhaps we should have done that right away.
Aug 6 2020
Jun 29 2020
Jun 4 2020
May 4 2020
I think there is wisdom in "less is more" and that talk pages do not make sense for all wikis. A clean way to disable them would be nice.
Apr 16 2020
Apr 11 2020
In theory it could call wfLoadExtension()
It'd be nice to replace mediawiki/mw-extension-registry-helper provides with something simpler while retaining automatic enabling of dependencies. Can an extension somehow enable other extensions that it depends on when it is enabled? (We'd make this optional so you can define things manually/explicitly for WMF wikis.)
Apr 9 2020
Also seeing this issue
Apr 6 2020
Is this on some roadmap?
Apr 1 2020
Feb 23 2020
May 22 2019
May 19 2019
May 14 2019
May 5 2019
May 4 2019
May 3 2019
Ready for review: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/507954
One thing left in the maintenance script itself: support property id ranges. I will work on this today
Apr 24 2019
I think something along these lines makes sense, please comment here: https://github.com/wmde/doctrine-term-store/pull/8/files
I am also not happy with this task, as again it specifies a solution, not an outcome. I much rather have "avoid expensive cleanup during the request to the degree this is possible" as acceptance criteria in the story.
Apr 23 2019
We talked about this (two weeks ago?) and concluded there likely is no need to introduce anything in wikibase/term-store. I'm pretty annoyed with this task now since it specifies a solution rather than a problem that needs to be solved.
WikibaseImport contains a limited number of items and properties
This means we have to go with the "smart update using diff" approach, since otherwise we do not know which terms have been removed. Not clear to me it will make sense to do the cleanup in post-request, we might end up only delaying a few % of the cost. I suggest to first make it work on write and then see if we can gain a lot by moving stuff to a job.
I'm calling it a day. Current guess is that the tables are not created right because we are not using this setting in mediawiki/doctrine-connection.
There is some issues though. Some properties result in an error, and on re-run many of them do.
With https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/501992/ the rebuilding works using the Doctrine Term Store.
Apr 22 2019
@alaa_wmde what is the status of this?
AFAIK the script we currently have (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/505670) is sufficient for this task. It has continuation based on page id rather than property id. I figure that won't fly for items but likely is OK for properties. Do we need continuation at all for properties?
We already did some of this while working on the property script: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/505679
Apr 21 2019
Yesterday while thinking about design stuff I randomly realized that we might not need a script like this. Can't we just use https://github.com/Wikidata/WikibaseImport to important a bunch of real entities? If that is too slow, then perhaps we can use https://github.com/JeroenDeDauw/Replicator to import JSON dumps.
Apr 16 2019
Apr 14 2019
Apr 12 2019
Don't think it is a good idea to modify the existing RebuildTermSqlIndex code. We can just create a new script. The existing code has things in there we don't need, and still having the wb_terms specific thing around might be useful to various users.
@alaa_wmde is this done?