Shortcut: WD:DEV

Wikidata:Contact the development team

From Wikidata
Jump to navigation Jump to search

Contact the development team

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

Regarding the accounts of the Wikidata development team, we have decided on the following rules:

  • Wikidata developers can have clearly marked staff accounts (in the form "Fullname (WMDE)"), and these can receive admin and bureaucrat rights.
  • These staff accounts should be used only for development, testing, spam-fighting, and emergencies.
  • The private accounts of staff members do not get admin and bureaucrat rights by default. If staff members desire admin and bureaucrat rights for their private accounts, those should be gained going through the processes developed by the community.
  • Every staff member is free to use their private account just as everyone else, obviously. Especially if they want to work on content in Wikidata, this is the account they should be using, not their staff account.
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 2018/07.






a query

for deletions

for comment


for permissions


for deletion

and imports



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

Monolingual string language code ("cnr")[edit]

Please add "cnr" for Q7700307#P1705. I found it on the enwiki article about Montenegrin (Q8821).
--- Jura 11:54, 25 January 2018 (UTC)

I've created T185800 for this and patch will follow soon. But before it can be merged, approval by LangCom is needed. Mbch331 (talk) 10:30, 27 January 2018 (UTC)
@Millosh: what do you think ? It's a request for a language code at Wikidata (not a new wiki/interface language).
--- Jura 17:20, 28 January 2018 (UTC)
It's a valid language code (per [1]) and I see no reason why it shouldn't be added. --Millosh (talk) 19:14, 2 February 2018 (UTC)
Is that a personal statement or an official statement from the langcom? If the latter, please add a statement to phab:T185800. Mbch331 (talk) 20:15, 2 February 2018 (UTC)
@Mbch331: thanks for the patch. I think you can go ahead with it @Millosh: is the m:Language_committee#Current member knowledgeable about this language (or closely related ones). --
--- Jura 07:20, 3 February 2018 (UTC)
@Jura1: My part of the work is done anyway. I don't have the right to merge patches. That's only to the WDME devs. I'm just a volunteer dev that submits patches. Mbch331 (talk) 07:23, 3 February 2018 (UTC)
  • It still needs to be addressed.
    --- Jura 10:33, 12 March 2018 (UTC)
    • I've added a comment to the ticket that there is Langcom approval. Mbch331 (talk) 13:02, 12 March 2018 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Patch for T185800 has been merged. Next passing of the train it will be live. Mbch331 (talk) 18:42, 15 March 2018 (UTC)

{{Section resolved|1=--Lydia Pintscher (WMDE) (talk) 08:23, 23 April 2018 (UTC)}}

  • Finally, what was it?
    --- Jura 11:14, 24 April 2018 (UTC)
We're still working on solving this issue. It's a tough one. Lea Lacroix (WMDE) (talk) 12:24, 24 April 2018 (UTC)
  • It actually works. So what was needed to make it work?
    --- Jura 09:42, 1 May 2018 (UTC)
    • Still open.
      --- Jura 09:00, 31 May 2018 (UTC) --- Jura 09:42, 1 May 2019 (UTC)

Placement in identifier section[edit]

