Wikidata-tech

wikidata-tech@lists.wikimedia.org

621 discussions

Fwd: [Wikitech-l] 2021 Community Wishlist Survey
by Mohammed Sadat Abdulai 17 Nov '20

17 Nov '20

Hello, The proposals phase of the Wikimedia Foundation Community Wishlist Survey 2021 has started. You can submit wishes in various categories, like Wikidata < https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Wikidata> The survey is open until November 30th and the evaluation phase will take place between 23 November and 7 December. Cheers, ---------- Forwarded message --------- From: Szymon Grabarczuk <sgrabarczuk-ctr(a)wikimedia.org> Date: Tue, Nov 17, 2020 at 7:58 AM Subject: [Wikitech-l] 2021 Community Wishlist Survey To: The 2021 Community Wishlist Survey[1] is now open! This survey is the process where communities decide what the Community Tech[2] team should work on over the next year. We encourage everyone to submit proposals until the deadline on 30 November, or comment on other proposals to help make them better. The communities will vote on the proposals between 8 December and 21 December. The Community Tech team is focused on tools for experienced Wikimedia editors. You can write proposals in any language, and we will translate them for you. Thank you, and we look forward to seeing your proposals! P.S. If the pages are not fully translated into your language, visit a dedicated page[3], be bold, and add the translations! [1] https://meta.wikimedia.org/wiki/Special:MyLanguage/Community_Wishlist_Surve… [2] https://meta.wikimedia.org/wiki/Community_Tech [3] https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Translation_… Kind regards, Szymon Grabarczuk (he/him) Community Relations Specialist Wikimedia Foundation <https://wikimediafoundation.org/> _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Mohammed Sadat *Community Communications Manager for Wikidata/Wikibase* Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de

1 0

Removal of noratelimit for bots on October 20th
by Léa Lacroix 13 Oct '20

13 Oct '20

Hello all, As you may know, over the past months we’ve been struggling with more and more bots editing Wikidata at a very high rate, causing infrastructure issues having an impact on the Query Service that couldn’t keep up with the changes and on tools such as Pywikibot <https://phabricator.wikimedia.org/T242081>. Over the years, we tried different things (like Add Wikidata query service lag to Wikidata maxlag <https://phabricator.wikimedia.org/T221774>, increase maxlag or factor <https://phabricator.wikimedia.org/T243701#5864130>, limit the edit rate for all accounts <https://phabricator.wikimedia.org/T184948>). Wikidata admins also approached individual bot owners to ask them to comply with the bot policy’s limit, sometimes without success. Recently, we discussed removing the noratelimit feature for the bots group <https://phabricator.wikimedia.org/T258354>. This would have as an effect to *limit the edits to 90 edits/min for most of the bots* ; the few bots that need an unlimited rate to function (for example MassMessage) can be added to the existing accountcreator group (with the possibility to rename this group). Many thanks to bot owners who gave input in the comments of the ticket <https://phabricator.wikimedia.org/T258354> and helped us frame this solution. If you want to continue the discussion, please have a look at these comments, so we can build from them and avoid restarting the discussion from scratch. We hope that this solution will allow a fair access to mass editing Wikidata, while preserving the existing infrastructure and avoiding hitting too hard on the Query Service. In the meantime we are working together with the Search Team at the WMF and others on improvements to the Query Service scalability and alternatives to it so some load can be redirected to other systems, as well as general infrastructure improvements. Unless there’s a strong opposition from the community to this change, we will implement it on October 20th. If you have any questions or need more information, feel free to add a comment in the ticket <https://phabricator.wikimedia.org/T258354> or onwiki <https://www.wikidata.org/wiki/Wikidata:Project_chat#Remove_noratelimit_for_…> to avoid too many messages on these mailing-lists. Thanks, -- Léa Lacroix Community Engagement Coordinator Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

1 0

What’s your experience with reporting bugs or feature requests to the Wikidata development team?
by Mohammed Sadat Abdulai 25 Sep '20

25 Sep '20

