Shortcut: WD:DEV

Wikidata:Contact the development team

From Wikidata
Jump to: navigation, search






for permissions

for deletions


for deletion

for comment

and imports


a query


Development plan Usability and usefulness Status updates Development input Contact 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 2017/08.

Capacity limits[edit]

I found official monthly population statistics for Taipei City and its districts (2001-present, so about ~200 data points on a single item), which I processed and partially uploaded with the QuickStatements tool. A user pointed out that there may be some capacity limits with the server and/or tools and I should seek clarification with the development team first. What are the limits, if any? Are there guidelines for P1082? S-1-5-7 (talk) 12:28, 26 July 2017 (UTC)

viewing an item can be slow (and particularly bad on mobile devices) if there are 1000's of statements. A couple of hundred is not so bad. However you might want to consider (and perhaps propose another property for) using the new "tabular data" datatype where the detailed data can be stored in Commons with just a link from wikidata. It is very new but would be good to see some useful applications of which this sounds like a possible good one. ArthurPSmith (talk) 13:18, 26 July 2017 (UTC)
@ArthurPSmith: How is "tabular data" on Commons helping when designing a template on Wikipedia? -- Innocent bystander (talk) 08:59, 28 July 2017 (UTC)
I don't think there's anything built in for this right now, but in principle it sbe displayable just like images are. ArthurPSmith (talk) 13:17, 28 July 2017 (UTC)
en:w:New York City#Climate is using tabular data on Commons in the interactive graph. --Pasleim (talk) 14:00, 28 July 2017 (UTC)
  • @S-1-5-7: Last time we heard from the developers about this, I think it was 100-200 values max. @ArthurPSmith: are you currently developing this to expand?
If monthly population data is entered, this would given 120 values per decade. Supposedly the same could happen as with chessplayer items: these can't be used in larger Listeria reports, as too much data is involved.
--- Jura 07:23, 28 July 2017 (UTC)
Jura I'm not involved in development, this is just from personal experience looking at one or two items with several thousand statements a few months ago - they were slow but barely useable. ArthurPSmith (talk) 13:18, 28 July 2017 (UTC)
Maybe the web interface could be modified so that items with large numbers of properties only show the first N properties and then additional properties could be loaded with a link/button? S-1-5-7 (talk) 06:56, 29 July 2017 (UTC)
@Lea Lacroix (WMDE): can you get the community a status on this?
--- Jura 10:10, 29 July 2017 (UTC)
There is no limit in term of number of statements. The only limit we have is the size of the page, in bytes, which also depends on the qualifiers, references, the alphabet that is used, etc.
We're currently working on making the page of an item lighter to load.
About the statistics and other "timeline" data, we are looking into it long-term but it is not a priority at this point because storing timeline data is not a focus of Wikidata.
Lea Lacroix (WMDE) (talk) 12:24, 3 August 2017 (UTC)
So what's the limit in bytes? Supposedly we will have to divide this by 500, at least when reading from another wiki.
--- Jura 06:36, 4 August 2017 (UTC)
It's the default size of Mediawiki pages, 2Mb. Lea Lacroix (WMDE) (talk) 09:16, 4 August 2017 (UTC)
Well, Wikisource can already bypass that number by some special function. I guess we could as well. -- Innocent bystander (talk) 16:23, 4 August 2017 (UTC)
How much content can be read from Wikipedia? Currently there is a limit of 500 items, but I suppose it can't read 1 GB (500*2 Mb).
--- Jura 16:48, 4 August 2017 (UTC)
In Special:LongPages we can see that there already are items with over 3.5 Mb. XXN, 17:25, 13 August 2017 (UTC)

small js change with huge impact[edit]

For long lists "edit" button should scroll similar to property label. d1g (talk) 22:37, 4 August 2017 (UTC)

Property label should scroll for every qualifier, not for every property :-) d1g (talk) 22:39, 4 August 2017 (UTC)

Links from identifier SIPA ID (P1700)[edit]

Recently SIPA URL changed from "" to "" (added .gov). The "formatter URL" in Property:P1700 is already correct, but many of the items with this property still link wrongly to the old one ex:Q16501783. If I remove and re-add the property in these items the problem is solved. Should I run this procedure through all the wrong items? --JotaCartas (talk) 23:36, 6 August 2017 (UTC)

Or you need to do a cache purge (with link update) on all items containing this property or just have patience till the cache is invalidated by itself. Recently ran into a similar issue too. Mbch331 (talk) 05:34, 7 August 2017 (UTC)
The formatter URL was modified about one week ago (2017-07-30); how much do we have to wait, or who and where one can do the cache purge (with link update)?--JotaCartas (talk) 19:55, 9 August 2017 (UTC)
Is there anybody out there? --JotaCartas (talk) 12:24, 13 August 2017 (UTC)
@JotaCartas: It can take up to 31 days for such changes to be reflected everywhere. Purging the page in question will solve the problem. I've filled T173247 for improving this, so that such changes propagate faster. -- Hoo man (talk) 13:54, 13 August 2017 (UTC)
@Hoo man: Many thanks--JotaCartas (talk) 14:37, 13 August 2017 (UTC)
✓ Done --JotaCartas (talk) 16:33, 16 August 2017 (UTC)

Small tweak in search results[edit]

I'd like to suggest a small tweak in search results. While it's obvsiously very sensible to get a clickable result, it would be great if the item number (Q...) or property number (P...) could also be written somewhere in plain unlinked text in the results. More often than not, I have to copy & paste this number, and it's very inconvenient to have the format copied with it, or have to use all sorts of workarounds depending on the browser and the program you paste the number into. Since there is no SPARQL way that I know of to search descriptions, but only the ridiculous ItemDisambig page that does not support wildcards and is limited to 100 results anyway, the search engine is very very important, and it is already enough user-unfriendly as it is (not being able to restrict search to "in label" or "in description" for example). --Anvilaquarius (talk) 13:49, 8 August 2017 (UTC)

Swedish GUI[edit]

When I have added a claim with a reference, I see now the text "1$3+$2$4 referens".

When I have added a claim without reference, I see "0$3+$2$4 referenser". Note that "referenser" here is plural of "referens".

A purge easily fixes this, but it is still annoying as Hel (Q644341)! -- Innocent bystander (talk) 06:23, 18 August 2017 (UTC)

SAme thing can be found in edit mode in the list of sitelinks: "1$3+$2$4 uppslag". -- Innocent bystander (talk) 07:40, 18 August 2017 (UTC)
I saw same kind of codes in Finnish, today, too. Stryn (talk) 20:01, 18 August 2017 (UTC)
This is a known problem. See phab:T173543. A purge isn't even needed, a refresh of the page is enough. Mbch331 (talk) 06:53, 19 August 2017 (UTC)