Blog: https://addshore.com
Twitter: https://twitter.com/addshore
Meta: https://meta.wikimedia.org/wiki/User:Addshore
Wikitech: https://wikitech.wikimedia.org/wiki/User:Addshore
🦓🐝🐢
Blog: https://addshore.com
Twitter: https://twitter.com/addshore
Meta: https://meta.wikimedia.org/wiki/User:Addshore
Wikitech: https://wikitech.wikimedia.org/wiki/User:Addshore
🦓🐝🐢
So, an interesting "tidbit" here is that MediaWiki does normally come with a default page.
However, I purposefully ignored it when creating the mediawiki schemas that get rolled out for all wikis
That page (or any other page) could get included agin if you copy over move content when making the schemas
https://github.com/wbstack/api/blob/main/database/mw/README.md?plain=1#L109
It sounds like the problem here might lie entirely within quickstatements from my understanding?
It looks like quickstatements does this mapping based on configuration
And the configuration that wbstack code provides is just wrong
How does this look?
At least adding a label or a description in one language is mandatory
Yup, right now arm isn't supported out of the box.
The easiest way to get there for the core feature set would be to move to more docker hub images rather than WMF maintained ones, which are often built to be cross platform.
But there would always be WMF images or production etc that do not have arm builds.
mediawiki-docker-dev is no longer supported anyway, so closing this sounds fine.
So one thing I'll note is that the limited access to settings is by design.
The idea of Wikibase cloud is it can easily scale to 1000s etc of wikibases and the limited set of functionality changes helps that.
MediaWiki and Wikibase individual settings are often far to fine grained to be useful when exposed to a wide group of users, and allowing free access to the settings can have undesired consequences.
The more settings that are exposed, and the more differently configured wikis the harder platform maintenance is.
I did some experiments a few years back (2021)
You can find my writeup from back then https://addshore.com/2021/02/testing-wdqs-blazegraph-data-load-performance/
This was mainly trying different Java and Blazegraph options to see how things changed the behaviour while loading data, but I also tried a bunch of different GCP hardware including different disk setups.
@bking Would it be possible to get me access to an R2 bucket that is paid for by the WMF in some way?
I'll happily continue my manual process of putting a JNL file in a bucket every few months for folk to use until the point that this is more automated?
In T343686#9090090, @Evelien_WMDE wrote:From Telegram, popular request is to introduce "Merge items" linking to /Special:MergeItems under the Wikibase section.
We'll definitely add this, anything else popping up here can be added on top.
The energy savings is possibly unclear, at least under current case (but that's partly because it's hard to know how much energy is being expended, which could be guessed at from number of dump downloads; not sure how easy it is to get those stats; this is different from the bandwidth transfer on Cloudflare R2).
From my side, everything that is in a cron there i believe should be in https://github.com/wikimedia/analytics-wmde-scripts
Specifically to see what is happening within the crons see https://github.com/wikimedia/analytics-wmde-scripts/tree/master/cron
I'm gonna work on actually publishing this soon :)
Adding some usage numbers to this task.
Of the JNL files that I am currently hosting on cloudflare, 4.28 TB traffic has been used in the past 30 days, which equates to roughly 3-4 downloads of the file.
Okay, scratch that, sudo mw update seems to work fine for me...
In 0.20.0 I removed any suggestions of running the commands with sudo as it complicates things internally.
See https://gitlab.wikimedia.org/repos/releng/cli/-/blob/main/CHANGELOG.md#v0200
The main premise of the ticket is solved, but this is blocked on merging the necessary bits to mwcli, currently we run a custom variant of the cli.
Though another thought with a wikibase perspective here would be that there should work for any wikibase out of the box and make sense, not being red links :)
Your best bet here is probably following the pattern of the `WikimediaMessages" extension
https://www.mediawiki.org/wiki/Extension:WikimediaMessages
This contains customized messages string for WMF production sites in comparison to default mediawiki and extensions..
Now visible on https://wmde.github.io/wikidata-map/dist/index.html
https://github.com/wmde/wikidata-map/blob/master/docs/data/DATA-NEW.md and https://github.com/wmde/wikidata-map/blob/master/docs/data/DATA-PIXELS.md still work as a documented process
2022 will remain skipped for now, as that data doesn't exist in hadoop right now (Might be able to backfill in the future)
I'll add some images to commons now too
You are now a reader of the project, not sure if that is enough.
If not poke me and I'll set you to a member
It seems this stuff has changed a little since I last looked
Video attached showing the path, but tldr, look specifically at commons contributions and go from there for a data edit
I imagine this issue currently happens in v0.20.0 +