Wikidata:Contact the development team

(Redirected from Wikidata:DEV)

Contact the development team

Wikidata development is ongoing. You can leave notes for the development team here or report bugs on Phabricator. (See the list of open bugs on Phabricator.)

If you have questions or bug reports related to the Wikidata Query Service or search on Wikidata, please add them to this page. If you have suggestions or requests regarding the entity suggester ranking, please see this page.

On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2020/09.

Development plan Usability and usefulness Status updates Development input Contact the development team

Conversion to external-idEdit

For Jewish Encyclopedia ID (Russian) (P1438) there is clear consensus for conversion, the only impediment were constrain violations, which I have now cleaned. Thank you in advance, --Epìdosis 11:33, 26 August 2020 (UTC)

Noted! Are there any other properties on the way to get a consensus, so we could run a conversion batch with 5 of them or more? Lea Lacroix (WMDE) (talk) 15:29, 26 August 2020 (UTC)
@Lea Lacroix (WMDE): I think it will be the only one for a while :( --Epìdosis 12:48, 30 August 2020 (UTC)
Alright! We'll try to make it happen as soon as possible. Lea Lacroix (WMDE) (talk) 09:55, 7 September 2020 (UTC)

Fix typo requestEdit

I noticed that on Dagbani (Q32238), in the column language, it is wrote “dagbanli” instead of “Dagbanli”. It is possible to change? Thanks in advance!!! -- 03:34, 29 August 2020 (UTC)

Hi We're currently looking into it. -Mohammed Sadat (WMDE) (talk) 11:18, 2 September 2020 (UTC)

True duplicates are no longer editable (August 29)Edit


Q96002185 can't be edited as the same enwiki sitelink is on Q96002184. I'm not sure if this is a step forward or backward from the previous situation. For some reason, it now leads to a crash of QuickStatements. How could this be improved? --- Jura 06:42, 29 August 2020 (UTC)

Other sample: Q97154094 (of Q97154095). --- Jura 05:21, 30 August 2020 (UTC)
Sample of today: Q97154088 and Q97154089 --- Jura 09:30, 13 September 2020 (UTC)

Connecting newly created articles to existing objects resp. creating new object - additional step when creating articles, categories, etc.Edit

Hello, the problem of connecting newly created articles to existing objects respectivley creating new objects for unconnected pages (when, by whom, how to avoid duplicates amongst the currently 93 million objects, ...) for hundreds of newly created articles per day in different language versions has been discussed for years now again and again without a solution. @ArthurPSmith: suggested at Wikidata:Requests for permissions/Bot/RegularBot 2 a possible solution: An additional step after saving a newly created article etc. to present to the user a list of possible matching wikidata objects (e.g. a list of persons with the same name; could be a similar algorithm as the duplicate check / suggestion list in PetScan, duplicity example) or the option to create a new object if no one matches. From my point of view, one current problem is, that a lot of creators of articles, categories, navigational items, templates, disambiguations, lists, commonscats, etc. are either not aware of the existance of wikidata or did forget to connect a newly created article etc. to an already existing object or to create a new one if not yet existing (which leads to a lot of duplicates, if this creation respectivley connection is not done manually, but by a bot instead, which have to be merged manually). Thanks a lot! --M2k~dewiki (talk)

Also, it would be helpful to have one page per WD WikiProject that gets automatically filled with items from that field (use WP categories to map if sitelink exists), and that have neither P31 nor P279 statements. --SCIdude (talk) 14:42, 31 August 2020 (UTC)
This would be a job for a bot operated by the community. I actually do have something similar in use for a single project. While I would not want to operate such a bot by myself, I would be willing to share my code if someone is interested (Python/pywikibot). —MisterSynergy (talk) 17:26, 31 August 2020 (UTC)
Also User:Pi bot operated by @Mike Peel: does a great job with connecting to existing objects or creating new ones if not existing for items regarding peoples (currently only for the english wikipedia, until june 2020 for about one year also for the german wikipedia, Thanks a lot to Mike! - In my opinion this should be reactived also for the german wikipedia). Of course, the algorithm could be improved, for example by also considering various IDs (like GND, VIAF, LCCN, IMDb, ...). The algorithm is described here: User_talk:Mike_Peel/Archive_2#Matching_existing_wikidata_objects_with_unconnected_articles. I have also created these two pages: User:M2k~dewiki/Tools/Create Objects and User:M2k~dewiki/Tools/Enrich Objects for the german language wikipedia. The first one might help to find and connect unconnected articles, categories, templates, ... from de-WP to existing objects respectivley to create new wikidata objects. The second one might help to enhance existing objects with IDs (using HarvestTemplates for GND, VIAF, LCCN/LCAuth, IMDb, ...) or other properties (e.g. using PetScan based on categories). Parts of the functionality of these two pages could be implemented in specialized bots. --M2k~dewiki (talk) 17:58, 31 August 2020 (UTC)
@M2k~dewiki: It could even be a step earlier - in at least some language wiki's when you do a search and there is no match, in addition to the red link to create a new article it lists matching Wikidata items if any - see here for example in Indonesian wikipedia. Could there be some way to encourage selecting one of those matching items as part of the create-a-new-item process, rather than just clicking on the red link? It would obviously require a significant UI change there, but then you have that link right at the start of creation, and could possibly pull in info (like id's) from the related Wikidata item immediately as part of writing the article, if that was wanted. ArthurPSmith (talk) 14:44, 31 August 2020 (UTC)
Also, if someone uses the "translation function" to create a translated article in another language version, then the new translated article could be connected automatically to the object of the original article. And after a version import (after a translation), at the moment often the link to the Wikidata object gets lost and the article has to be reconnected again a second time manually. --M2k~dewiki (talk) 14:50, 31 August 2020 (UTC)
@M2k~dewiki, MisterSynergy, ArthurPSmith: The only way this is going to work in the long term is that Wikipedia editors have to *want* to connect the articles to Wikidata, otherwise you're just going to ask them to extra steps for reasons they don't understand, and they won't want to do that extra work. I think the way to do that is to embed Wikidata in articles, and to do so in a useful way. We're getting there, but we're not there yet. Thanks. Mike Peel (talk) 21:30, 3 September 2020 (UTC)
@Mike Peel: Also see Wikidata:Client editing prototype / Wikidata Bridge; regarding embedding data in the german wikipedia also see de:Wikipedia:Umfragen/Normdaten aus Wikidata (de:Wikipedia Diskussion:Umfragen/Normdaten aus Wikidata) and de:Wikipedia:Meinungsbilder/Nutzung von Daten aus Wikidata im ANR. --M2k~dewiki (talk)

