Wikidata:Contact the development team/Archive/2014/04

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

Question about inclusion syntax

I understand, that properties can be included in Wikipedia by the tag {{#property:Pxxx}}. But is there also a way to include the label and the description? This might be helpful as some Wikipedia labels use additional brackets. In those cases the reserved tag {{PAGENAME}} is not a helpful ressource and Wikidata could provide much better information. -- Pütz M. (talk) 09:01, 27 March 2014 (UTC)

For this, you need to use a module, see mw:Extension:Wikibase Client/Lua. Matěj Suchánek (talk) 15:52, 27 March 2014 (UTC)

So it works in Wikipedia or it does not? -- Pütz M. (talk) 16:18, 27 March 2014 (UTC)

It works, but you have to use other tools than {{#property:Pxxx}}. -- Lavallen (talk) 16:29, 27 March 2014 (UTC)

OK ... so if I want to create in Wikipedia a template with two parameters, one a property, the second the label, what do I have to do pratically? The basic structure would be {{TplName|1={{#property:Pxx}}|2={{PAGENAME}}}}. But PAGENAME should be replaced by the label of the Wikidata item. How can I do this? -- Pütz M. (talk) 13:50, 28 March 2014 (UTC)

Look at Module:Wikidata at test2wiki. -- Lavallen (talk) 16:56, 28 March 2014 (UTC)

Nah, Module:Wikidata only handles statements. Module:Wikibase is better in this case, as it can fetch the label. So, what Putz should do in this case is twofold, firstly copy Module:Wikibase to the wiki where that template is going to be used, and secondly create an template with the following structure: {{TplName|1={{#property:Pxx}}|2={{#invoke:Wikibase|label}}}}.--Snaevar (talk) 14:53, 29 March 2014 (UTC)

A perfect advice! Thank you so much, Snaevar. -- Pütz M. (talk) 02:45, 2 April 2014 (UTC)

Date formatting in French

In French, the first day of the month is displayed in Wikidata like "1 [month] [year]" (for example "1 janvier 2014") while it should be "1^er [month] [year]" (for example "1^er janvier 2014").

Another issue is that when you paste "1er [month] [2014]" in a Time datatype field, there is an error message "aucune valeur valide reconnu" (= "no valid value recognized").

Could you correct this, please? Thanks in advance. — Ayack (talk) 16:11, 7 March 2014 (UTC)

We have a patch in the queue that will fix a lot of time formatting issues. Can you poke me about this again in 3 weeks if it still is not solved by then? Thanks! --Lydia Pintscher (WMDE) (talk) 19:42, 11 March 2014 (UTC)

Ok. Thanks! — Ayack (talk) 20:20, 11 March 2014 (UTC)

@Lydia Pintscher (WMDE): Hi, as I see no change regarding this issue, I poke you just like you asked. :) — Ayack (talk) 18:50, 8 April 2014 (UTC)

Thanks! Will have a look again why it is stuck. --Lydia Pintscher (WMDE) (talk) 11:31, 10 April 2014 (UTC)

Also dates in Russian should provide declension of month. Infovarius (talk) 06:13, 10 April 2014 (UTC)

still hard to edit Q4167836

When editing description/alias, there're usually timeout.--GZWDer (talk) 14:03, 3 April 2014 (UTC)

I filed this as bugzilla:63763. --Lydia Pintscher (WMDE) (talk) 12:13, 10 April 2014 (UTC)

<wikibase-itemlink>

All items and property links became <wikibase-itemlink>. Can somebody reproduce it?--GZWDer (talk) 04:48, 10 April 2014 (UTC)

Seems fixed now. but there're still <wikibase-aliases-label>, <wikibase-label-empty>, ...--GZWDer (talk) 09:27, 10 April 2014 (UTC)

Just for the records: I also had this problem this morning (around 06:00 UTC). If it was a temporary problem that is fixed now, all is fine, otherwise I confirm that it's not GZWDer's private problem. --YMS (talk) 10:48, 10 April 2014 (UTC) PS: Ah, just saw that some other users are talking about it on the Project Chat already, so my contribution here was unnecessary and may be ignored ;). --YMS (talk) 10:50, 10 April 2014 (UTC)

$number needs to be a integer

Hi all, this error "$number needs to be a integer" keeps popping up when I try to link [nl:Another Language] with [en:Another Language]. Can someone fix this, please? Regards, Tekstman (talk) 06:31, 10 April 2014 (UTC)

Weird. But i've merged the items, so it's fixed for now. Sjoerd de Bruin (talk) 10:59, 10 April 2014 (UTC)

I assume this is bugzilla:63567? --Lydia Pintscher (WMDE) (talk) 11:44, 10 April 2014 (UTC)

Yes. Sjoerd de Bruin (talk) 11:52, 10 April 2014 (UTC)

Different items with same sitelink

I found pairs of items which have the same sitelink:

Category:Edmonton Drillers (2007–2010) players (Q13260681) <-> Category:Edmonton Drillers (2007–2010) players (Q15254147) and Category:Wikipedia table of contents templates (Q9740449) <-> Category:Wikipedia table of contents templates (Q16320263)

Is it a bug? --Pasleim (talk) 18:58, 12 April 2014 (UTC)

See WD:True duplicates. Matěj Suchánek (talk) 19:29, 12 April 2014 (UTC)

Thanks for this link. I reported there a new list with duplicates. --Pasleim (talk) 21:02, 13 April 2014 (UTC)

Errors in summaries

See summaries of recent edits of 67.1.248.68. Matěj Suchánek (talk) 21:32, 12 April 2014 (UTC)

Please be more specific ;-) They look fine to me here. --Lydia Pintscher (WMDE) (talk) 21:34, 12 April 2014 (UTC)

+1; I see no problem. --Succu (talk) 21:36, 12 April 2014 (UTC)

I think he means the fact it is saying 'Added link to [shwiki]: shwiki'. Since the latter 'shwiki' should really be the page added not the wiki name which was repeated less than 10 pixels away. John F. Lewis (talk) 21:40, 12 April 2014 (UTC)

So whats (e.g.) wrong in the history of (E)-4-hydroxy-3-methyl-but-2-enyl pyrophosphate (Q2708007)? --Succu (talk) 22:04, 12 April 2014 (UTC)

"Added link to [shwiki]: shwiki" should be "Added link to [shwiki]: (E)-4-Hidroksi-3-metil-but-2-enil pirofosfat" like the previous edit "Removed link to [shwiki]: (E)-4-Hidroksi-3-metil-but-2-enil pirofosfat". John F. Lewis (talk) 22:08, 12 April 2014 (UTC)

I also saw "Added link to [shwiki]: shwiki"--GZWDer (talk) 12:14, 14 April 2014 (UTC)

Aha! Ok now I see it. I have been looking at a few other edits and they seem fine. Does anyone else see a pattern that'd help track this down? --Lydia Pintscher (WMDE) (talk) 12:16, 14 April 2014 (UTC)

Ohhhh. Looking at the bot's contributions they are all like that. The bot is setting the edit summary there, right? Then it is an issue with the bot it seems. --Lydia Pintscher (WMDE) (talk) 12:18, 14 April 2014 (UTC)

@Dcirovic: Please use meaningful edit summary.--GZWDer (talk) 12:20, 14 April 2014 (UTC)

At the beginning of my recent set of bot additions of interwiki links, I was having difficulties with logging into wikidata as a bot, even though I was logged in as such elsewhere. For that reason, few edits were unintentionally made with my IP address. The "(E)-4-Hidroksi-3-metil-but-2-enil pirofosfat" entry, and couple of others, were used for debugging. I would remove my IP change, modify bot configuration, and test it. The sequence was repeated few times, until the cause of the problem was identified. No harm was done, and only a small number of such changes were made.

I think that the change comments such as: "Added link to [shwiki]" are quite sufficient. I assume that the cause of confusion, are the deletions of my IP edits. If this community requires more elaborate comments in such cases, I will be glad to accommodate that. --Dcirovic (talk) 17:32, 14 April 2014 (UTC)

@Dcirovic: For your tests you should use test.wikidata.org. --Succu (talk) 17:50, 14 April 2014 (UTC)

Searching categories

See Wikidata:Project_chat/Archive/2014/04#Searching_categories. Q9107354 is not in the result of [1].--GZWDer (talk) 12:44, 14 April 2014 (UTC)

The issue is that Category:Unionoida is treated as one term and not two. The same will happen with project pages for example. Can you please file a bug for that? We'll have to see what we can do about it. Adding an alias Unionoida makes it work. --Lydia Pintscher (WMDE) (talk) 13:00, 14 April 2014 (UTC)

Defective rendering of large numbers in French

It was reported that field number of deaths (P1120) of World War I (Q361), rendered as "16,563,868" in English, appears as "16 563 868" in French (should be "16 563 868"). Is there a bug tracking this issue ? LaddΩ chat ;) 16:01, 14 April 2014 (UTC)

Same in Hungarian for example for population (P1082). --JulesWinnfield-hu (talk) 16:22, 14 April 2014 (UTC)

That should be bugzilla:61911. Fix is doen and waiting for the next deployment. --Lydia Pintscher (WMDE) (talk) 09:19, 15 April 2014 (UTC)

Wrong rendering of time values

See the source of instance of (P31) in Aristobulus I (Q335124). I've added it via wbeditentity. --Ricordi samoa 05:53, 15 April 2014 (UTC)

<value time="+00000002014-04-15T05:25:44Z" timezone="0" before="0" after="0" precision="14" calendarmodel="http://www.wikidata.org/entity/Q1985727" />

You have added a precision > 11 and written hour, minute and second.

That looks like a known bug to me. -- Lavallen (talk) 07:17, 15 April 2014 (UTC)

Yes that would be precision of seconds which are not supported at the moment - only days or larger. --Lydia Pintscher (WMDE) (talk) 08:59, 15 April 2014 (UTC)

This edit should no longer be possible with the next deployment. --Lydia Pintscher (WMDE) (talk) 09:02, 15 April 2014 (UTC)

Have you considered that it could be more useful to support hour, minutes and seconds correctly? Otherwise, calling the datatype "time" is a bit confusing. --Ricordi samoa 19:45, 15 April 2014 (UTC)

Of course ;-) But that is quite a bit more complicated (conversions between timezones anyone?) So for now this is the solution. --Lydia Pintscher (WMDE) (talk) 20:41, 15 April 2014 (UTC)

License

After a long discussion in the PC, I am just wondering if someone from the development team dealing with rights and licenses can give a feedback about the problem of incorporation of some large parts of other databases in WD after the independent imports of hundreds of contributors. Isolated imports are covered by the short citation rule and by giving the source you can import what to want. But when this is done thousands times and the same sources are used, important parts of some documents/databases will be integrated in WD and then this will be a potential problem according to the law (both EU an US). Shouldn't we modifying our license to reduce the problem by applying the CC-BY which is often one of the main common rights required by other databases or public documents ? And don't look at the WMF because I already asked that question and they just said to look with WD about that. Snipre (talk) 19:38, 9 April 2014 (UTC)

I am not a lawyer and therefore will refrain from advice on the legal parts of this. I am however absolutely sure that CC-0 is the only right license for Wikidata and that we should not change it. There are several reasons for this. Here are a few:

No matter what license we switch to it will not solve the import problem. There are simply too many licenses out there to make this a deciding factor.
Licensability of data is disputed anyway. We're just making sure everyone knows our stance on this is "do whatever you want" which is basically what people can do most of the time anyway.
Licensing is either a pain on the producer or re-user. I am absolutely convinced that we have to be the ones bearing the pain if we want to be successful.
We do not need to import other large databases. We're not about having all the data out there. Let's grow slowly and build a useful knowledgebase - not a data graveyard.

I am absolutely convinced that a license change is one of the very few things that can kill Wikidata. Let's not do that.

--Lydia Pintscher (WMDE) (talk) 11:42, 10 April 2014 (UTC)

@Lydia Pintscher (WMDE): Perhaps my comment was not clear enough and I should focus on the real problem of the data import instead of trying to propose a solution. I just take one example of the french or the swiss communes: data about these administrative entities is provided only by the statistical services of both countries. So even if you use another document as source, the primary source is and stays the statistical services. Both services have some copyright on the data: the french ask only for the credit here and the swiss one asked for the credit and for no commercial use (here). So for a strict application of the CC0, we won't be able to use any data directly or indirectly from this two databases because we don't ensure the credit outside of WD with a CC0 lisence. That's the first thing.

The second thing is about the data import. Right now without any massive data import we can import individually data from these databases according to the short citation rule, but as the contributors will work the totality of the databases will be integrated in WD. So there we will have a problem according to the EU law because of the presence of those databses in WD without respecting their lisences. And as these databases are the only ones providing data about the communes it won't be difficult to find the source.

So the question is this one: WD is under the CC0 lisence, according to EU law about databases and without any massive import from other databases having at least a CC-BY lisence (credit), what will happen if by a the result of independent efforts of several contributors major party or the totality of a database under a CC-BY lisence will be present in WD ?

Can we argue good faith in case of demand of deletion or demand to modify our lisence to keep these data and that is ?

Can we expect that public databases won't say anything in that situation ?

As most of public databases in Europe deal with a similar lisence to CC-BY I think we have to clarify this question before letting person doing what they want because even if individually they respect the system, at the end WD won't respect the EU law.

And I already try to ask that question to the WMF and the replied that a WD problem so for me we can continue our job without thinking about future but I think we will have bad surprises once WD will reach a certain size and will be use by a lot of persons.

You can have a CC0 lisence but in that case, in my opinion, we have to be sure that your sources are quite diverse to avoid any risk to have a large amount of an unique database. And for some data this is not possible because there is only one source.

I know that you are not a lawyer but as everyone should know the law there is perhaps a good idea to find someone who can give as least an appreciation of the risk (high risk vs. small risk) to work in our situation. Snipre (talk) 14:38, 10 April 2014 (UTC)

Knowing too much can be equally bad for us because anyone who sues can then argue that we knowingly infringed. We should definitely avoid that. We should act in a best-effort manner. Changing our license will not change anything there. And this is all I can say on-record. Sorry :/ --Lydia Pintscher (WMDE) (talk) 14:55, 10 April 2014 (UTC)

I am no lawyer either but for what I could gather the general principle of copyright license is pretty clear, at least for the EU and the US: databases can be protected in the EU, they can't in the US. As a US-hosted database, it seems unlikely that Wikidata can get into serious troubles for copyright reasons, but we may be required to remove some content to comply with European law. My hunch is that if we have to remove content that clients have grown used to rely on, it could be much more harmful to the project than adopting a more restrictive license right now. That said, I guess we could also bluntly decide that we do not care about European copyright policies, and we could probably get away with that. It seems that by itself, CC0 is incompatible with at least French and Swedish law anyway. --Zolo (talk) 20:25, 10 April 2014 (UTC)

@Zolo. Don't say that US don't have a copyright for databse because database can have a copyright if there is a creative action like the evalutation/selection of data. Snipre (talk) 09:11, 11 April 2014 (UTC)

@Lydia. It's up to you but I think this should be mentioned in some way to the community in order to be sure that everyone who contributes knows that his work is not protected against a possible deletion even if the contributor is doing the job properly. In my case I would say that without a clear position I will avoid to import more data in WD. Snipre (talk) 09:11, 11 April 2014 (UTC)

@Lydia Pintscher (WMDE): Hi, Lydia, I understand your intentions, and it is laudable. I hope that all government offices and scientific institutions will give in the future their data in public domain, but now it is not so! Maybe Wikidata could give its contribution with its example... --Paperoastro (talk) 21:20, 14 April 2014 (UTC)

@Snipre, Lydia Pintscher (WMDE): We have now as possible values "custom value", "unknown value", and "no value". Would it be a reasonable solution to have "external value" and point in the source where is the value, which license it uses, and how to extract it?--Micru (talk) 21:48, 14 April 2014 (UTC)

That's technically infeasible for the foreseeable future. It's also counter to what we want to do here. We want to give everyone easy access to a lot of free and open data. We don't want them to go through the hassle of having to get their data from a lot of different sources and attribute each of them. In addition individual data points are not an issue at all. --Lydia Pintscher (WMDE) (talk) 08:56, 15 April 2014 (UTC)

If what we want is a CC0 database and some data is not CC0, then we can either ignore that data or point towards it. All the data that we have and that we generate still will be CC0, free, open and hassle-free. If in addition to that someone wants to get more data right now they already have pointers to some external sources, but that is a poor solution which doesn't convey license information of each site or the extraction methods... In a way we wouldn't be adding more hassle than the one already exists, just simplifying it and automating it. --Micru (talk) 12:33, 15 April 2014 (UTC)

Interesting idea. Would need quite a bit more elaboration, but interesting idea. --Denny (talk) 16:06, 17 April 2014 (UTC)

@Denny: Another idea is to use a property to refer to non-free data as suggested here: Wikidata:Property_proposal/Generic#non-free_data_available_at --Micru (talk) 20:28, 18 April 2014 (UTC)

file usage commons

If an item uses a picture (f. e. [2] in wolf (Q18498)), it should be listed in the used files on commons (down at the linked Filepage). Greetings, Conny (talk) 06:57, 19 April 2014 (UTC).

That is bugzilla:46358. --Lydia Pintscher (WMDE) (talk) 09:08, 20 April 2014 (UTC)

Problems with AbuseFilter

Tracked in Bugzilla
Bug 64367

Although a filter is set to warn, users are not warned. (Happens since April 9.) Matěj Suchánek (talk) 16:33, 18 April 2014 (UTC)

@Hoo man: Could you have a look please? --Lydia Pintscher (WMDE) (talk) 09:10, 20 April 2014 (UTC)

This still seems to work for wikitext content pages (also on other wikis), so it's probably not a MediaWiki problem. Also there weren't any recent AbuseFilter changes which could have led to this, thus I suspect a Wikibase change to be the cause. This needs further investigation. - Hoo man (talk) 12:20, 20 April 2014 (UTC)

Matěj, can you file a bug please on bugs.wikimedia.org? Thanks! :) --Lydia Pintscher (WMDE) (talk) 13:20, 24 April 2014 (UTC)

@Lydia Pintscher (WMDE): bugzilla:64367. Hope you will find the way to fix this. Matěj Suchánek (talk) 15:06, 24 April 2014 (UTC)

dates show wrong value - bug

User talk:Ivan A. Krestinin#Jan van Eyck (Q102272) Sterbedatum (P570)--Oursana (talk) 19:14, 22 April 2014 (UTC)

This is not a bug. Precision is taken into account after conversion from the stored Gregorian value to the given calendar model. If a bot sets the Julian calendar, the stored date value should be converted first to Gregorian value, but many bots do not do this, and store wrong values. WD is full of wrongly stored dates. --JulesWinnfield-hu (talk) 19:45, 22 April 2014 (UTC)

The only tool that uses behavior that your describe is the latest version of item editor. Bots, previous versions of the editor, Wikidata diff tool (example) uses another behavior. So I think bug is in the latest version of item editor, not in data or in bots. It is very strange display time="+00000001441-01-01T00:00:00Z" precision="9" as 1440. — Ivan A. Krestinin (talk) 20:41, 22 April 2014 (UTC)

The calendar model is used to display the value: Special:ListDatatypes. If you store Gregorian 1441-01-01 with your bot and you set Julian calendar, it means that you refer Julian December 23 1440, that's why you get 1440 with precision 9. This is not a behavior, this is a fact. The diff you referenced displays only the stored value, incorrectly, because it not takes into account the calendar model. I am not development team member, I just learned this from WD. --JulesWinnfield-hu (talk) 21:50, 22 April 2014 (UTC)

In this example day and month are wrong value: 1-30 instead of 2-7, also here (should be correct)--Oursana (talk) 23:44, 22 April 2014 (UTC)

I see that you corrected the value: [3]. The dates are stored incorrectly by the bots, as I said before. Please read Special:ListDatatypes. --JulesWinnfield-hu (talk) 07:27, 23 April 2014 (UTC)

But you can see that the date shown in this diff link summary differs from the given value, the deleted date in Diff link 7. Februar 1317 (Gregorian) showed Januar 30 1317, when I corrected 7. Februar 1317 (Gregorian) diff link showed 15 February 1317. This is confusing and must be a bug--Oursana (talk) 11:51, 23 April 2014 (UTC)

15 February 1317 (Gregorian) = February 7 1317 (Julian) The diff displays the stored value. --JulesWinnfield-hu (talk) 12:28, 23 April 2014 (UTC)

But you see the difflink displays 7 February 1317 (Gregorian)- old edit /15 February 1317 (Gregorian)- new edit, so both gregorian. How does it come to

February 7 1317 (Julian): Normally used calendar also on commons is Gregorian. Should I have made my correction differently? I simply wrote the correct date February 7 1317 which showed correctly but for me confusingly displayed 15 February 1317 (Gregorian) in the difflink--Oursana (talk) 14:40, 23 April 2014 (UTC)

If we use different calendar models to display the values this is the right way. This is not a bug, but you are right that the auto summary and the diff should display the value with the given calendar model or else it is very confusing. --JulesWinnfield-hu (talk) 15:07, 23 April 2014 (UTC)

For dates before 1582 the automatic calendar model is Julian en:Proleptic Gregorian calendar. --JulesWinnfield-hu (talk) 15:15, 23 April 2014 (UTC)

Claim value with wrong type

How could I did this edit at all? Infovarius (talk) 20:43, 23 April 2014 (UTC)

Known issue. Should be fixed with next deployment. Bad... :( --Lydia Pintscher (WMDE) (talk) 13:22, 24 April 2014 (UTC)

Empty diff

? --Ricordi samoa 09:48, 16 April 2014 (UTC)

There is no difference. The IP changed P3x back to the original values. --Succu (talk) 10:14, 16 April 2014 (UTC)

So why did the rollback succeed? --Ricordi samoa 12:57, 16 April 2014 (UTC)

This is interesting because when you move a statement upwards or downwards, there is no visible change in the diff. (Actually, I didn't check whether the IP really moved a statement. The page is too big...) Matěj Suchánek (talk) 14:01, 16 April 2014 (UTC)

I think your revert should have been simply ignored, because there was nothing to revert. May be this is a bug?

Moving statements around should cause an edit summery. I think this is a bug. --Succu (talk) 20:46, 16 April 2014 (UTC)

@Lydia Pintscher (WMDE): --Ricordi samoa 23:35, 23 April 2014 (UTC)

Sorry. Missed this. Very strange. What did you actually change? There are some issues with moving but they should still show up in the diff - just in a bad way. It'd help me with investigating to know what was actually changed. --Lydia Pintscher (WMDE) (talk) 13:19, 24 April 2014 (UTC)

I only clicked the rollback link (even if I knew there was nothing to revert, I wanted to mark all those edits as patrolled). --Ricordi samoa 14:04, 24 April 2014 (UTC)

Hmmm ok. I'll try to investigate some more. Thanks. --Lydia Pintscher (WMDE) (talk) 12:21, 25 April 2014 (UTC)

Special:AbuseFilter/examine/log/198801 and Special:AbuseFilter/examine/log/194686

This seems very strange. I can't reproduce it.--GZWDer (talk) 13:04, 22 April 2014 (UTC)

I am not sure what this is trying to tell me. Can you please describe what the issue is in those two links? --Lydia Pintscher (WMDE) (talk) 13:21, 24 April 2014 (UTC)

@Lydia Pintscher (WMDE): See edit diff:

@@ -1,5 +1,6 @@
 Tooraweenah
 Tooraweenah, New South Wales
+small village just off the Newell Highway about 44 km (27 mi) north east of Gilgandra in the central west of New South Wales, Australia
 Tooraweenah
 Tooraweenah, New South Wales
 item
@@ -16,7 +17,7 @@
 -31.438888888889
 148.91111111111
 
-http://www.wikidata.org/entity/Q2
 
+http://www.wikidata.org/entity/Q2
 q182541$1911E20B-C04A-41D7-86C8-C07A38ECCEAE
 1

These two lines are strange. It made AF34 catches this edit.--GZWDer (talk) 15:05, 25 April 2014 (UTC)

Talk page aliases on the watchlist

When editing a property or an item, the change is shown in the watchlist as "based on (P144)" - very nice. But when editing the talk page then it is shown as "Property talk:P144", which is not very informative. Would it be possible that the alias is also shown for talk pages? (Ex: "Property talk:based on (P144)")--Micru (talk) 08:47, 25 April 2014 (UTC)

I concur, this is annoying not to have a proper label for discussion pages about item and properties. TomT0m ^(talk) 09:07, 25 April 2014 (UTC)

That is bugzilla:52672. --Lydia Pintscher (WMDE) (talk) 12:20, 25 April 2014 (UTC)

At least it is tracked... maybe that would be a good paper cut.--Micru (talk) 18:45, 25 April 2014 (UTC)

Error in documentation

While learning wbeditentity by API, I've found an error: api.php?action=wbeditentity&id=Q42&data={"descriptions":{"no":{"site":"no","title":"no Description Here"}}} should be api.php?action=wbeditentity&id=Q42&data={"descriptions":{"no":{"language":"no","value":"no Description Here"}}}. Best regards. Infovarius (talk) 20:52, 25 April 2014 (UTC)

Introduced in gerrit:115663, pending fix in gerrit:129825. Thanks, --Ricordi samoa 21:36, 25 April 2014 (UTC)

The patch has been merged, but you may have to wait until the next deployment to see it live. --Ricordi samoa 16:37, 28 April 2014 (UTC)