Hello all, Currently, various channels exist to report bugs or make feature requests related to the Wikidata software. You can for example leave a message Wikidata talk:Contact the development team/Process review 2020 <https://www.wikidata.org/wiki/Wikidata_talk:Contact_the_development_team/Pr…>, create a ticket on our task tracking system Phabricator with the Wikidata tag. You can also ask questions on the various social channels run by the Wikidata community, like the Facebook group, Twitter, or the Telegram group. We identified some issues with the current process from our perspective, and we would like to hear about your own experience, whether or not you already submitted a bug report or a feature request. After collecting all of this feedback, we will propose a reviewed and improved process for you to interact with the Wikidata development team. You can find more information about the project here <https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Process…> (current status, problems we identified, timeline). You are very welcome to give us feedback, either using this anonymous form <https://wolke.wikimedia.de/index.php/apps/forms/qXk3e2LM98ebLcJb>, or answering the questions publicly on this talk page <https://www.wikidata.org/wiki/Wikidata_talk:Contact_the_development_team/Pr…>. This feedback loop will run until September 30th. If you prefer giving feedback in person, we can also offer you a live call to talk about your experience! This call will take place on September 15th at 18:00 UTC <https://www.timeanddate.com/worldclock/converter.html?iso=20200915T180000&p…> on Jitsi <https://meet.wmcloud.org/WikidataCommunityFeedback> *Please avoid replying to this email if you have questions or feedback, but feel free to write on this talk page. <https://www.wikidata.org/wiki/Wikidata_talk:Contact_the_development_team/Pr…>* Thanks for your attention, Lea and Mohammed -- Mohammed Sadat *Community Communications Manager for Wikidata/Wikibase* Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de

1 1

[Significant Change] lib/WikibaseLib.php is no longer an entry point to the Lib extension
by Mohammed Sadat Abdulai 16 Sep '20

16 Sep '20

*(Apologies for cross-posting)* Hi all, This is an announcement of a significant change to 3rd party Wikibase installs that still use lib/WikibaseLib.php as an entry point. *On September 30*, we will remove the lib/WikibaseLib.php file from the Wikibase code. Wikis which directly load that file in their LocalSettings.php will then fail to load (after the 1.36 release of MediaWiki and Wikibase, if they do not track the master branch). The file lib/Wikibase.php used to be the entry point of the WikibaseLib extension. Directly loading this file has not been necessary since the earliest days of Wikibase – it was loaded automatically by the entry points of the Client and Repo extensions. Nevertheless, lines similar to the following found their way into some Wikibase installation instructions: require_once "$IP/extensions/Wikibase/lib/WikibaseLib.php"; If your LocalSettings.php contains such a line, please remove it. It has not been needed for ages, and soon it will stop working. This refactoring is part of a project with a twofold objective: (1) decouple the Wikibase Client and Repo as much as possible and establish a long-term strategy for organising the shared logic <https://doc.wikimedia.org/Wikibase/master/php/adr_0013.html>, and (2) get both Client and Repo to use the standard extension registration mechanism <https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Extension_registra…> to be loaded. The impact of the project is focused on developers who can now have a clearer view of the code, the modules involved, and their interactions which makes their lives easier. Also, the maintenance of the code is now easier. This is the phabricator board <https://phabricator.wikimedia.org/project/profile/4815/> of the project. If you have any issues or questions, please do not hesitate to ask. Cheers, -- Mohammed Sadat *Community Communications Manager for Wikidata/Wikibase* Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de

1 0

problem with bot test edits
by Seidlmayer, Eva 08 Sep '20

08 Sep '20

Hey, I'm not sure if this is the right place to ask, but I really do not know where to ask instead. When I try to make some test edits in the main instance with my recently accepted bot, I receive the message: "permissiondenied: You do not have the permissions needed to carry out this action." I am logged in with my User@bot-username and my bot-password and use Wikibase-CLI. What do I do wrong? Thank you very much! Cheers, Eva

2 1

[Significant change] New datatype fields in Lexeme JSON output
by Lucas Werkmeister 17 Aug '20

17 Aug '20

Hi all! This is an announcement for a significant (but not breaking) change to the JSON output of WikibaseLexeme entities, specifically of Senses and Forms, when obtained via Special:EntityData <https://www.wikidata.org/wiki/Special:EntityData> or the Wikibase API endpoints like Special:ApiHelp/wbgetentities <https://www.wikidata.org/wiki/Special:ApiHelp/wbgetentities>. The Snak output in the Wikibase JSON serialization <https://doc.wikimedia.org/Wikibase/master/php/md_docs_topics_json.html#json…> usually contains a datatype field for each Snak. Previously, these fields were missing for statements within Senses and Forms of a Lexeme – see the message on Project Chat <https://www.wikidata.org/wiki/Special:PermanentLink/1258923595#[Significant…> for an example (I didn’t want to bloat this email too much by including it here 🙂). Starting on 26 August 2020 (barring unexpected deployment issues; 25 August 2020 on Test Wikidata), these datatype fields will be present there as well. If you have any issue or question, feel free to leave a comment at T249206 <https://phabricator.wikimedia.org/T249206>. Cheers, Lucas -- Lucas Werkmeister (he/er) Full Stack Developer Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

1 0

