Pywikibot, Wikidata, i18n, GLAM stuff
User Details
- User Since
- Oct 14 2014, 3:01 PM (396 w, 6 d)
- Availability
- Available
- IRC Nick
- multichilll
- LDAP User
- Multichill
- MediaWiki User
- Multichill [ Global Accounts ]
Thu, May 5
Wed, May 4
Is this upgrade supposed to be without impact? Does it impact the performance of the Swift cluster? I've got quite a few of these for the last couple of days:
Tue, May 3
Sun, May 1
Structured data is supposed to be the replacement of wikitext editing and the future. It's very broken for months now. Is nobody responsible for Commons anymore these days?
Mar 29 2022
Mar 12 2022
Thanks for implementing this. I finally got around to update https://www.wikidata.org/wiki/Module:Constraints so that pages like https://www.wikidata.org/wiki/Property_talk:P650 are not throwing a horrible alert anymore. I also filed T303670 to make the same constraint for descriptions.
Feb 7 2022
Feb 6 2022
Got a ping from @Aklapper about having tasks assigned to my name with no activity for a long time. This task doesn't ring a bell.
Feb 5 2022
Jan 25 2022
@TheDJ is currently actively deprecating the service, all tiles look like https://tiles.wmflabs.org/osm/18/136090/86311.png now
Jan 3 2022
Jan 1 2022
Dec 18 2021
Phabricator task to remove authentication: T297995
No, as a tool developer I don't want to authenticate, see https://commons.wikimedia.org/wiki/Commons_talk:SPARQL_query_service/Upcoming_General_Availability_release#Mandatory_authentication_considered_harmful . Filed T297995 to remove it.
Oct 4 2021
Sep 26 2021
Not sure why the Toolforge project was removed by @JJMC89 . A package is missing on the generic infrastructure affecting multiple tools. Also no mention of this on https://wikitech.wikimedia.org/wiki/Help:Toolforge/Pywikibot#Clone_pywikibot_git_repo
Sep 24 2021
Three groups of people are involved in this:
- MediaWiki API developers
- Pywikibot framework maintainers
- Pywikibot framework users
Sep 22 2021
This task is tagged as priority low. It would be completely ridiculous to push this through now knowing what amount of fallout this will cause.
Sep 19 2021
Sep 17 2021
Sep 13 2021
Added you to the group, see https://commons.wikimedia.beta.wmflabs.org/wiki/Special:ListUsers?username=&group=interface-admin&wpsubmit=&wpFormIdentifier=mw-listusers-form&limit=50
Good luck testing.
Aug 16 2021
Jul 31 2021
I expect encoding issues. How are you handling spaces and underscores for example? https://commons.wikimedia.org/wiki/File:Stilleven,_SK-C-1561.jpg gives <schema:contentUrl rdf:resource="https://upload.wikimedia.org/wikipedia/commons/f/f4/Stilleven%2C_SK-C-1561.jpg"/> in https://commons.wikimedia.org/wiki/Special:EntityData/M83614923.rdf and <ps:P18 rdf:resource="http://commons.wikimedia.org/wiki/Special:FilePath/Stilleven%2C%20SK-C-1561.jpg"/> in https://www.wikidata.org/wiki/Special:EntityData/Q18608269.rdf .
Jul 3 2021
I just noticed https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Non-free_content . Setting this one to declined because clearly no community consensus exists at this moment in time.
Jun 29 2021
Hi folks, please stick to the Phabricator etiquette as described at https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette . This is not the place to discus if these items should be moved out or not. @MPhamWMF don't see these comments as any indicator of the community view.
Jun 9 2021
I would like to have "If several languages are provided in the constraint then the constraint is satisfied if at least one of the languages has a label added" changed to "If several languages are provided in the constraint then the constraint is satisfied if all of the listed languages have a label added" (so not OR, but AND)
Jun 7 2021
Jun 2 2021
May 30 2021
May 29 2021
This new constraint would get plenty of usage, see https://www.wikidata.org/wiki/Help:Property_constraints_portal/Label_language
@dcausse thanks for the pointers. Might be worth switch structured data on Commons first to the new approach. It is much less integrated in all sorts of processes and it uses a ton of blank nodes or was Commons already switched? See for example P170 (creator) on https://commons.wikimedia.org/entity/M106076433.rdf for how blank nodes are currently used on Commons.
May 25 2021
I see the right concept uri on https://commons.wikimedia.org/entity/M105912167 now (and still the right one on http://www.wikidata.org/entity/Q106874575). Thanks for fixing.
May 22 2021
May 21 2021
When you say Wikibase do you mean Wikidata, Structured data on Commons or completely Wikibase in general? Judging from the context it's SDC so I would scope it on that. For the monuments database we define source fields, how they map to the destination and what kind of conversion to apply. You could do something like that.
I didn't notice this task before. Where can I read the feedback you got? From who did you get feedback?
May 14 2021
@Cparle @John_Cummings : Why are you discussion references in this task instead of in T230315 ? This task is about about serialization of the data and that the fact that we use two different keys (claims vs statements) for the same thing.
May 8 2021
May 7 2021
May 4 2021
Apr 29 2021
As a work around on pages like https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings/Old_European_art_missing_genre/Sweden where most thumbnails don't work:
wget -E -H -k -K -p https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings/Old_European_art_missing_genre/Sweden
Mar 20 2021
File names are bad URI's. Files get renamed all the time (see https://commons.wikimedia.org/w/index.php?title=Special:Log&offset=&limit=500&type=move ) causing all sorts of breakage. The pageid stays the same so the mediaid also stays the same. That's a much more stable identifier.
Mar 17 2021
Mar 7 2021
Mar 3 2021
Mar 2 2021
Why are we not using the description field for this? Seems more sensible to me than creating new properties
The URI for the image is https://commons.wikimedia.org/entity/M6919529 (yes, https, not http, that got messed up, see T258590). You can see an RDF representation of that at https://commons.wikimedia.org/entity/M6919529.rdf . We should someone include this URI on Wikidata too. The royal way would be to update the image data type which accepts the Mediainfo ID and does all the logic like the current image data type.
Mar 1 2021
Feb 27 2021
We now have more than 1 million files with location of creation on Commons, see https://commons.wikimedia.org/w/index.php?search=haswbstatement%3AP1071&title=Special%3ASearch
Feb 25 2021
Feb 21 2021
If it aint' broken, don't fix it? Let's just see what happens and if anything explodes, than focus on fixing that.
Feb 13 2021
Wrote https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings/Automated_image_uploads and shared the link by email some time ago.
Feb 9 2021
Feb 8 2021
This change is subject to the https://www.wikidata.org/wiki/Wikidata:Stable_Interface_Policy . Please complete the steps listed there.
Feb 2 2021
I obviously like getting more structured data and better usage, but I see some issues with this task: The scope seems to be very broad. Is this intentional? What kind of time investment is expected? Might have a higher chance of making a difference when it's more tightly scoped. We have several steps in the process and possible tasks related to it:
- Convert existing data from wikitext to structured data. This is already happening on a small subset, but on a large scale. Not controversial as long as you don't remove any data. Still a ton of work to do here, but quite a few things are not clear yet on how to model things. Building some kind of workflow to extract knowledge from the category tree and show it to users for approval would be extremely useful.
- Show the structured data in a pretty way. You already mentioned some examples, https://commons.wikimedia.org/wiki/Module:Artwork and https://commons.wikimedia.org/wiki/Module:Information . The current approach here is to do incremental improvements without changing the look and view from what it used to be. You can also take a radical different approach like skins: You make another implementation for the same data with a completely different look and feel. With some logic logged-in users can enable this new template skin. That way you can experiment quite freely without disturbing the Monobook people. This task would be fun for someone who is on the edge of development and design.
Jan 21 2021
Reasoning why the convention is suddenly enforced are missing. Instructions on how to fix are also missing.
Jan 18 2021
Jan 17 2021
@RKemper so what's the status of this? I see a lot of cases where the last edit didn't get processed so the data in SPARQL is not consistent. See https://w.wiki/ugf for some examples.
Jan 14 2021
Jan 6 2021
Just had it again:
pywikibot.data.api.APIMWException: internal_api_error_JobQueueError: [X-VEtQpAIDkAAHaGUqkAAADW] Caught exception of type JobQueueError
[servedby: mw1345;
errorclass: JobQueueError]
Jan 5 2021
Ha, right after I posted that my bot crashed twice. Now with internal API errors:
One of my robots ran non-stop for the last week so looks like it's not happening at the moment. You got to love intermittent problems.....
Jan 1 2021
Dec 29 2020
Thanks Sam, can you do a per user per year breakdown? I expect a small number of users with a lot of uploads.