To detail a point brought up earlier, is it possible to add an option to place statements of a few properties (e.g. P1036, sample use: Q64#P1036) in the identifier section of pages (in the sample Q64#identifiers). Currently the sort seems to be based exclusively on datatype.
--- Jura 06:52, 17 February 2018 (UTC)

Why not simply change P1036 to external-id datatype? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 17 February 2018 (UTC)
Dewey Decimal Classification (P1036) is not an identifier but classifier. An identifier identifies an unique instance of class. In contrast, a classifier is used to tag all instances of a class. For example the code 813.54 means American narrative prose from 1945 to 1999. If P1036 is an identifier, we would add that code to the item about the class of American narrative prose from 1945 to 1999. But since P1036 is used as classifier, we add the code to all instances of that class. --Pasleim (talk) 14:10, 17 February 2018 (UTC)
would be more useful to have such classes on Wikidata and to use this property only on the class item. This would allow us to encode the class definition as statements in Wikidata and to infer instances automatically, for example with {{Implied instances}}. Or to add automatically the statements in the class item to the explicit instances of it without having to put the logic into the bot (or an out wiki inference rule). author  TomT0m / talk page 14:17, 17 February 2018 (UTC)
In one sense, certainly; but we have plenty of other external-id properties on Wikidata that "identify" classes of things. Do we really add Dewey codes to every item about a book with that code? The examples on the property page certainly do not suggest that. I also note that, in the property proposal, User:Merrilee of OCLC said "The Dewey identifiers are just that -- identifiers... I had an in depth conversation with the Dewey Editor, Michael Panzer, last week and this use of Dewey identifiers as free for all to use lines up with his understanding as well.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:17, 17 February 2018 (UTC)
  • I think the datatype of one or the other properties for which this can apply should be discussed elsewhere. I think there is a general need for this.
    --- Jura 08:24, 20 February 2018 (UTC)
  • It is currently possible to create a section based on a list of datatypes or on a list of properties but not both. And I don't think we can spend time on it without having a good reason why these properties can't just be converted to external identifier. --Lydia Pintscher (WMDE) (talk) 16:26, 7 March 2018 (UTC)
    • What could we do about exact match (P2888)? There are obviously some that could be converted, but others that can't. There is also the group of identifiers that emerged during the conversion discussion and remained with string datatype.
      --- Jura 08:54, 13 March 2018 (UTC)
      • I'd say as a next step the discussions about the remaining ones need to be concluded. I am not sure what they are held up on. --Lydia Pintscher (WMDE) (talk) 10:45, 15 March 2018 (UTC)
        • Even for the ones that are already in the "not to be converted section", some are identifiers and have formatter urls. BTW exact match (P2888) has url datatype and I think it should be in the identifier section.
          --- Jura 11:34, 15 March 2018 (UTC)
          • @Lydia Pintscher (WMDE): can we move ahead with this?
            --- Jura 07:01, 19 April 2018 (UTC)
            • I am not sure what I can do. It needs editor consensus and then I can move ahead with scheduling the conversion. Or am I missing something? --Lydia Pintscher (WMDE) (talk) 08:25, 23 April 2018 (UTC)
  • Seems this is still open.
    --- Jura 09:05, 31 May 2018 (UTC)
    --- Jura 11:15, 24 April 2019 (UTC)

Formatter url and string datatype[edit]

A problem brought up further up on this page. It seems that this works sometimes and sometimes it doesn't. What's is the development status on this? I think ideally this would work as for "external id"-datatype when the url is set on a property.
--- Jura 08:30, 20 February 2018 (UTC)

I checked and it is possible to do. Can you give me 2 or 3 examples where this would hold and not be an external identifier? I need to look into some of the details because of the RdF export before someone can work on it. --Lydia Pintscher (WMDE) (talk) 10:59, 15 March 2018 (UTC)
Full list:
--- Jura 11:41, 15 March 2018 (UTC)
Ok should be doable. Can you open a ticket for it? Or Léa? --Lydia Pintscher (WMDE) (talk) 14:34, 13 April 2018 (UTC)
Léa? That would be helpful. Apparently, I can't write tickets. Besides, I surely wouldn't find it if someone had already opened one.
--- Jura 14:53, 13 April 2018 (UTC)
done, phabricator:T192188 --Pasleim (talk) 00:25, 14 April 2018 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Lydia Pintscher (WMDE) (talk) 08:26, 23 April 2018 (UTC)
  • The point that might be missing in the phab ticket is that when the formatter url is qualified with a regex, then this should be taken into account. What would be the next steps?
    --- Jura 11:17, 24 April 2018 (UTC)
  • Seems this is still open.
    --- Jura 09:05, 31 May 2018 (UTC)
    --- Jura 11:15, 24 April 2019 (UTC)

Future of query server[edit]

Just wondering, what's the plan for the future of query server? When I looked at the bug tracking system of the software that is being used some time ago, I had the impression that it stopped being maintained. Besides, it appears that the company was acquired by Amazon some time back, possibly when development stopped. Is there a plan to replace the software or at least start evaluating alternatives?
--- Jura 08:24, 29 June 2018 (UTC)

So far I am not worried but investigating. The software we have works and isn't going away over night. I am in the process of talking to people about alternatives and reaching out to Amazon though to get a better sense of where Blazegraph is going and if we need to make a switch. Back when we decided for Blazegraph we also looked at several alternatives and we can still use a lot of that research. --Lydia Pintscher (WMDE) (talk) 10:14, 29 June 2018 (UTC)
If the bug tracking system consists mainly of customers unanswered calls for help, I find it hard to be convinced by anything contrary corporate communications may say.
Currently, the server works fine and I think WMDE/WMF are doing a great job keeping it running. I think its functioning has become a key factor in Wikidata as a whole. One needs to make sure that this still works a year from now.
Compared to other endpoints, I think the GUI is most helpful, but I suppose this is unrelated to the underlying server software.
Growth of Wikidata continues and even if we don't want to change it now, one needs to bear in mind the time it takes to switch. Given other priorities of Wikidata/WMF and its usual pace, I suppose even if we started to switch to something else today, this could easily take 6 months. Selection of an alternative and preparing for this might easily take another 6 months .. You might have better estimates though.
--- Jura 11:08, 29 June 2018 (UTC)
  • Should we start building a plan for a change?
    --- Jura 11:38, 9 July 2018 (UTC)
Hello Jura,
As mentioned above by Lydia, we think that there is nothing pressing us right now. When the time comes we'll make a plan. Lea Lacroix (WMDE) (talk) 12:05, 11 July 2018 (UTC)

Wikidata API not acessible via URL with CONSTRUCT in query[edit]

Unfortunately since some point in time in May 2018 it is not longer possible to query the Wikidata API via URL completely.

As far as I can see, the query API is working fine in the context of functionality. So if we for example adding this query, the given results are fine.

But if we use the respective URL acess, to be able to handle the results in our own application, the data is not accessible anymore. (cf.

At first I thought it would not work anymore due to changes in the API, but as the query works still in the web interface (cf. first link), and the URL access is also offered at the code section of the web interface with exactly the same link, thus not accessible, I think this bug should be fixed.

Did I miss any information about this URL queriing possibility? Or is it a bug already working on? N0omB (talk) 12:24, 9 July 2018 (UTC)

So for me the URL is not working in the browser, but works fine with CURL. What library do you use in your application? Are there any error messages? Jonas Kress (WMDE) (talk) 10:28, 11 July 2018 (UTC)


I'm not sure exactly what sort of normalization is performed on (monolingual) strings, but it appears that we strip certain whitespace from both ends. I found a case of an invisible "left to right mark" character (U+200E) that a user had appended to a string. I think these could usefully be stripped as well.

For the avoidance of doubt, I'm not trying to criticize the user who made this change. I'm sure it was just a copy-and-paste and they had no idea. Cheers, Bovlb (talk) 23:08, 9 July 2018 (UTC)

Thanks for noticing. We are going to investigate about this. Lea Lacroix (WMDE) (talk) 12:06, 11 July 2018 (UTC)

units displayed as QIDs[edit]

It seems frequent today, but tends to disappear when one edits items. What happened?
--- Jura 12:53, 12 July 2018 (UTC)

It was a bug that has been fixed, should not occur anymore. Purging the page to refresh the last remaining. If it's still happening despite purging, let us know. Lea Lacroix (WMDE) (talk) 15:08, 12 July 2018 (UTC)

Hard to read titles[edit]

Update to the archived discussion Wikidata:Contact the development team/Archive/2018/01#Hard to read titles: don't really know if this is a problem for others; however, it is no longer a problem for me since I bought a new computer. It's a widescreen, so this problem went away for me. Just fyi. Thank you for your input and help!  Paine Ellsworth  put'r there  08:02, 13 July 2018 (UTC)

schema:about triples without schema:isPartOf on query server[edit]

Q23769546 doesn't seem to have schema:isPartOf on query server [2]. The same goes for a few others I added yesterday. --
--- Jura 10:09, 14 July 2018 (UTC)

@Jura1: [3] This query seems to work better. Bovlb (talk) 16:28, 15 July 2018 (UTC)
@Bovlb: I'm not sure, try another item, you will see that you get more triples (e.g. Q21508594). --
--- Jura 17:30, 15 July 2018 (UTC)
@Jura1: [4][5] These two queries both produce five results for me. Bovlb (talk) 17:41, 15 July 2018 (UTC)
Strange, I get 1 triple only for Q23769546.
--- Jura 17:52, 15 July 2018 (UTC)
Hmm. Is load-balanced? I have seen BlazeGraph drop an update block occasionally . Bovlb (talk) 18:09, 15 July 2018 (UTC)
There are at least two servers, but it seems I keep getting the wrong one ;)
--- Jura 18:12, 15 July 2018 (UTC)

"20. century" doesn't mean 2000–2099[edit]

Is it actually technically possible to fix phab:T95553/phab:T196674? As far as I'm aware this bug is basically like displaying "19.5±.5" for values internally stored as 20.49±.5, so that all of the data entered with a precision of integer is possibly wrong; so this is probably not something that should be lying around unfixed. Jc86035 (talk) 07:29, 17 July 2018 (UTC)

Since it is fairly evident from the age of the Phabricator tasks that no one wants to fix this, I've made a bot request. Jc86035 (talk) 11:48, 17 July 2018 (UTC)

Wikibase Repository’s naming convention[edit]

Hi, I have a Gamepedia wiki and I would like to use Wikibase to store variables on a namespace (Properties:) and retrieve them in the main namespace. And I’d also a third tab between Article and Discussion. Is there a way to name items pages with its real name instead of Q173 or Qsomething ? Otherwise how do I link a page if the basepagename doesn’t match ?

Thank you --CreativeC (talk) 11:15, 17 July 2018 (UTC)

Lexeme numbers made jumps[edit]

The following lexemes were apparently created consecutively: głuszec (L7038), tannpirkar (L7042) and niedziela (L7044). What happened? --Njardarlogar (talk) 07:58, 19 July 2018 (UTC)

Probably someone wanted to create the missing ones, but for some reason this was not successful and the L-ID is lost forever. The same happens to Q-IDs, where we omit about one out of three these days (see the black bars in User:MisterSynergy/itemstats). I think the item creation rate limit is to some extent responsible. —MisterSynergy (talk) 08:14, 19 July 2018 (UTC)
Tool Wikidata Lexeme Forms returned to me error messages (sorry don't remeber exact wording) that server is overloaded and cannot create lexemes, but apparently it reserved ids for them. I workarounded it by creating lexemes through Special:NewLexeme and then added forms with tool. KaMan (talk) 08:24, 19 July 2018 (UTC)
@Lucas Werkmeister: can you have a look if it's your tool creating this problem? Lea Lacroix (WMDE) (talk) 12:18, 19 July 2018 (UTC)

Interface language bug[edit]

Was: ‎Language says English but is showing German

My language says English but is showing German. I have tried switching languages and switching back but the issue still exists. Image at Please ping in reply. --Emir of Wikipedia (talk) 18:27, 18 July 2018 (UTC)

Was: Some texts of this property show up in Chinese

It seems to be the only property affected, but for Harmonized System Code (P5471) some texts show up in what it seems to be Chinese. For instance instead of the header "Data type", "数据类型" appears, also for the string "references" is shown in Chinese. Refreshing the page doesn't solve it. I have opened the page in another browser and the same happens.--Micru (talk) 08:24, 19 July 2018 (UTC)

In this one it also happens (but in Japanese): GlyphWiki ID (P5467).--Micru (talk) 08:30, 19 July 2018 (UTC)

Some of the text in my interface (e.g. "references") has randomly switched to French; others (in the same room at Wikimania) are seeing German. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 19 July 2018 (UTC)

Task filed at phab:T199983. Quiddity (talk) 11:47, 19 July 2018 (UTC)