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/12.


It seems that everything lags. Maybe not everything, but SPARQL and WDQ. What's happening? --- Jura 12:37, 18 November 2015 (UTC)

SuccuBot is doing a huge amount of edits at the moment. I am not sure but my guess is that this is too much for the query service to keep up with. I recommend at the very least having it run slower. --Lydia Pintscher (WMDE) (talk) 14:58, 18 November 2015 (UTC)
It does do quite a lot, but is this already sufficient to slow things down that much? If yes, Wikidata is likely to break if the userbase increases significantly. --- Jura 15:03, 18 November 2015 (UTC)
Special:DispatchStats seems ok. --- Jura 15:08, 18 November 2015 (UTC)
Yes those are stats for the dispatching to the clients (Wikipedia etc.) The query service is independent of that for all I know and hasn't been stress tested like dispatching yet. --Lydia Pintscher (WMDE) (talk) 15:12, 18 November 2015 (UTC)
I'm not very fast. Should I stop the bot for today? --Succu (talk) 15:16, 18 November 2015 (UTC)
So it's rather ? Given the type of edits, maybe Succu should hold them for stress testing once the fixed deployed.
This part seems okish for all I can tell. Very strange. --Lydia Pintscher (WMDE) (talk) 15:20, 18 November 2015 (UTC)
Edits per day increase from 200k to 1200k :) --- Jura 15:18, 18 November 2015 (UTC)
Yeah. I think it is worth a try to stop. Edits increased a lot. Then we can be sure one way or the other. If it is really the problem then we need to make the updater more robust. --Lydia Pintscher (WMDE) (talk) 15:19, 18 November 2015 (UTC)
Done. --Succu (talk) 15:21, 18 November 2015 (UTC)
Thanks! Let's see if this helps. --Lydia Pintscher (WMDE) (talk) 15:22, 18 November 2015 (UTC)
Is there a way to use sparql to determine the current lag? (Other than trying to search for an edit made recently). --- Jura 16:31, 18 November 2015 (UTC)
Jonas just gave me this to do it:
prefix schema: <>
SELECT * WHERE {<> schema:dateModified ?y}
Hope it helps. --Lydia Pintscher (WMDE) (talk) 17:05, 18 November 2015 (UTC)
It does. Thanks. --- Jura 17:32, 18 November 2015 (UTC)
The service should be fully caught up now. Please ping me if you still see problems. --Smalyshev (WMF) (talk) 00:37, 19 November 2015 (UTC)
Something is wrong, Smalyshev (WMF): Running this simple query I get an old value for botanist author abbreviation (P428) in Neville Forde (Q21395061) (fixed 21. November 2015, 22:52 Uhr) --Succu (talk) 14:06, 24 November 2015 (UTC)
Hi all! You can now track the lage of the query service on this lovely dashboard ·addshore· talk to me! 15:29, 24 November 2015 (UTC)
@Addshore: Very pretty, but not so relevant to Succu's complaint, which shows a value still not updated in the triplestore after three days, even when the lag is reported at 15 seconds.
Should we be concerned that one node appears to have 200,000 more triples in it than the other ? Jheald (talk) 17:08, 24 November 2015 (UTC)
That is already being looked at :) ·addshore· talk to me! 20:16, 24 November 2015 (UTC)
There is an issue currently with data not being deleted correctly on update, so old data may show up along with the new data. See I am working on figuring out why it happens and fixing it. Usually updating the entry again (even in unrelated place) fixes the problem. I will update once I have something substantial to report. --Smalyshev (WMF) (talk) 00:11, 25 November 2015 (UTC)
If you need another test case: This query should give no results. I fixed the issue more than 48 hours ago. --Succu (talk) 12:53, 28 November 2015 (UTC)

Clicking "add reference" while editing a statement means the edit will not save[edit]

