Wikidata:Contact the development team/Archive/2017/08

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Capacity limits

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)

Hello,

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

https://www.wikidata.org/wiki/Property:P523#P2302

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)

Recently SIPA URL changed from "http://www.monumentos.pt/Site/APP_PagesUser/SIPA.aspx?" to "http://www.monumentos.gov.pt/Site/APP_PagesUser/SIPA.aspx?" (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)

Swedish GUI

Tracked in Phabricator
Task T173543

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)

I believe this is fixed now. Let us know if it is still happening for anyone. --Lydia Pintscher (WMDE) (talk) 15:34, 27 August 2017 (UTC)

WDQS better support of grouped columns

query:

1. I would prefer wd:Q201996 × wd:Q494446 over http://www.wikidata.org/entity/Q201996 × http://www.wikidata.org/entity/Q494446
2. IRIs/URLs should be clickable

d1g (talk) 16:16, 23 August 2017 (UTC)

I am not sure I understand what you'd like us to do. Sorry. Can you clarify? --Lydia Pintscher (WMDE) (talk) 15:35, 27 August 2017 (UTC)

my bad, link wasn't best

tinyurl.com/y7ofppfx unclickable "http://... × http://..."

tinyurl.com/y75qv5od clickable "wd:..."

In first example we should have "wd:... × wd:..." - where each link is clickable d1g (talk) 05:43, 28 August 2017 (UTC)

Ok thanks! So you are saying that in a grouped column the links should also be clickable? --Lydia Pintscher (WMDE) (talk) 08:03, 28 August 2017 (UTC)

They should be 1. clickable 2. in short form (similar to other links) d1g (talk) 18:42, 28 August 2017 (UTC)

I think that’s phab:T144764. --Lucas Werkmeister (WMDE) (talk) 14:15, 29 August 2017 (UTC)