Distruptive edits by the iOS appEdit

I wasn't aware of significant amounts of edits by the iOS app. An IP seems to create a lot of wrong edits of descriptions where the user who doesn't understand Wikidata's policies changed Wikidata's description. There seem to be multiple issues here.

1) The agreement with Enwiki is that the app should use Enwiki short descriptions and not Wikidata descriptions. It's unclear why the iOS app accesses English Wikidata descriptions. If the iOS app doesn't follow the agreement that set the policy for the Android app, that has a potential for creating conflict.

2) Apps shouldn't make anonymous edits to Wikidata.

3) When it comes to the Android app we talked 1-2 months ago about making it clear to the user that Wikidata descriptions are lower-case. If the iOS app wants to edit our descriptions it should follow along.

I don't know who's responsible for the iOS app. Can you forward the message? ChristianKl❫ 20:47, 2 September 2020 (UTC)

Hi Christian, thanks for reporting these issues, I will indeed get in touch with the iOS app team so they can have a look at it. Lea Lacroix (WMDE) (talk) 09:07, 3 September 2020 (UTC)
Edit: @Johan (WMF): Can you help with this? Thanks a lot! Lea Lacroix (WMDE) (talk) 09:58, 3 September 2020 (UTC)
Hi ChristianKl. Let me see if I can give some answers. First, to explain the logic behind editing in the apps, as we see it: At the core, the apps are typically just another interface to Wikipedia in particular and the Wikimedia wikis in general, and follows the same principles. Typically, there is little difference between the mobile web and the app in how you can edit the wikis, for example. I would consider this like any other unregistered editor, be it from desktop, mobile web or an app. Is there a particular reason why the app would be treated differently from e.g. mobile web here?
What we don't do is to invite people to edit (in the apps in the Android feed) unless they have a registered account, because we don't have the tools to handle that in a sensible way and it would overwhelm Wikidata quality control. That is handle according to a separate logic, as it encourages newcomers to make many edits, whereas the apps in general don't. I understand that what you linked to looks a lot like what you'd expect from a feed, but this is someone who has decided to go on an editing spree like one could do from any interface.
The iOS app always prioritises the local English Wikipedia description. It does, however, show the Wikidata description when no local description exists and what is shown is editable.
I will point out the iOS developers that the Wikidata description editing is very visible in the app, and even though iOS doesn't have the feed (the context we talked about a while ago), it could still be useful with a hint here. Thanks for mentioning it. /Johan (WMF) (talk) 17:58, 3 September 2020 (UTC)
See phab:T261977 for the iOS ticket. /Johan (WMF) (talk) 18:57, 3 September 2020 (UTC)
@Johan (WMF): the problem Christian was specifically referring to was the fact that the iOS app auto-capitalized descriptions against Help:Description#Capitalizaton. --Prahlad (tell me all about it / private venue) (Please {{ping}} me) 19:30, 4 September 2020 (UTC)
Reminds me of phab:T131013 (2016) --- Jura 05:20, 5 September 2020 (UTC)