If, while adding or editing a statement, you click to add a reference, the edit to the statement will not save - it says "saving" as normal but never completes (I've left it 20 minutes once). If you click "cancel" everything except "save" is greyed out but the action is not cancelled, if you then click save it does if you hadn't clicked cancel at all. If you refresh the page your edit has not saved, but everything works exactly as the first time (i.e. as long as you don't try to add a reference while a statement is open for editing).

This happens every time using Firefox (version 42.0 on Xubuntu Linux) but not normally when using Chromium (Version 45.0.2454.101 Ubuntu 14.04 (64-bit)). I cannot add or edit any statements at all using Konqueror 43.3. Thryduulf (talk: local | en.wp | en.wikt) 17:26, 18 November 2015 (UTC)

Since when did you have this issue and is it still an issue? New code was deployed about an hour ago. I tried in Chromium and Firefox and it works, though perhaps there are some caching issues. Aude (talk) 21:12, 18 November 2015 (UTC)
I had same issue in last days as Thryduulf, but it is OK with new code. --Jklamo (talk) 22:03, 18 November 2015 (UTC)
I've been experiencing it for a couple of weeks, and it was still happening when I left the report above but it does seem to have been fixed since then. Thryduulf (talk: local | en.wp | en.wikt) 23:48, 18 November 2015 (UTC)

Adding reference[edit]

When I today added references, I discovered that I opened all of the claim to edit. I also had to "save" at the top of the box. Based on how it has worked this far, it was very confusing, but I guess I (we) will learn. The possibility to add both the reference and the claim itself in one single edit is a big improvment.

But one thing made me very confused in GUI. There is dark blue bar between the qualifier-part and the reference-part of the claim. It made me think something was broken with my browser. What is the purpose of this bar?

And a second thing, the Gadget that allows me to copy-paste references looks like it is now broken... -- Innocent bystander (talk) 07:08, 20 November 2015 (UTC)

@Bene*: Maybe you can have a look at the gadget?
As for the bar: Yeah Jonas and me sat down together today to remove a few things like this. The view should be quite a bit cleaner with the next update in 2 weeks. --Lydia Pintscher (WMDE) (talk) 10:19, 20 November 2015 (UTC)

The Gadget that allows me to copy-paste references wot working. Big problem. Xaris333 (talk) 16:27, 20 November 2015 (UTC)

@Xaris333: I have fixed the gadget and it should work again. :-) -- Bene* talk 17:43, 23 November 2015 (UTC)

WDQ not working for me for two days[edit]

Hi, I saw ListeriaBot having some issues with manual request for updates a few days ago. Also WDQ had some issues. After waiting, it now doesn't seem to throw any errors anymore, but some lists don't update (via ListeriaBot). Even when I initiate a manual update it says "no change". This seems to come from WDQ not returning correct results. E.g Bassum station (Q4868200) (P81 claim added 22:36, 6. Nov. 2015‎) and Lauenbrück (Q16061828) (P81 claim added 17:52, 19. Nov. 2015‎) both claim Wanne-Eickel–Hamburg railway (Q317480) via connecting line (P81). Checking via "whats links here" show 22 stations linking to Wanne-Eickel–Hamburg railway (Q317480). But WDQ "CLAIM[81:317480]" only returns a list of 9, including Bassum station (Q4868200) but not Lauenbrück (Q16061828). As far as I can tell, those are older claims. None of my edits from this week seem to show up via WDQ (and subsequently in ListeriaBot managed lists). Among those lists suffering from this are:

--Aeroid (talk) 09:31, 21 November 2015 (UTC)

Unfortunately WDQ has frequent outages. Wikidata Query Service is much more reliable (and there is tool to convert WDQ->SPARQL queries). --Jklamo (talk) 11:38, 21 November 2015 (UTC)
ListeriaBot uses WDQ not SPARQL, so converting the query to SPARQL won't help fix the lists unless Magnus decides to make ListeriaBot support SPARQL queries. - Nikki (talk) 13:40, 21 November 2015 (UTC)
ListeriaBot and WDQ are both tools by User:Magnus Manske, so he is usually the best person to ask about it. WDQ is rather behind at the moment (see #Lag above) and as far as I can tell from Topic:Ssx90z1r5akk0b4x Magnus is waiting for a new dump to be created (due on the 23rd... it doesn't look like it will catch up before then, since it's now over four days behind). - Nikki (talk) 13:40, 21 November 2015 (UTC)

You can now use SPARQL instead of WDQ as a Listeria generator. See documentation update. --Magnus Manske (talk) 21:36, 21 November 2015 (UTC)

Now you need to work on the display of the template. The introduction currently reads: This list is periodically updated by a bot. Manual changes to the list will be removed on the next update! Query: {{{wdq}}}. (After switching from wdq to sparql). Mbch331 (talk) 11:39, 22 November 2015 (UTC)
He, you, they, we? --- Jura 12:10, 22 November 2015 (UTC)
@Magnus Manske, great stuff! I'll probably need to understand that better. Simple stuff worked, but a more complex WDQ translates into some strange stuff. Try "CLAIM[131:(TREE[1197][150][131])] and CLAIM[31:(TREE[5302441][][279])]" ... it returns 21 items via Autolist and 146 going via wdq2sparql/query. It's not really a "Subqueries within tree/web", right? So I thought might work.--Aeroid (talk) 19:34, 22 November 2015 (UTC)
I had an experience that may be similar a couple of days ago. I was looking for instances of subclasses of "town" in the UK, and got a lot fewer responses from WDQ than I expected (and fewer than I got from SPARQL), because two key subclasses weren't being included in the WDQ version of the query for subclasses of town: Query: CLAIM[279:3957] is missing market town (Q18511725) and county town (Q1357964). Jheald (talk) 21:13, 22 November 2015 (UTC)
See #Lag above. You set them to be subclasses of town on the 18th. WDQ is still stuck on the 17th (according to [1]) so does not have your changes yet. - Nikki (talk) 22:42, 22 November 2015 (UTC)
Yeah, that makes sense. Thanks! Jheald (talk) 23:34, 22 November 2015 (UTC)

ı am so sorry[edit]

I wrote here that I have less time. I took out some information to make wikipedia I'm working on a project presentation. Do not break the news to get information from the copyright've also sufficient. I'm gonna give me a link where I got the information from. If you want I will send to you when I finish my project.We stayed for two days. Please wished success;)


--  – The preceding unsigned comment was added by Argk02 (talk • contribs) at 23:34, 22 November 2015‎ (UTC).

This user has made no other edits on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:22, 30 November 2015 (UTC)

Long qualifiers list[edit]

Hello, I am working on migration constraints violation system from templates to properties. Now one issue blocks this process: Wikidata editor does support long qualifiers lists changing (~ 1000 values). All tested browsers say something like "script does not responding". The issue can be tested on Property:P370. This list come from real-life case Property talk:P225. Is it known issue? Can the issue be resolved on editor level in near future? — Ivan A. Krestinin (talk) 10:21, 23 November 2015 (UTC) @Jura1, TomT0m, Brya, Succu: JFYI

Maybe --- Jura 13:18, 23 November 2015 (UTC)
So the issue is when editing? --Lydia Pintscher (WMDE) (talk) 11:43, 25 November 2015 (UTC)
Yes, page script hangs after click on "edit" link. — Ivan A. Krestinin (talk) 18:56, 26 November 2015 (UTC)
Thanks. I'll look into it with the team. --Lydia Pintscher (WMDE) (talk) 13:17, 30 November 2015 (UTC)

explanation for "link layout mystery" please (bug or feature?)[edit]

Hello, can someone please explain to me how it is possible that simple links like [[Q112375]] are sometimes shown like Q112375 (as normally expected), but sometimes with labels like Galápagos National Park (Q112375)? it feels not really good to loose "control" over link display, especially on talk pages. What is behind this mysterious "feature", which appears/disappears on random pages in certain timespans without an obvious scheme? it happens repeatedly for a couple of weeks now and only for logged-in users as far i know.

there's also a short background discussion "constraint violations, link layout mystery" which you might want to read.

Holger1959 (talk) 10:37, 23 November 2015 (UTC)

Just now I don't see [[Q112375]], but I see the second version :) In preview is normal. --ValterVB (talk) 18:23, 23 November 2015 (UTC)
I observed this many times. AFAIK it might be a software feature. Recently, there were some caching problems with this but I cannot find anything about them now (I don't remember when it was). Matěj Suchánek (talk) 20:58, 23 November 2015 (UTC)
Yes most of the time this is a caching issue that should be solved with a purge or waiting a bit. --Lydia Pintscher (WMDE) (talk) 11:44, 25 November 2015 (UTC)
@Lydia Pintscher (WMDE): purging does not help (i tried out a lot in the last weeks), and waiting can mean 2 days. maybe you can explain a bit more how this is done (by some scripts or css?) and also on which basis. i mean: if this is really thought to be the new default layout for all [[Q1234567]] links on all Wikidata pages , but only for logged-in users, this will need some community discussion i think, because such a change affects many issues. For example it is sometimes wanted to have only the short Qnumber shown, and not also the (sometimes long) labels in undefined languages (display depends on user prefs, not on textual/page context). Of course having the labels shown is nice in many circumstances (we are used to use {{Q|number}} for this). And of course we could change all intentional Qnumber links to [[Q1234567|Q1234567]]. But this is a lot of work, and would only make sense if the "feature" would really work. At the moment, it does not work reliably, neither in one, nor in the other direction. Holger1959 (talk) 22:52, 29 November 2015 (UTC)
Do you have a specific page where it is sometimes shown one way and sometimes another? Without that it is hard to guess what is going on besides caching. --Lydia Pintscher (WMDE) (talk) 13:21, 30 November 2015 (UTC)
T111346 is what I meant in my comment above. Matěj Suchánek (talk) 14:36, 30 November 2015 (UTC)
@Lydia Pintscher (WMDE): as said in "constraint violations, link layout mystery", i regularly see it on the P809 constraints report (probably because this is the report i check most often), but on random other pages too, even user talk pages. thanks to Matěj Suchánek for the link to T111346! there, in the middle of the page is a good screenshot and description by Bene (i guess this is Bene*) which shows how it looks. that bug is marked as resolved, don't know why, it is obviously not. Holger1959 (talk) 00:50, 1 December 2015 (UTC)

Unusable Open Dataset[edit]

What to do in the case the main official (open) dataset are in an incompatible licence ? This is a big problem for france for example as the opendata portal offers a licence (compatible CC-BY) with necessity to mention the source of datas - which we actually DO, but not guaranty subsequent usage will do as well : I think this is a real problem for Wikidata development as demographic datas are a real Wikidata usecase, where Wikidata/Wikipedia can relly make a difference in data diffusion and exploitation, that governments are willing to publish in OpenData, but that we just can't use their datas !?! This seems an absurd problem as Wikipedias can actually have this datas. This actually is the single thing here that stops Wikidata in usecase such as french demographic datas. author  TomT0m / talk page 14:09, 23 November 2015 (UTC)

Contac the data owner and request a licence change or an OTRS authorization for a set of data in its use in WD. We don't have any structure for the OTRS system yet but this is the correct way to get an official approval. Snipre (talk) 14:41, 23 November 2015 (UTC)

A related question that has been worrying me: under what authority do we have the right to systematically mine Wikipedia and republish the results CC0 ?

The content of Wikipedia -- including infobox data, categorisation, templating, etc -- is published CC-BY-SA. How is it acceptable to host systematic extractions, without complying with the terms of that license ? Jheald (talk) 16:56, 23 November 2015 (UTC)

The way Wikipedia has its data makes it not eligible for copyright. I'm not completely sure why, or where the boundary is. --Yair rand (talk) 17:54, 23 November 2015 (UTC)
In the US maybe, because there is no database copryright, but in Europe and especially in france any collection of datas chosen in a creative manner, and the selection of articles that fulfils WP:N criteria seems to me as such, is eligible as a database and is eligible for copyright. author  TomT0m / talk page 17:59, 23 November 2015 (UTC)
It seems to me the database being copied from (Wiki*) is hosted on US territory and such a fact would be important. Either this is never going to be an issue or the Foundation isn't going to have any difficulties defending our import from... whoever... decides they're going to have a conniption. --Izno (talk) 19:29, 24 November 2015 (UTC)
This is maybe legally valid, I don't know, laws and international laws are somewhat complex, but this is unsatisfactory. What happens if someone just want to reuse Wikidata datas in France ? Is he at risk ? Plus Zolo's proposal of bot import was rejected for this reason. author  TomT0m / talk page 20:43, 24 November 2015 (UTC)

ML-text editor[edit]

I cannot a change lang code in birth name (P1477) at Friedrich Köppen (Q4251435). When i replace "ru" with "de", the save button was still disabled, a adding a fake qualfier enables button, but lang not changed to German. Fix it please. -- Sergey kudryavtsev (talk) 10:07, 24 November 2015 (UTC)

I fixed P1477 value in Q4251435 via adding a new value. You may try same action in Wikidata Sandbox (Q4115189). -- Sergey kudryavtsev (talk) 10:12, 24 November 2015 (UTC)

Where are we in ... watchlist integration ?[edit]

A little status update related to the state of watchlist integration would be good. It seems that the non-checked by default is (one of) the blocker for Wikidata usage in heated and unpleasant discussions that can occur on almost a daily basis this day. Other users (or the same) still agues on the flood. As Wikidata's watchlist integration seems not to work for me (did not investigate), I don't know if it's worth answering yet.

author  TomT0m / talk page 11:25, 25 November 2015 (UTC)

Wikidata changes show up meaningfully now on one of the two watchlist/recent changes versions. Enhanced recent changes still needs to be made to work. We've poked at it some but not gotten far. The codebase there is pretty bad and we are going to talk about how to move forward at the developer summit in early January. --Lydia Pintscher (WMDE) (talk) 11:47, 25 November 2015 (UTC)

@Lydia Pintscher (WMDE): Should we also be considering history integration, to allow relevant Wikidata changes that have changed the infobox to be shown in place in the page history ? Jheald (talk) 18:20, 25 November 2015 (UTC)

Yeah I have that on my list. However I have not pushed it up very high because very few people have been asking about it. So I'd first concentrate on making recent changes and watchlist work properly and then see how much history integration is demanded once that is in place. Does that make sense? --Lydia Pintscher (WMDE) (talk) 18:50, 25 November 2015 (UTC)
This shows up into anti-wikidata infoboxes arguments on frwiki as a blockup for some people as well. But I agree watchlist is higher priority, and I came to understand history integration was not easy to implement :) author  TomT0m / talk page 19:40, 25 November 2015 (UTC)
A good next step might be for someone to create a gadget that just merges the two histories on-view so we get a better understanding of how it could work and what people want exactly. --Lydia Pintscher (WMDE) (talk) 15:35, 26 November 2015 (UTC)
I also thought of a workaround that by setting-up a watchlist snapshot every now and then for a single article and merge it with the article history. author  TomT0m / talk page 16:02, 26 November 2015 (UTC)
That seems pretty bad to be honest as it'll mess in all kinds of ways with diffs and so on as I understand it. But then again... worth a try maybe. --Lydia Pintscher (WMDE) (talk) 13:22, 30 November 2015 (UTC)


I have problems with wbsetqualifier in the API-sandbox. Maybe the parameter for the value is wrong in the example? For example, I see no parameter that tells that it is a string. And if I use wbgetclaims for an item with a qualifier, I see the parameters "datavalue" and "datatype" in the qualifier section. I use this API-funktion in User:Molarus/SPARQL-Endpoint-01.js. I have tested a lot of different ways to call this API-function at, but I couldn´t find the right way. I hope you could help me. --Molarus 11:42, 25 November 2015 (UTC)

@Bene*: Could you maybe have a look? --Lydia Pintscher (WMDE) (talk) 11:49, 25 November 2015 (UTC)
Hi Molarus, as far as I understand you have to pass the serialized datavalue to the value param, so only {"type":"string","value":"test2test2"}. The example given in the ApiSandbox is indeed wrong and misleeding. Hope that helps. :-) -- Bene* talk 18:45, 25 November 2015 (UTC)
I have found the right solution at [2]: value: '"GdyjxP8I6XB3"'. In wbcreateclaim there is an example for a string too and there in the parameter value "itsastring" is seen. That means in the example GdyjxP8I6XB3 should be changed into "GdyjxP8I6XB3". --Molarus 02:04, 26 November 2015 (UTC)
Thank you! Adam is making a patch for this right now. --Lydia Pintscher (WMDE) (talk) 15:51, 26 November 2015 (UTC)
It wont actually be deployed for a while but it is fixed! ·addshore· talk to me! 15:55, 26 November 2015 (UTC)

Module namespace doesn't display QID/interwikis[edit]

would normally display a link or at least the QID for Q12069631, but nothing is there. --- Jura 18:51, 25 November 2015 (UTC)

I need a bit more context here ;-) Where is nothing shown? --Lydia Pintscher (WMDE) (talk) 13:23, 30 November 2015 (UTC)
Long weekend? ;) Try to click on the links. For comparison, see en:Module:Wikidata or --- Jura 13:58, 30 November 2015 (UTC)