Problem with SPARQL query: items which use a specific image (P18)
by Stephan Bösch-Plepelits 24 Jul '20

24 Jul '20

Hi! I have a problem with a SPARQL query. Hopefully you can help me. I'd like to get wikidata articles which use a specific image in the P18 property. I'm using this simple query: SELECT ?item WHERE { ?item wdt:P18 "item.jpg". } This works for some items, but not all. Example 1: SELECT ?item WHERE { ?item wdt:P18 "1936-ChirkovAntonNikolaevich.jpg". } -> returns "wd:Q16718402" (https://www.wikidata.org/wiki/Q16718402) Example 2: SELECT ?item WHERE { ?item wdt:P18 "GuentherZ 2010-02-27 0207 Wien10 Scheunenstrasse2 Bildstock.jpg". } -> returns nothing, although it is used by https://www.wikidata.org/wiki/Q33231166 This might be related to the following fact: Example 1A: SELECT ?item ?image WHERE { ?item wdt:P18 ?image. ?item wdt:P214 "307433452". } -> the field "image" shows a string "1936-ChirkovAntonNikolaevich.jpg" Example 2A: SELECT ?item ?foo WHERE { ?item wdt:P18 ?image. ?item wdt:P2951 "86578". } -> the field "image" shows a link to https://commons.wikimedia.org/wiki/File:GuentherZ%202010-02-27%200207%20Wie… with the text "commons:GuentherZ 2010-02-27 0207 Wien10 Scheunenstrasse2 Bildstock.jpg" (I also tried prefixing the query image name by 'commons:', like "?item wdt:P18 "commons:image.jpg") Please tell me if you have an idea how to solve this problem! greetings, Stephan -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,----------------------------------------------------------------------. | Stephan Bösch-Plepelits ❤ code ❤ urbanism ❤ free software ❤ cycling | | Projects: | | > OpenStreetMap: openstreetbrowser.org > openstreetmap.at | | > Urbanism: Radlobby Wien > Platz für Wien | | Contact: | | > Mail: skunk(a)xover.mud.at > Blog: plepe.at > Code: github.com/plepe | | > Twitter: twitter.com/plepe > Jabber: skunk(a)jabber.at | | > Mastodon: @plepe@en.osm.town | `----------------------------------------------------------------------'

2 1

[Config change] WikibaseClient example config will no longer define an example repo
by Lucas Werkmeister 20 Jul '20

20 Jul '20

Hi everyone! This is an announcement for a change to the example configuration of the WikibaseClient extension, which only affects Client wikis which are not also Repository wikis. If you don’t operate a non-Repo Client wiki, or if you don’t use the example settings, you can ignore this message. (Wikibase-Docker users, in particular, can ignore it.) The change will become effective on the master branch soon, and then in the future 1.36 release (but not yet in the upcoming 1.35 release). Currently, the WikibaseClient example settings (client/ExampleSettings.php or client/config/WikibaseClient.example.php) define an example Repo for the Client if the WikibaseRepository extension is not also being loaded. As we are moving towards using extension registration for Wikibase (T88258 <https://phabricator.wikimedia.org/T88258>), this will no longer be possible (extensions loaded using wfLoadExtension() are processed later, so the example settings file can’t detect if WikibaseRepo is loaded or not). Therefore, we will be removing this code from the Client example settings, and if your wiki is not also a Repo wiki, you will have to configure the Repo manually. (For wikis that are both Repo and Client, the default Client settings are sufficient, and nothing needs to be done.) This means that if your configuration (LocalSettings.php) currently contains a line like require_once "$IP/extensions/Wikibase/client/ExampleSettings.php"; or require_once "$IP/extensions/Wikibase/client/config/WikibaseClient.example.php"; but not a line like require_once "$IP/extensions/Wikibase/repo/Wikibase.php"; then you should copy the example settings <https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/7613b87c619…> into your configuration and adjust them as needed (at least the repoUrl, http://repo.example.org, is certainly wrong). If you already configure some of these client settings, then you can skip copying the corresponding example settings lines. We will be making this change on the Wikibase master branch very soon, so if you use the latest MediaWiki and Wikibase from Git, then you will probably have to update your configuration ahead of the next update too. However, the change will not be in the upcoming MediaWiki 1.35 release (or the REL1_35 Wikibase branch), so if you are sticking to release versions, you don’t need to change anything yet. That said, you could still update your configuration in preparation for this future change – the only potential problem with copying this block is the repeated define(), which may raise a PHP Notice, so you might want to wrap those two lines <https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/7613b87c619…> in an if ( !defined( 'WB_REPO_NS_ITEM' ) ) block when copying them (unless you stop loading the example settings altogether, which is also an option). I also want to stress that, while the eventual goal of this work is to load WikibaseRepo and WikibaseClient using extension registration (i. e., JSON files, not PHP entry points), we do not yet recommend that third-party installs do this. When Wikibase is fully ready for extension registration, we will send another announcement, and the PHP entry points will probably still be kept for compatibility for a good while longer even after they’re no longer required. If you have any issue or question, feel free to leave a comment at T257449 <https://phabricator.wikimedia.org/T257449>. For more information, see also T256238 <https://phabricator.wikimedia.org/T256238>. Cheers, Lucas -- Lucas Werkmeister (he/er) Full Stack Developer Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

1 0

BREAKING CHANGE: removing special pageterms behavior on repo wikis, use entityterms instead
by Lucas Werkmeister 15 Jul '20

15 Jul '20

This is an announcement for a breaking change to the pageterms submodule of the query API module, which only affects Wikibase repository wikis. If you do not use that API module, or only use it on client wikis (e. g. Wikipedias) and not on repository wikis (Wikidata, Wikimedia Commons), you can ignore this message. For years, the pageterms <https://www.wikidata.org/wiki/Special:ApiHelp/query%2Bpageterms> API module has served a double role: on client wikis, it returned the “terms” (Label, Description, Aliases) of the Wikidata Item linked to the given page(s), whereas on repo wikis, it would return the terms of the Item (or other Entity) on that page itself. For example, querying for the Label of Wikipedia:Village pump on English Wikipedia <https://en.wikipedia.org/w/api.php?action=query&prop=pageterms&titles=Wikip…> would return “Project:Village pump” (the Label of Q16503 <https://www.wikidata.org/wiki/Q16503>), but querying for the Label of Wikidata:Project chat on Wikidata <https://www.wikidata.org/w/api.php?action=query&prop=pageterms&titles=Wikid…> would not return anything, even though that page is linked to the same Item – you would have to query for the Label of Q16503 <https://www.wikidata.org/w/api.php?action=query&prop=pageterms&titles=Q1650…> instead. This behavior is inconsistent and also mixes repo and client concerns in a way that makes the Wikibase code harder to maintain. To resolve this, we introduced a new entityterms <https://www.wikidata.org/wiki/Special:ApiHelp/query%2Bentityterms> API module (a submodule of the query module, just like the pageterms module) which has the same behavior as the pageterms module currently has for Item (or other Entity) pages, and which is only available on repo wikis. If you want to get the terms of Q16503, you can now use action=query&prop=entityterms&titles=Q16503 <https://www.wikidata.org/w/api.php?action=query&prop=entityterms&titles=Q16…> instead of action=query&prop=pageterms&titles=Q16503 <https://www.wikidata.org/w/api.php?action=query&prop=pageterms&titles=Q16503>. (You can also use wbgetentities <https://www.wikidata.org/wiki/Special:ApiHelp/wbgetentities>, which gives you much more control over the returned data; pageterms/entityterms may be faster and can also be combined with other submodules of the query module.) On or shortly after 5 August 2020, we will remove the special repo behavior of the pageterms module, and it will then behave just like it always has on client wikis, and return the terms of the Item linked to a page, not the terms of the Item (or other Entity) on a page. (Because the new API module is already available on Wikidata, and you can start using it immediately, we are not making this pageterms behavior change available on Test Wikidata significantly before that date.) If you have any issue or question, feel free to leave a comment at T257658 <https://phabricator.wikimedia.org/T257658>. For more information, see also T115117 <https://phabricator.wikimedia.org/T115117>, T255882 <https://phabricator.wikimedia.org/T255882> and T256255 <https://phabricator.wikimedia.org/T256255>. Cheers, Lucas -- Lucas Werkmeister (he/er) Full Stack Developer Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin Phone: +49 (0)30 219 158 26-0 https://wikimedia.de Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us to achieve our vision! https://spenden.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

1 0

Uniquely Identifying Items Created by Bot
by Yusra Haider 10 Jul '20

10 Jul '20

Hi, I hope this is an appropriate question for this mailing list. I am a software developer at Reactome and am working on our bot that writes Reactome data to Wikidata. Our bot currently uses the property https://www.wikidata.org/wiki/Property:P3937 (the Reactome ID property) to identify and update Reactome items. We are running into the issue that this property is being used by other people and our bot inadvertently ends up changing items that have not been created by the Reactome bot. Is there any way to uniquely identify the items created by our bot? Thanks and warm regards, Yusra Hader

3 3

← Newer
1
2
3
4
5
6
7
8
9
...
63
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Wikidata-tech