sr-el looks like it's not working when added to user page so Serbian in latin script not working on items. Eurohunter (talk) 14:51, 3 September 2020 (UTC)

  Info The Serbian community members might want to rename this and sr-ec to use sr-Latn and sr-Cyrl in the future, though, I missed which Phabricator task this is related to. --Liuxinyu970226 (talk) 13:23, 4 September 2020 (UTC)
Hi Eurohunter, do you mean that when you add sr-el to your babel template it doesn't work? Or that it doesn't appear under your languages in the termbox? -Mohammed Sadat (WMDE) (talk) 08:08, 7 September 2020 (UTC)
@Mohammed Sadat (WMDE): It doesn't appear under languages when you want to add label or desription in any Wikidata item. Eurohunter (talk) 16:11, 7 September 2020 (UTC)
Eurohunter, Liuxinyu970226! We're going to look into it: phab:T262269. -Mohammed Sadat (WMDE) (talk) 12:56, 8 September 2020 (UTC)
@Mohammed Sadat (WMDE): Thanks. I can add that some languages also has no polish translations in so called termbox. Eurohunter (talk) 14:27, 8 September 2020 (UTC)
Can you please list those lanaguages so that we can take a look? -Mohammed Sadat (WMDE) (talk) 07:23, 9 September 2020 (UTC)

Query entitiesEdit

Hello. I have seen that there are some properties that make use of SPARQL queries (Wikidata SPARQL query equivalent (P3921) and kinship equivalent in SPARQL at Wikidata (P4316)), however this seems very nonintuitive. Are there any plans to have more intuitive ways of storing and displaying queries in Wikidata?--MathTexLearner (talk) 23:16, 4 September 2020 (UTC)

Thanks for your question. Yes, there are plans to store and display Wikidata queries in new ways, although they are not concrete yet. Most of the plans are related to generating and maintaining lists from Wikidata on Wikipedia (automated list generation). Lea Lacroix (WMDE) (talk) 11:32, 14 September 2020 (UTC)


Hello. Could you please enable the linguistic code for lexemes 'zxx' with the tagname 'no linguistic content'? I would like to use it for LATEX words/symbols under the category zxx-x-Q5310. See discussion here.--MathTexLearner (talk) 07:35, 6 September 2020 (UTC)

Thanks for your request. I continued the discussion here as I first need to understand why we need a code that means "no linguistic content" on a project that is specifically about linguistic content. I'd like to have input from the community about it. Lea Lacroix (WMDE) (talk) 09:20, 7 September 2020 (UTC)

June 31stEdit