Problem with moon crates interactive view[edit]

Good morning from Spain:



He detectado que al entrar en los cráteres lunares que he generado (siempre traducidos del inglés), al navegar por la opción interactiva que se acciona al pulsar en el símbolo "del globo terráqueo" situado junto a las Coordenadas, NO APARECE EN EL PLANO INTERACTIVO DE LA LUNA EL NOMBRE DE NINGUNO DE LOS CRÁTERES QUE HE GENERADO:


La posición aparece correctamente en el plano lunar (con un circulito marrón), pero no el rótulo con el enlace correspondiente. He probado a activar y desactivar el idioma español en el menú de Mostrar Etiquetas" sin éxito. En cambio, el inglés funciona correctamente. También he revisado los datos en Wikidata (comparando un cráter en español que funciona con los que no), pero no doy con el problema.


Por favor, necesito que alguien más ducho que yo manejando Wikidata (creo que el problema está ahí, pero vaya usted a saber...), ME INDIQUE CÓMO SOLUCIONAR EL PROBLEMA. (Tengo la intención de seguir subiendo cráteres de vez en cuando).


Usuario que lo solicita: --Wiki LIC (talk) 12:10, 26 November 2015 (UTC)--Wiki LIC (discusión) 20:31 24 nov 2015 (UTC)

