Shortcut: WD:DEV

Wikidata:Contact the development team

From Wikidata
Jump to: navigation, search





the development team

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 2015/10.

Templatedata, Wikidata and infoboxes[edit]

Hi, we lack an equivalent of "Templatedata" for infoboxes and templates that uses Wikidata. The problem showed up on one of the recent heated discussions about Wikidata on frwiki.

Usecase :

In an infobox template
someone wants to put an infobox, in VE lets say. He has documentation about the name of the parameters and what to put as values through templatedata
In a Wikidata template
someone wants to put an infobox, in VE lets say. Without gadgets, he has to put the infobox, then to go to Wikidata such as to find the relevant properties, using the property suggestions to find what he is looking for

I think there is a missing link beetween an infobox and the data it uses and the Wikidata ontology, and it has rightly said that this is an analog problem of the one documentation of the templates parameters through templatedata. As templatedata and Wikidata are structured data, there might be something to dig here ...

Thoughts ?  – The preceding unsigned comment was added by ‎TomT0m (talk • contribs).

Yes definitely. There is still a lot to do. We currently have a student work on her bachelor thesis investigating editing on the clients. Once that's done I intend to move forward with improving all that. --Lydia Pintscher (WMDE) (talk) 11:18, 22 September 2015 (UTC)

Can we have monolingual text in Korean in Hanja or Hangul?[edit]

See proposal at Wikidata:Property_proposal/Generic#hanja. I think a separate property is not the way to go. Instead we should be able to specify if a monolingual text is in ko-hanja script or in ko-hangul script. Can this be done? Joe Filceolaire (talk) 16:17, 18 September 2015 (UTC)

That's phabricator:T74126. Adrian is back from paternity leave and looking into it. --Lydia Pintscher (WMDE) (talk) 11:20, 22 September 2015 (UTC)

I've been trying to link to link two articles in Romanian and English - it does not work[edit]


I keep getting this error message "The specified article could not be found on the corresponding site". Mainly because wikipedia keeps adding an '(apostrophe) after each article that I copy paste and enter.

The external client site 'enwiki' did not provide page information for page ''. - see the apostrophe at the end? It only appears after I press "Link with page"  – The preceding unsigned comment was added by AdrianConst (talk • contribs).

enwiki (English language Wikipedia) is already used by Q184204.
The Romanian article is linked from Q12734673.
As both items are about the same these can be merged. This will add English to the interwikis at Romanian. --- Jura 07:54, 20 September 2015 (UTC)

Thanks. I still don't understand it, but it worked.

Tutorial commentary[edit]

I'm not sure whether the tutorial is within the remit of the developers or if that is something created by users.

Because I am new to Wikidata, I decided to start with the tutorial. Overall it's pretty good, but I had some challenges, most of which can be fixed quite easily. I shared my experiences here:


Please let me know if this place is the right place to let you know or if I should be posting this somewhere else.--Sphilbrick (talk) 17:17, 23 September 2015 (UTC)

Hi, a really big thank you for taking the time to write your comments down. I've created these tutorials quite a time ago and it seems during the latest redesigns some things got broken. I will try to address them as soon as possible. I will also reply to your notes then more in detail. Once the redesign is finished, I also want to create tours for the rest of the ui. Perhaps we should have some browser tests to avoid such regression. Best regards, -- Bene* talk 06:32, 24 September 2015 (UTC)
Thanks for your response, I wasn't quite sure who created them which is why I posted here. Good point that redesign probably affected them. As I mentioned I have experience writing tutorials and that was one of our challenges. We would tweak the system to make it better and then a new user would walk through the tutorial and wonder why it didn't seem to match up with the system. Not surprisingly, when we worked on improving the system it wasn't our highest priority to go out and update the tutorial.--Sphilbrick (talk) 15:17, 24 September 2015 (UTC)

Item limit for client[edit]

Recently an item limit of 500 for client wikis was added. Despite Wikidata not being a client wiki, it was added here as well.