Hello, I've have found out by making a typo that the UI allows to save erroneous dates like 2020-02-31, 2020-06-31, etc. Shouldn't there be a control that prevents such errors? Ayack (talk) 11:59, 7 September 2020 (UTC)

  • As far as I understand it's by design because sources can list such dates. I think the date UI is generally bad. It doesn't allow specific timing on when in a day an event happened. The way to state inaccurate dates laid out in (and ISO 8601:2019) is much more useable then our system of handling unaccuracy. ChristianKl❫ 13:51, 7 September 2020 (UTC)
As Christian mentions, the UI allows such dates because there can be a need for them (for example February 30 (Q37096) of February 31st being used for example on fictional tombstones). One of the principles of Wikidata is to allow exceptions and to not block them a priori. Maybe a constraint could solve the issue by informing the editor that the date they just entered is likely wrong? Lea Lacroix (WMDE) (talk) 14:15, 7 September 2020 (UTC)
It makes sense, but, yes, such a constraint could be useful. Thanks. Ayack (talk) 12:50, 8 September 2020 (UTC)

add language code "lij-mc" for monolingual texts phab:T254968 (September 8)Edit

Could we move ahead with the above? It has been almost three months. For more samples, see .

@Amire80, Mbch331, Lea Lacroix (WMDE): --- Jura 12:30, 8 September 2020 (UTC)

Thanks for the ping. I approved it in Phab. Sorry I missed the examples earlier. --Amir E. Aharoni {{🌎🌍🌏}} talk 12:35, 8 September 2020 (UTC)
Now there's approval I can make the patches. Mbch331 (talk) 15:49, 8 September 2020 (UTC)
And the patches have been submitted. Mbch331 (talk) 17:56, 8 September 2020 (UTC)
Thanks Amir and Mbch331! We will review the patches as soon as possible. Lea Lacroix (WMDE) (talk) 07:49, 9 September 2020 (UTC)

Missing QIDsEdit