Maybe it's this: MediaWiki_talk:Gadget-AuthorityControl.js#Globe. --- Jura 12:47, 26 November 2015 (UTC)

Simple inverse look-ups from Lua ?[edit]

At the moment, for a given item, it's easy from Lua (eg in an infobox) to find statements for a particular property that the item is the subject of.

How far are we from being able to make calls in Lua for a particular item to find statements for a particular property that the item is the object of ? (eg in a similar way to the way Reasonator shows what statements refer to an item, not just what statements are located on the item).

Is this in the roadmap ? Is there a current view on the timeframe that it might happen ?

There are quite a lot of property proposals that get rejected, on the basis that they are "just the inverse of an existing property", with a preference against duplicating information. But that assumes inverse look-ups are possible, for the information to be able to be found and extracted.

Of course, it's possible now to do those sorts of queries with WDQ and SPARQL. But is it intended that direct inverse look-ups should be possible directly from Lua ? Jheald (talk) 18:23, 27 November 2015 (UTC)

The next step in that direction will be list creation on the Wikipedias and co. How exactly we'll do that isn't decided yet. It is one of the big targets for 2016. --Lydia Pintscher (WMDE) (talk) 13:25, 30 November 2015 (UTC)


Since about a week it is no longer possible to use a label in the form "Category:Xxxxxxxx" (with Xxxxxxxx being any string) more than once, no matter what is put in the description field. - Brya (talk) 06:00, 28 November 2015 (UTC)

Have you some examples? --ValterVB (talk) 08:49, 28 November 2015 (UTC)
As the system refuses to store such edits, there can be no diff's. - Brya (talk) 11:39, 30 November 2015 (UTC)
I just tried this and it works for me: What error do you get? --Lydia Pintscher (WMDE) (talk) 13:27, 30 November 2015 (UTC)

Template expansion limits[edit]

Has somebody recently changed the limit for the maximum number of templates that can be expanded on a page?

Or changed the template {{Q}} to make it a lot more expensive?

The templates on Wikidata:SPARQL query service/queries used to expand fine. Now it's a sea of red. Jheald (talk) 09:12, 28 November 2015 (UTC)

YesY Seems to be okay again now. Jheald (talk) 13:54, 28 November 2015 (UTC)