As Wikidata isn't actually a client wiki, would it be too much of a drain of resources to exempt it from that? --- Jura 09:18, 24 September 2015 (UTC)

I thought Katie had already done that. How much higher would you need it? --Lydia Pintscher (WMDE) (talk) 10:41, 25 September 2015 (UTC)
The per-year lists at Wikidata:Database reports/Deaths at Wikipedia used to display entirely. Maybe 2000? --- Jura 17:53, 25 September 2015 (UTC)
The limit is already set to 500 for Wikidata (while it is 400 for all other clients). Performance-wise it doesn't make a difference whether entities are being used on Wikidata or on any other client (as Wikidata is just a client to itself). How expensive loading an entity actually is depends on many factors, thus sometimes the limit of 500 will already be way to much, while in other cases it might be ok to include more entities. Due to that, it's very hard to have an upper limit that meets most use cases while still making sure the infrastructure wont be negatively affected. - Hoo man (talk) 10:22, 28 September 2015 (UTC)
Technically the difference might be that if it's set higher for any client, the impact might be thousandfold, whereas a change only at Wikidata concerns just one instance.
While it may appear technically as a client, functionally it's the place where all this is maintained and consolidated.
Given that the reports didn't generate any performance issues in the past, we might as well keep them working. We did reduce the backlog from 30k to 18k since they were set up! --- Jura 09:02, 29 September 2015 (UTC)
@Lydia Pintscher (WMDE), Hoo man: until or unless a system issue comes up, would you mind increasing it again? --- Jura 08:56, 1 October 2015 (UTC)
Marius says we definitely can't go above 1000 without causing issues right now - probably less. Can you load less entities by using the more specialized Lua functions to get the label etc? Those don't count into the limit. --Lydia Pintscher (WMDE) (talk) 10:51, 2 October 2015 (UTC)
I think using the getLabel function would solve the most important cases, but afaik it only works in the project's default language, so would be English-only. --Zolo (talk) 11:48, 2 October 2015 (UTC)
You should be able to specify the language for them. --Lydia Pintscher (WMDE) (talk) 12:09, 2 October 2015 (UTC)
@Lydia Pintscher (WMDE): can you specify the language using mw.wikibase.label() ? It is not documented. You can specify a language for entity:label(), but as it only if the entity has already been loaded, I don't think it make things any better ? --Zolo (talk) 12:16, 2 October 2015 (UTC)
@Zolo: Making it possible to use convenience functions in Lua for this is tracked in T75460. Do you also need access to labels in languages other than the content language or the user's language in that way or are these needed rarely enough so that it's ok to load the whole entity in those cases? - Hoo man (talk) 17:21, 2 October 2015 (UTC)
@Hoo man:, thanks, I think the user's language would be enough here (the same thing for Wikipedia links would be very useful for Commons). -Zolo (talk) 17:48, 2 October 2015 (UTC) (edited 3 oct)
Given the problem there was with LUA, the list was designed to work mostly without it. It relies primarily on {{#property . Labels are added on import. If it's a problem to keep those lists, I suppose we could drop them. Eventually someone else can come up with another solution. --- Jura 11:52, 2 October 2015 (UTC)
The other option would be to split them up. --Lydia Pintscher (WMDE) (talk) 12:09, 2 October 2015 (UTC)
Hmm .. that seems to work: test. Really odd actually. If you prefer, I suppose we could do that. --- Jura 06:23, 3 October 2015 (UTC)
It would make us loose the convenient check of earlier versions though (of date entered etc). --- Jura 06:28, 3 October 2015 (UTC)

Error trying to added an alias to p1344[edit]

Wikidata p1344 p710 conflict error.png

I was trying to add the English alias "participated in" to participant of (P1344) and copy the English title, description and alias to British English. However, I am unable to make any of these changes (I've tried most combinations) as I get the error: "Property participant (P710) already has label "udelženec" associated with language code sl." (see screenshot).

The history of participant (P710) shows this label was added on 14 November 2014 and it was added to participant of (P1344) on 17 January 2015. A Slovenian description was added immediately afterwards, and there have been many label and alias updates in other languages since January so it makes no sense why I'm being prevented now. I do not have Slovenian set in any language or babel settings. I don't speak the language so can't help with whether the label is appropriate in either property. Thryduulf (talk: local | en.wp | en.wikt) 14:13, 24 September 2015 (UTC)

We had a bug that allowed this for some time. I recommend removing the label and waiting for a native speaker to re-add the correct one. --Lydia Pintscher (WMDE) (talk) 10:43, 25 September 2015 (UTC)
Which one should be removed? How do I edit the label of a language I do not have set in my preferences? Why is the existence of a problem in Slovenian preventing unrelated edits to English/British English? Thryduulf (talk: local | en.wp | en.wikt) 11:38, 25 September 2015 (UTC)
I think it would probably be best to remove both, since we don't know which one is the right one. I know of three ways to edit labels in other languages: The one which is usually the best solution is to enable the "labelLister" gadget in the preferences (which adds a tab to display and edit all of the labels). The other two options are to temporarily change the interface language or temporarily add "sl-0" to your babel box on your user page. I can't answer the third question since I don't know how it all works behind the scenes. - Nikki (talk) 12:58, 28 September 2015 (UTC)


Special:PagesWithBadges don't work? --ValterVB (talk) 17:15, 24 September 2015 (UTC)

I think the page is only designed to show articles from the current wiki, so to look for enwiki articles with badges, you would go to en:Special:PagesWithBadges. I'm assuming there are no Wikidata pages with badges, because we don't have things like featured articles. - Nikki (talk) 17:33, 24 September 2015 (UTC)
Ops, you are right. --ValterVB (talk) 17:51, 24 September 2015 (UTC)

Incremental dumps[edit]

I take it that the constraint reports are not updated as there are no new incremental dumps.

What is the status on the dumps? --- Jura 10:38, 2 October 2015 (UTC)

Thanks for poking. I wasn't aware. Marius just poked Ariel. He is looking into it right now. --Lydia Pintscher (WMDE) (talk) 10:49, 2 October 2015 (UTC)
Dump creation has been fixed, thus a new incremental dump for Wikidata should appear within the next hours. - Hoo man (talk) 17:41, 2 October 2015 (UTC)
Thanks. Constraint reports have been generated since. --- Jura 03:35, 3 October 2015 (UTC)

Problems with Safari using present in work (P1441)[edit]

Two times I could not use present in work (P1441) with Safari, an waiting circle was turning endlessly, with FF it works. I was probably using different versions of Safari and systems. Perhaps you can consider Safari.--Oursana (talk) 12:51, 4 October 2015 (UTC)

I was wondering if this is a Safari issue, because I have the same problem in Safari but also in Chrome. Do we have a bug for this? It seems another bug that only happens when you work fast. Sjoerd de Bruin (talk) 13:07, 4 October 2015 (UTC)
To me that happens when I select the property, paste the QID after the property name, then notice that I'm in the wrong field, remove it, try to move to the value section ..  – The preceding unsigned comment was added by Jura1 (talk • contribs).
I don't think there is an open one. phab:T96466 describes the same sort of behaviour, but that was closed back in April (not sure whether the bug came back or whether it's a different one). I also see it (using Chromium). It usually happens with instance of (P31) if the value field doesn't appear fast enough - I accidentally start typing in the property field and then when I remove the text again, the value field never appears. - Nikki (talk) 15:03, 4 October 2015 (UTC)


Why do I get rounding to 10^1 digit in this case? I also inputted 10^0 digit for the value and to, what I think is, the standard deviation: --Tobias1984 (talk) 13:56, 4 October 2015 (UTC)

Typo at[edit]

"are no more that RADIUS km [...] away from LATITUDE,LONGITUDE"

"that" should be "than".

Cheers! Syced (talk) 08:23, 5 October 2015 (UTC), merged by Magnus (but not deployed yet, it seems). --Ricordisamoa 14:18, 5 October 2015 (UTC)

Stability issue with Primary Sources Tool[edit]

It might just be my browser/connection, but each time I add a statement with the tool, the page reloads in slow motion. Is this a general issue or something I should check on my side? --- Jura 12:53, 5 October 2015 (UTC)

Strange search engine behavior[edit]

Hello, When I search for some word (which in my case is item alias) in top-right side search bar, some suggestions come up, and when I click "Enter" the same suggestions I see in the search results. For me this is normal behavior. But when I search for "♀" character, again several suggestions are shown but without any result when I click "Enter", even if I use "Everything" option from the searcher. I don't know is this normal for the searcher but for me is strange. Also I notice the same problem when I search for some item label which is category, for example "Category:Mammals" - there are suggestions but no results. I thought the problem is in colon (:) but its work for "Template:Taxobox". Regards --Termininja (talk) 10:14, 6 October 2015 (UTC)

Creative Destruction !!![edit]

I see there seems to be work on phab:T95287 - creating a separate datatype for 'identifiers', independent of that for strings.
Lydia's comment on Wikidata:Project_chat#Mandatory_language_fields_for_languages_not_recognised_by_Wikidata suggests monolingual text datatype could be changed so we can use any random item as a "language" just as we can use any random item as a "unit" for a quantity.

I think this is a great idea. I was shocked when 'number with units' appeared with no constraints and no built in conversions but it does in fact make thing much more transparent and now I'm convinced it's better.

Once the 'identifiers' have been moved to a new datatype we can combine 'string' and 'monolingual text' into a new 'text with optional language/script tag' datatype, where a text can be labelled with it's language/script, however obscure it's language/script might be. Where the item on 'The One Ring' can record that it's inscription is in 'Elvish' or 'Sindarin' or 'High Elvish' and we don't need to raise a bug - or get an ISO standard amended - first.

Or have I misunderstood where you are going? Joe Filceolaire (talk) 17:56, 6 October 2015 (UTC)

So no more rdfs:label ...@en ? Jheald (talk) 19:23, 6 October 2015 (UTC)
Personally I'm not convinced by that idea. There is already a widely used standard for language tags and it makes sense to me to continue using it. The main problem we have is that only a small subset of the options available are included in our list. Just making any ISO 639-3 language (which are all by themselves valid IETF language tags) available would already solve the majority of the requests I've seen.
Scripts can actually be determined programmatically without the user having to explicitly specify it in almost all cases I can think of (the main exception I'm aware of is simplified vs traditional Chinese). Many languages also have a default script defined by the IETF language tag registry (e.g. Latin for English) and the script should only be specified in the language tag if it's different from that. A well-designed language selector could avoid making the user pick a script at all most of the time (which I think would be good, script is quite a technical idea and in my experience people often get quite confused about it) and determine itself what the script is and whether it should be specified, and something like that would allow using any script for a language without users having to ask or create new items first.
I can think of other issues with using items too, e.g. the default languages shown for a user are based on the Babel extension, which uses language tags, not items. The UI language stuff would also have to understand which items correspond to which language in order to add the right languages for labels when changing the UI language. And if labels/descriptions/aliases are based on items, not language tags, merging two items would affect how labels/descriptions/aliases are merged too, and that would add even more nasty effects if someone does a bad merge (e.g. merging two languages). - Nikki (talk) 12:15, 7 October 2015 (UTC)

Time in hours, minutes and seconds[edit]

Hi everybody. As suggested by @Filceolaire: on Wikidata:Property proposal/Event where I ask three properties for time, I ask you if it will become possible in the future to enter the time of a race, for example 3 h 56 min 30 s, or 3:56:30 instead of using decimal numbers. On Wikidata:Cycling, I explain the project to centralise on Wikidata the classifications of cycling races, to make people contribute to Wikidata, it must be very easy and very fast (sorry for my English..., and it is worst when I speak). Jérémy-Günther-Heinz Jähnick (talk) 08:29, 7 October 2015 (UTC)