Any idea why most QIDs get skipped at Special:NewPages?


  • 17:10, 9 September 2020 ‎(Q99051383) (hist) ‎[764 bytes] ‎RegularBot (talk | contribs) (‎Created a new Item: Bot:
  • 17:10, 9 September 2020 (Q99051380) (hist) ‎[600 bytes] ‎RegularBot (talk | contribs) (‎Created a new Item: Bot:
  • 17:10, 9 September 2020 ‎(Q99051378) (hist) ‎[5,348 bytes] ‎NordNordWest (talk | contribs) (‎Created a new Item: Item duplicated from Q99051178)
  • 17:10, 9 September 2020 (Q99051376) (hist) ‎[798 bytes] ‎RegularBot (talk | contribs) (‎Created a new Item: Bot:
  • 17:10, 9 September 2020 ‎(Q99051372) (hist) ‎[598 bytes] ‎RegularBot (talk | contribs) (‎Created a new Item: Bot:
  • 17:10, 9 September 2020 ‎(Q99051370) (hist) ‎[522 bytes] ‎RegularBot (talk | contribs) (‎Created a new Item: Bot:
  • 17:10, 9 September 2020 ‎(Q99051366) (hist) ‎[530 bytes] ‎RegularBot (talk | contribs) (‎Created a new Item: Bot:

Malfunctioning bot? --- Jura 17:19, 9 September 2020 (UTC)

See the next section.--GZWDer (talk) 18:11, 9 September 2020 (UTC)
It's unclear if the old bug has any link to your and/or someone else's bot activity. --- Jura 11:43, 12 September 2020 (UTC)
A cause for this problem might be, that in the last few days some indexes are updated not immediately, but with a delay of some days. For example this Petscan result should show only articles without wikidata objects. In the last days, also entries are shown, where the articles already have been connected to a (new or existing) wikidata object. --M2k~dewiki (talk) 13:34, 12 September 2020 (UTC)
Also see Wikidata:Project_chat#Missing_increments_for_new_creates_Items. --M2k~dewiki (talk)


Due to some recent issue, I would let the development team notice a situation that exists since the very first day of Wikidata: When somebody failed to created an entity (including: label/alias or sitelink confilct, AbuseFilter, block, etc), a QID is lost forever. However, there are no any way to find the user doing so, and even if the user is found and blocked, QIDs will still be skipped when the user try to create an entity. Prior to phab:T213817, the issue is more severe as anyone can launch a DoS atteck without easy way from being detected. However, T213817 only mitigate the issue, but not completely resolve the issue (It can still cause unmanagable higher database load).--GZWDer (talk) 18:10, 9 September 2020 (UTC)

Thanks for reporting. I'll talk about it with the team and we will certainly add more details on Phabricator. Lea Lacroix (WMDE) (talk) 13:24, 10 September 2020 (UTC)

What’s your experience with reporting bugs or feature requests to the Wikidata development team?Edit

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 here, 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 (current status, problems we identified, timeline). You are very welcome to give us feedback, either using this anonymous form, or answering the questions publicly on this talk page. 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 on Jitsi.

Thanks for your attention, Lea Lacroix (WMDE) & -Mohammed Sadat (WMDE) (talk) 13:22, 10 September 2020 (UTC)

Deploy Citoid integration?Edit

I noticed that on there you can generate automatic references, but this is not available here. Is there any time estimate when this will be deployed or are there unresolved issues? Best --Pyfisch (talk) 12:10, 17 September 2020 (UTC)

Apostrophe bugEdit

Hello, a little bug I've just found: I searched "François Lemaçon d'Ormoy". Since there was no result, I clicked on the link below to create it, but it gave me a wrong label: "François Lemaçon d'Ormoy". Ayack (talk) 18:26, 17 September 2020 (UTC)

Thanks! I think that message is configured at MediaWiki:Search-nonefound, not directly related to Wikibase, so it’ll need to be fixed by the community if I’m not mistaken. (I’m not sure if it’s possible to fix it, but there might be some wikitext tricks I’m not aware of.) --Lucas Werkmeister (WMDE) (talk) 09:02, 18 September 2020 (UTC)
@Lucas Werkmeister (WMDE): The issue is not with the message. See [1] for example. It is with the proposed label in Special:NewItem. Ayack (talk) 09:43, 18 September 2020 (UTC)
@Ayack: I still think the issue is with the message. The message links to, which produces the label toto d'Ormoy; I think it should instead link to, which sets the label to toto d'Ormoy as it should be. (CC Matěj Suchánek, who created/edited the message on --Lucas Werkmeister (WMDE) (talk) 10:10, 18 September 2020 (UTC)
I thought we had fixed it long time ago. I'm not sure if these my changes were supposed to fix it: [2]. Do you, Lucas, happen to see how the message should be changed? --Matěj Suchánek (talk) 10:41, 18 September 2020 (UTC)
Very strange, on my sandbox that wikitext seems to do the right thing. Maybe the search page already escapes the search string before it’s passed into the message? --Lucas Werkmeister (WMDE) (talk) 13:18, 18 September 2020 (UTC)
Ah, yes – the text is already wikitext-escaped:
// If we have no results and have not already displayed an error message
if ( $num === 0 && !$hasSearchErrors ) {
   $out->wrapWikiMsg( "<p class=\"mw-search-nonefound\">\n$1</p>", [
      $hasOtherResults ? 'search-nonefound-thiswiki' : 'search-nonefound',
      wfEscapeWikiText( $term )
   ] );
I don’t know of a way to undo this in wikitext (though I assume you could selectively fix individual pairs using something like {{#replace:$1|&#39;|'}}); maybe we should add a second, unescaped message argument to the search-nonefound message, so that the Wikidata version of the message could use $1 when showing the search string but $2 when building the link. --Lucas Werkmeister (WMDE) (talk) 13:31, 18 September 2020 (UTC)

flavor=dump duplication (August 12)Edit

The other day I read that this is used for query server updates. Sample:

It includes some duplication not present on query server rdfs:label is repeated as skos:prefLabel, schema:name

Maybe that part should be skipped. --- Jura 07:09, 12 August 2020 (UTC)

Updated the above link to "ttl" (from rdf). --- Jura 15:10, 17 August 2020 (UTC)

@Lydia Pintscher (WMDE): what do you think? --- Jura 09:08, 19 August 2020 (UTC)

This format is used in other places than the Query Service, therefore changing it would be a breaking change. We don't see a strong reason to touch anything at this point. Lea Lacroix (WMDE) (talk) 10:24, 19 August 2020 (UTC)
There are two ways of solving this redundancy: either use a different function to update the query server or remove it from this.
Given that it's triggered by every edit, even a single additional element is likely to have a large impact. @Lydia Pintscher (WMDE): fyi --- Jura 10:38, 19 August 2020 (UTC)
@Jura1: The dump is proceeded via a munge process, which will remove skos:prefLabel and schema:name.--GZWDer (talk) 02:26, 25 August 2020 (UTC)
I doubt this applies to query server. In any case, even a single bit that is added and later removed is a waste if done for every single edit. --- Jura 07:07, 25 August 2020 (UTC)

Query service GUI cut-n-paste problems (August 13)Edit

I keep deleting the parts when trying to do cut and paste of SPARQL parts on .

Maybe it's a problem with my browser, etc. (of which I will spare you the details), but maybe others have the same problem. --- Jura 08:24, 13 August 2020 (UTC)

I did have such a puzzling problem yesterday, when I tried to paste the string GGNZKBPHAMNUOU-UHFFFAOYSA-N but I cannot reproduce it now. --SCIdude (talk) 06:28, 25 August 2020 (UTC)
  • It still happens. Somehow it goes with newline, but still suspect it's a browser issue. --- Jura 09:50, 19 September 2020 (UTC)

"suppress redirect" when moving pages not recognized as sitelink deletion by Wikidata, contrary to delete page (August 25)Edit

Can we fix this? See Topic:Vsnby0dfotcfi23y, Wikidata:Request_a_query/Archive/2018/10#Identifying_interwiki_links_that_no_longer_exist, phab:T201371 (closed), phab: ?.. --- Jura 07:17, 25 August 2020 (UTC)

Hi Jura, is phab:T261275 a correct representation of the issue? Are we doing the right thing when "suppress redirect" is not used when moving to an unsupported namespace? Mohammed Sadat (WMDE) (talk) 09:30, 26 August 2020 (UTC)
  • Yes, thank you. I think it (phab:T261275) is different from the question it was merged into (phab:T231151). Maybe one solves the other, but I'm not entirely convinced.
What do you think @Wurgl, MisterSynergy, Mike Peel:? Jura 06:51, 29 August 2020 (UTC)
  • Looks good, and I agree that the merge/close of phab:T261275 into phab:T231151 is not the best idea, it should be the other way: merge phab:T231151 into phab:T261275 because T261275 has more details and a a nice step by step example how to reproduce. "supress redirect" seems to be the main reason and this detail is not mentioned in T261275. --Wurgl (talk) 07:39, 29 August 2020 (UTC)
    I think it would be good to fix this, if this is the root cause of the bad sitelinks. Let me know if you want me to do further bot runs to remove the current bad ones. Thanks. Mike Peel (talk) 07:56, 29 August 2020 (UTC)
    Ping GZWDer who merged them. --Matěj Suchánek (talk) 08:36, 29 August 2020 (UTC)
  • @GZWDer: once more. --- Jura 09:49, 19 September 2020 (UTC)

Display bugEdit

At university (Q3918), clicking on the image for the sign language video leads to an error, since it tries to fetch a ".ogv.jpg" file that doesn't exist. I assume this may the case with all sign language videos or wider. Could it be fixed? {{u|Sdkb}}talk 19:04, 20 September 2020 (UTC)

Hi @Sdkb:, thanks for reporting. I just tried (with Chromium on Ubuntu), and it seems to work for me: when I click on the picture or the name of the picture, I'm correctly redirected to the file on Commons, and when I click on "Play media", the file is played directly on the page.
What browser are you using? Could you try with a different one? Lea Lacroix (WMDE) (talk) 08:09, 21 September 2020 (UTC)