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

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

Drop-down properties

I have all drop-down lists in properties not working. It prevents me from adding new claims and changing existing... Is it common problem? Infovarius (talk) 09:26, 11 June 2014 (UTC)

Same problem here (IE 9). --Jklamo (talk) 09:41, 11 June 2014 (UTC)

Are you also using IE 9, Infovarious? Can you link me to a page where it happens please? --Lydia Pintscher (WMDE) (talk) 18:07, 11 June 2014 (UTC)

I have issue with item properties too. Steps to reproduce: open Behemoth (Q4759868), go to instance of (P31) property, click add, enter "Q95074" to value editor. Save button stays in grayed state. This worked day or two ago. All works fine if I enter item`s label instead of Q-key. The issue is very annoying because many items do not have labels in my language and I do not know how to translate its to Russian. My environment: Opera v12.15, Monobook theme. — Ivan A. Krestinin (talk) 19:37, 11 June 2014 (UTC)

Thanks Ivan! That's very helpful. That's ugly... I can't properly reproduce it yet. But I am seeing one issue definitely when trying monobook. There are no suggestions when I type anything like there are in Vector. But the save link is fine for me in Chrome. Will try more tomorrow when I have access to more browsers. --Lydia Pintscher (WMDE) (talk) 19:52, 11 June 2014 (UTC)

I switched to vector theme. Now drop-down list appears after I enter Q95074. If I click to drop-down then save link goes to active state. So the issue is monobook specific. But there is usability issue in vector theme too. I need additional click to drop-down list. This is useful in case of disambiguation. But Q95074 is unique and robust identifier, click to the list is redundant in this case. — Ivan A. Krestinin (talk) 20:34, 11 June 2014 (UTC)

I'm using Monobook in Opera 12 and Firefox. The problem persists in any page. For example, I can't add parent taxon (P171) to Apogon maculiferus (Q1077985) neither by code ("P171") nor by russian label ("ближайший таксон"). --Infovarius (talk) 10:39, 12 June 2014 (UTC)

Ok we found the issue and are working on a fix. Thanks for the poke. --Lydia Pintscher (WMDE) (talk) 14:16, 12 June 2014 (UTC)

Now I can add some properties but hmm in a strange way. Drop-down lists still don't appear and codes P/Q aren't percepted but exact russian labels for property and item work. I suppose I will make errors sometimes when there are ambiguous labels. P.S. In vector skin all works fine, but I don't like it :) --Infovarius (talk) 14:22, 16 June 2014 (UTC)

Same problem here. With Monobook skin on both Firefox and Chrome. :( --Sannita - not just another it.wiki sysop 18:02, 20 June 2014 (UTC)

Hi, this fatal problem persists still, Wikidata are two weeks unusable (uneditable). No progress yet? --ŠJů (talk) 09:32, 25 June 2014 (UTC)

Argh. Sorry! We have the fix but apparently it slipped through and wasn't deployed :( We're getting a deploy window now. Hope to have it done later today or tomorrow. --Lydia Pintscher (WMDE) (talk) 11:40, 25 June 2014 (UTC)

Ok it should be fixed now. You might need to purge. --Lydia Pintscher (WMDE) (talk) 13:00, 25 June 2014 (UTC)

Works OK for me now. Thanks. --Jklamo (talk) 16:11, 25 June 2014 (UTC)

Thanks! All works fine now and even a little better than before :) --Infovarius (talk) 11:59, 2 July 2014 (UTC)

Impossible to set unknown value/no value

Use of unknown value/no value has no effect for me (after selecting them none appears in the box, it is not possible to save). Tried different browsers (IE, Firefox) and skins (MonoBook, Vector). Anyone experiences same problem ? --Jklamo (talk) 13:26, 28 June 2014 (UTC)

Yes it is a known bug we have fixed. We need to put the software change live here still. Sorry. --Lydia Pintscher (WMDE) (talk) 06:27, 1 July 2014 (UTC)

Wikispecies

Any dates for Wikispecies access to Wikidata? Original question.--Micru (talk) 21:44, 30 June 2014 (UTC)

Not yet. But it'll be pretty late in the game. See also Wikidata:Development_plan#Access_for_remaining_sister_projects. --Lydia Pintscher (WMDE) (talk) 06:28, 1 July 2014 (UTC)

Oh, ok. I thought it would be quite easy because it is the same as Commons. Shame that Copy+Paste doesn't work :D --Micru (talk) 07:01, 1 July 2014 (UTC)

It isn't so much a technical issue but a social one. I want it to go along with a bunch of other projects. --Lydia Pintscher (WMDE) (talk) 09:34, 2 July 2014 (UTC)

Script with amazingly long name that breaks the "stop slow script" popup box (and slow enough to cause a browser problem)

Script: https://bits.wikimedia.org/www.wikidata.org/load.php?debug=false&lang=en&modules=dataTypes.DataType%2CDataTypeStore%7CdataValues%2CvalueFormatters%2CvalueParsers%2Cwikibase%7CdataValues.DataValue%2Cvalues%7Cext.centralNotice.bannerController%7Cext.centralauth.centralautologin.clearcookie%7Cext.eventLogging%7Cext.uls.buttons%2Cdisplaysettings%2Ci18n%2Cinit%2Cinterface%2Clanguagenames%2Clanguagesettings%2Cmediawiki%2Cmessages%2Cpreferences%2Cwebfonts%7CglobeCoordinate.js%7Cjquery.AnimationEvent%2CNativeEventHandler%2CPurposedCallbacks%2CaccessKeyLabel%2CanimateWithEvent%2CbyteLength%2Cclient%2Ccookie%2CfocusAt%2Ci18n%2Cinputautoexpand%2Cjson%2CmwExtension%2CtabIndex%2Ctablesorter%2Cthrottle-debounce%2Ctipsy%2Culs%2Cvalueview%7Cjquery.event.special.eachchange%7Cjquery.ui.TemplatedWidget%2Cinputextender%2Clistrotator%2CooMenu%2Cpreview%2CsuggestCommons%2Csuggester%2Ctoggler%7Cjquery.uls.data%2Cgrid%7Cjquery.util.getscrollbarwidth%2ChighlightMatchingCharacters%7Cjquery.valueview.Expert%2CExpertExtender%2CExpertStore%2CViewState%2Cexperts%2Cvalueview%7Cjquery.valueview.ExpertExtender.CalendarHint%2CContainer%2CListrotator%2CPreview%2CToggler%7Cjquery.valueview.experts.CommonsMediaType%2CEmptyValue%2CGlobeCoordinateInput%2CStringValue%2CTimeInput%2CUnsupportedValue%7Cjquery.wikibase.addtoolbar%2Cclaimgrouplabelscroll%2Cclaimgrouplistview%2Cclaimlistview%2Cclaimview%2Cedittoolbar%2Centityselector%2Centityview%2Clistview%2Cmovetoolbar%2Creferenceview%2Cremovetoolbar%2Csiteselector%2Csnaklistview%2Csnakview%2Cstatementview%2Ctoolbar%2Ctoolbarbase%2Ctoolbarbutton%2Ctoolbarcontroller%2Ctoolbareditgroup%2Ctoolbarlabel%2Cwbtooltip%7Cmediawiki.Title%2CUri%2Capi%2Ccldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cuser%2Cutil%7Cmediawiki.api.parse%7Cmediawiki.language.init%2Cmonths%7Cmediawiki.legacy.ajax%2Cshared%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cmw.ext.dataValues%7Cskins.vector.compactPersonalBar.defaultTracking%2CtrackClick%7Cskins.vector.js%7Ctime.js%7Cutil.Extendable%2CMessageProvider%2CNotifier%2Cinherit%7CvalueFormatters.ValueFormatter%2CValueFormatterStore%2Cformatters%7CvalueParsers.ValueParser%2CValueParserStore%2Cparsers%7Cwikibase.AbstractedRepoApi%2CApiBasedValueFormatter%2CApiBasedValueParser%2CEntityIdParser%2CGlobeCoordinateParser%2CQuantityParser%2CRepoApi%2CRepoApiError%2CTimeParser%2Ccommon%2CcompileEntityStoreFromMwConfig%2CdataTypes%2Cdatamodel%2Cexperts%2Cformatters%2Cparsers%2Cserialization%2Cstore%2Ctemplates%2Cutilities%7Cwikibase.experts.EntityIdInput%7Cwikibase.formatters.api%7Cwikibase.parsers.api%7Cwikibase.serialization.entities%2Cfetchedcontent%7Cwikibase.store.EntityStore%2CFetchedContent%7Cwikibase.ui.Base%2CPropertyEditTool%2CentityViewInit%2Centitysearch%2CinitEntity%2CinitTermBox%7Cwikibase.utilities.ClaimGuidGenerator%2CGuidGenerator%2CjQuery%7Cwikibase.utilities.jQuery.ui.tagadata&skin=vector&version=20140702T025133Z&*:510

Rich Farmbrough (talk)

Tracked at Bugzilla: 67420.--Jasper Deng (talk) 06:53, 3 July 2014 (UTC)

JavaScript interface broken after switching language

Looks like JavaScript interface is broken after switching language with Universal Language Selector. I created Q17305033 with Russian label/description, then switched to English for adding properties. English version links leads to special pages for adding links, properties doesn't have Add link (no special page for that?). --EugeneZelenko (talk) 14:50, 2 July 2014 (UTC)

It looks fine here. Can you add "?action=purge" to the end of the URL and see if purging the page this way helps? --Lydia Pintscher (WMDE) (talk) 16:08, 2 July 2014 (UTC)

Purge didn't help. I tried several times. --EugeneZelenko (talk) 14:08, 3 July 2014 (UTC)

See also Wikidata:Project chat#Pages do not load properly when using Firefox. May be this problem relates to Firefox 30. --EugeneZelenko (talk) 13:57, 6 July 2014 (UTC)

Thanks! I tried in Firefox as well and it is still ok for me. Will investigate some more based on project chat discussion. --Lydia Pintscher (WMDE) (talk) 18:27, 7 July 2014 (UTC)

Can't add special values

I currently can't add novalue and somevalue to any property. Is that a known bug ? --Zolo (talk) 18:21, 7 July 2014 (UTC)

Jep. Known. We have fixed it already. Will go live with the next deployment late tomorrow. Sorry. --Lydia Pintscher (WMDE) (talk) 18:23, 7 July 2014 (UTC)

Claim jumps

Whenever I add a claim to an item it jumps to the first position of the item page (new position when reloading the item). Shouldn't it stay at the bottom of the page?--Micru (talk) 11:52, 13 July 2014 (UTC)

Yeah I have that issue on my radar. It's a bit unclear why it is happening. Need to investigate more. --Lydia Pintscher (WMDE) (talk) 11:05, 14 July 2014 (UTC)

If you edit the page before (eg. adding a desription, removing a claim) - i.e. creating a new page version - all works well. Otherwise not. After reloading the page it starts again to fail. This happens since the introduction of statement sorting, I think. --Succu (talk) 11:15, 14 July 2014 (UTC)

timeout-problem (Q183)

Hello all together,

I am have to struggle with timeout on the Item Q183

I can not enter any new items. I constantly get timeout messages. And reloading the page does not solve the problem.

Editing other items smoothly.

My Browser is Firefox ver. 30.0 on ubuntu 13.10

Thanks in advance for advice and help

--DavidMar86hdf (talk) 11:58, 13 July 2014 (UTC)

What are you trying to add? --Lydia Pintscher (WMDE) (talk) 11:00, 14 July 2014 (UTC)

I just had a 13s freeze after I clicked on the add statements link over there (I got a lot of things opened in my Firefox atm, but still 13s is a lot). If one has even more stuff opened or is on a slower machine I'm pretty sure that can turn into a real problem. - Hoo man (talk) 22:53, 14 July 2014 (UTC)

Wikidata broken by design?

Trying to get some answer here since the project chat discussion about how to properly capture uncertainty did not result in any valuable input.
I am still not sure how to properly capture those two cases of uncertainty I listed. An answer that Wikidata does and will not support that is fair enough - although, as far as I know, the intention of Wikidata was not to be a plain fact database but indeed allow modeling uncertainty. Listing the original description of the issues - any answer appreciated (please excuse the catchy headline, just trying to get some more attention than in the project chat):
The first one was on Abraham of Freising (Q330885): According to the reference, the person may have died either on 7 June 993 or 7 June 994. This could be reflected by using a time range or a data type specific qualifier like "alternative date". But, actually, these are two discrete values, basically a list of dates. Eventually, I added both which, at first, seems reasonable and was done before. However, when querying for people having died in 993, one would receive Abraham of Freising (Q330885) without any hint that this information is not certain. Consequently, when querying for people having died in 993, one would assume that this person, in fact, died in 993 and uncertainty becomes fact.
Another example is Wolfgang Carl Briegel (Q1523127). According to one reference, the person may have been a student of Johann Erasmus Kindermann (Q466635). Qualified by the same time range, I added "unknown value" and Johann Erasmus Kindermann (Q466635) for student of (P1066). However, split into two separate statements, that does not really reflect what the reference expresses and applying both statements, backed by the same reference, seems even odder than backing different values for date of death (P570) with the same reference. Expressing that Johann Erasmus Kindermann (Q466635) may have taught Wolfgang Carl Briegel (Q1523127) using student (P802) on Johann Erasmus Kindermann (Q466635) seems kind of impossible without some weird qualifier expressing "may be false". One could argue to just drop that uncertain information and use "unknown value" exclusively, but, well, that would be a loss of information and I am sure such problems occur in other situations as well (an example of a more prominent topic may be to model something like "Roger Godberd (Q7358238) might have been Robin Hood (Q122634)"). Random knowledge donator (talk) 06:56, 25 June 2014 (UTC)

I think those are different cases and in each case it should be treated differently. For instance, for the case of the date of birth, I would mark it as "unknown value" with qualifiers earliest date (P1319)/latest date (P1326). For the second case you could propose a qualifier "source certainty" that would indicate how sure are the sources about the provided information.

But you shouldn't expect to get "ultimate answers". Anyone can give suggestions, and if you don't get feedback, that means that you can come up with a proposal of your own.

OTOH, I agree that Wikidata is broken by design, however that applies not only Wikidata but to any piece of software or reality-representation :) The trick is to move closer little by little every day and not to expect perfect data or knowledge, because by definition it doesn't exist. --Micru (talk) 08:30, 25 June 2014 (UTC)

Thanks for your answer. Using earliest date (P1319) and latest date (P1326) would imply a range though. "Source certainty" is a nice idea. However, one would need to define a constraint of exclusive values (which probably would need to be items to be machine-readable) and what would these values be? Items for "high certainty", "normal certainty", "low certainty"?
Technically, I would like to simply flag values that can be regarded uncertain. When issuing a query, these values could be marked/filtered/whatever easily. As for the first example, it would even be better to allow some kind of alternative values on single statements since the value is basically a list of possible values - but that is probably hard to model from a technical perspective. Flagging statements uncertain could, for example, be simply(?) achieved by extending the "value type" options though: "custom value" (as opposed to "no value" and "unknown value") would be split into something like "certain value" (default) and "uncertain value". In my opinion, the amount of uncertainty ("source certainty") should be left to the reference/content of the reference since capturing that is out of scope for Wikidata as it involves subjective rating. Random knowledge donator (talk) 14:07, 28 June 2014 (UTC)

Seems like my inquiry was not successful once again. Still, I think this is a fundamental problem. I do not demand that the issue has to be solved right now but it needs to be addressed. However, the only outcome of my question is that no one really cares. I refrain from editing data as long as there is no strategy to resolve such a fundamental issue. Random knowledge donator (talk) 08:46, 2 July 2014 (UTC)

Random knowledge donator, how do you expect it to be successful if you don't file a property proposal with whatever property you think it could help you model uncertainty? I agree that it would be nice to have a confidence option for sources, but I am not the one setting the priorities, and I also think that for now we can do that with a property or a qualifier, so we can learn about the needs and possible uses.--Micru (talk) 09:31, 2 July 2014 (UTC)

Repeating myself: Personally, I do not think a property is appropriate. I would be fine if someone would explain how a property would solve the issue. Random knowledge donator (talk) 09:35, 2 July 2014 (UTC)

Random knowledge donator, if we create a new property it could be used as a qualifier: [qualifiers] expand on, annotate, or contextualize beyond just a property-value pair. It is not the same saying "date of birth:1850" than "date of birth:1850" with qualifier "source certainty:low". Both statement and qualifier form a whole and the statement is incorrect if you don't take both into account.--Micru (talk) 10:48, 2 July 2014 (UTC)

I really appreciate your answers and understand your argumentation. However, having a "source certainty" property involves subjectivity by rating the amount of certainty of a source or the fact stated by the source (which even are two different things but that is more of a different story). And which values would be allowed for "source certainty"? Low, normal, high, very low? Ultimately, I would not support having such subjectivity in Wikidata. How is one supposed to rate the certainty of a reference anyway? That is a very scientific matter. In my opinion, the amount of uncertainty should not be subject of Wikidata - however, having a qualifier like "is uncertain" pointing to a boolean "true" seems pointless as well. Random knowledge donator (talk) 11:42, 3 July 2014 (UTC)

Random knowledge donator, when there is source uncertainty it happens mainly because of two reasons: either the source is stating their self-assessed level of uncertainty, or the circumstances do not allow to consider properly the information contained in the source (physical support degradation, obsolete methodology, wrong assumptions, etc). You could generalize both cases with a general "sourcing circumstances" qualifier with objective values like: significant self-assessed uncertainty, incomplete source, source ambiguity, etc. To model information that is disputed by other sources we already have statement disputed by (P1310).--Micru (talk) 08:01, 4 July 2014 (UTC)

OK, I get the point. Still, I have concerns though. Sorry! First off, a generic property is not really usable since users need to figure out upfront that (a) the property exists, (b) it is the one they are actually looking for and (c) what values are supposed to be used for the property. The concept is just really hard to understand resulting in the property not being used at all. And what data type would the values of "sourcing circumstances" have? Are these supposed to be items, individual text or something else? Apart from that, one needs to be aware of the properties ("source uncertainty", "disputed by" and whatever is there and there to come) that mark uncertainty when querying to be able to filter those values eventually. And in the end, still, I think it involves too much subjectivity and detail. How can I judge that a source is incomplete, outdated or whatever? Yes, there are those really obvious matters like the flat earth theory - however, there are sources with much more subtle issues and the reason why a source may be regarded uncertain can be of diverse scientific matters and I would probably not put my head above the parapet and ascertain a reason why a reference may be regarded uncertain. Instead, I would recommend having a look at the original reference to the reader. Even more, in a secondary source, the reason why something is uncertain may not be supplied at all, like for the two dates of the example in the initial post. I am afraid, the concept of using one or more properties to mark uncertainty, still, seems too complex and - please, excuse me - naive. However, I think the two of us are not getting towards a solution here... what about the developers anyway? Random knowledge donator (talk) 07:22, 8 July 2014 (UTC)

I would like to see something done with qualifiers first to see how it is being used. We can then decide about what to do next and if it is worth investing more time into and if it is worth complicating the user interface and data model for it. --Lydia Pintscher (WMDE) (talk) 09:21, 8 July 2014 (UTC)

A rank "uncertain" would be nice, but I do not know which property could represent that... suggestions welcome, Random knowledge donator. --Micru (talk) 19:28, 11 July 2014 (UTC)

No offense, but waiting for "something being done with qualifiers" is not really helpful. Personally, I do not see a sane way to get that resolved with qualifiers (see all my statements). I would rejoice if there is... Using an additional rank is problematic since that would interfere with the original concept of ranks (see discussion on the corresponding help page).
Still, I stick to another snak type technically being the most sane solution. If there is another method to flag statements - fine. But regarding qualifiers: Qualifiers do not allow flagging since snaks always consist out of a property and a specific value (unless you choose another snak type - you get the point...). You would need to restrict the value to one particular item which is true (Q16751793). Regardless of true (Q16751793) being a strange item, the method would be too technical, too complex and not prove usable since, even more, you never would use false (Q5432619) for a property "is uncertain" - instead, you would just not assign the qualifier.
I really think that I made my point clear in all the lines above. If you want to see something made up with qualifiers - I cannot offer that since I am not convinced of that being a proper solution; And since nobody else seems to be interested in specifying uncertainty, we can also wipe that topic off the table since "doing something with qualifiers" is unlikely to happen unless you guys take action and figure out a proper solution.
If there is another proper solution (in terms of being logical and usable), yes, I would gladly accept it but, to me, it seems like uncertainty was not really considered in the original concept of the software. However, being labeled a "knowledge base" in contrast to a "fact database", I would suppose modeling uncertainty should be a core concept of Wikidata. Random knowledge donator (talk) 10:17, 16 July 2014 (UTC)

@Random knowledge donator: The other day I was doing some tests with a qualifier "type of statement" to specify uncertainty, universal quantification (∀) and existential quantification (∃). All these options are necessary (perhaps integrated into the software) if some day we want to move away from mere fact collection into the "knowledge base" realm. You can also do some experiments (create properties and items as needed) on the test instance of wikidata. See for instance:

adaptation of ∀: gold watch
adaptation of ∃: bottle
adaptation of uncertainty: Abraham von Freising

--Micru (talk) 10:58, 16 July 2014 (UTC)

I get the point, but still not convinced, sorry. That seems to capture the logic but for the price of poor usability. "type of statement" is far too generic for users to be aware of using it for specifying uncertainty. Given the huge amount of data that is supposed to be managed in Wikidata, Wikidata cannot rely on experts that have dug into the concepts. I think, being able to represent uncertainty should be as obvious as possible. If not, users will simply not enter data or, probably even worse, enter data as if it was not uncertain... But maybe/probably I am the only one who regards that as important. Random knowledge donator (talk) 09:44, 17 July 2014 (UTC)

@Random knowledge donator: "Uncertainty" is not the only meta-information that statements require. There were users also requesting for a system to protect statements, maybe both features belong together, I don't know. But without testing first what is needed we will not be able to know what to ask for.--Micru (talk) 09:57, 17 July 2014 (UTC)

(Sorry for editing in an archive, but I think this issue is more important.)

I agree with you on whether Wikidata is broken in this respect, it is a lot of things that isn't correct when it comes to handling of simple values values. I'll add bits and pieces as I read your text, but the general idea goes like this

Our mental model of an value is quite complex, but we must represent it in some simple way
Our value can be a range or a bag of values, probably also an ordered set of values
Our value can have several uncertainties and error sources attached to them, and two values in a list might not use the same error model
Any value should refer to some kind of datum, but values that share the same dimension might be compared (not always, we know from sources how some relates to each other but we don't know their absolute value)

Let me give an example: A box can have 3 lengths, those are width, depth and height. We could call them extent. We could then say

width: a
depth: b
height: c

or slightly better

extent: a
extent: b
extent: c

or perhaps even for a list of values

extent: {a b c}

If a, b, and c is 1, 2 and 3 then it might be valid to say

extent: [a c]

Those two last forms are very important if you want to keep the values together in a statement, and they are ordered and unordered sets. The first form is typically called a seq in rdf and the last form a bag.

But the values themselves (the a, b, and c), what if we need to model them more accurately? If we have simple values as the main snak then we can describe that value by using qualifiers, that is it is a reified statement anyhow. But if we have separate values inside a bag or seq inside a main snak, then we need to create the values as blank nodes themselves and we put the additional stuff inside that blank node. The qualifiers for the statements as in the Wikidata UI will then refer to the whole bag or seq of stuff, while we keep the very specific additions inside the blank node. We sort of add another level of qualifiers.

(Note that we can add qualifiers to describe uncertainty for a value in a statement, but when that statement is multivalued this might not be apropriate.)

So in your case with Abraham von Freising (Q330885) you will have

died: { "7 June 993" "7 June 994" }

Simply two dates, no mystery at all except for two dates where most people would expect one. That can be solved with a reference to some publication that describes the situation. It will although be troublesome in some context where you want to use a single value.

Messing around with this opens up some quite funny simplifications. What about open ended intervals for a birth date? The nice thing with this is that we can say something about a value without spiraling down the we need yet another special property.

There is also a situation where a statement holds a reference to a vector. I played around with various representations of that, it seems solvable. Some very important cases are where there exist some kind of statistical analysis, like a w:en:Five-number summary. Those represents something that would probably have been squashed into a single value in the present model.

There are several core concepts that should be implemented, and it should be possible to either write some parseable strings or it should be possible to build them some other way. Personally I like parseable strings, take a look at w:en:Well-known text for example.

I think some of the problems regarding the modeling of this is lack of expertise in statistics, probability and real life wetting and analysis of data. It was simply expected that this was a simple problem with simple solutions, but it is not, it is quite complex. Jeblad (talk) 21:01, 17 August 2014 (UTC)

Multiple items with same label and description

That should only happen in very rare cases. The check seems to be failing. I have filed bugzilla:68164. Thank you! --Lydia Pintscher (WMDE) (talk) 13:06, 17 July 2014 (UTC)

Time format error years before 1000

Year doesn't have 11 digits if less than 1000: https://www.wikidata.org/w/api.php?action=wbgetclaims&format=jsonfm&entity=Q320168&property=P570. --JulesWinnfield-hu (talk) 21:13, 17 July 2014 (UTC)

This isnt a formatting error, as this is the raw data stored. The value is correctly formatted by wikibase. Per this line the code doesnt force the years to have 11 digits. ·addshore· ^{talk to me!} 17:17, 18 July 2014 (UTC)

Special:ListDatatypes states that “the year always having 11 digits”. --JulesWinnfield-hu (talk) 17:50, 18 July 2014 (UTC)

Thanks :) We'll have a look. --Lydia Pintscher (WMDE) (talk) 07:37, 27 July 2014 (UTC)

Wikinews, again

Any plan for enable sitelinks to Wikinews? Probably in August?--GZWDer (talk) 17:00, 18 July 2014 (UTC)

Announced :) --Lydia Pintscher (WMDE) (talk) 07:37, 27 July 2014 (UTC)

Empty diffs, again

This edit was made with this code:

But it doesn't work on Wikidata Sandbox (Q4115189)... --Ricordi samoa 21:03, 19 July 2014 (UTC)

Hmmmm ok this looks like it'll be able to help us track this issue down. Thanks a lot! --Lydia Pintscher (WMDE) (talk) 07:38, 27 July 2014 (UTC)

Non-English label not showing up in editor

I added a non-English label to Q4710607. When I went back to the editor I was surprised to see that the label was blank in the editor. But the history screen shows that the label is still there. Is the editor broken, or is it possible there’s some unlogged change going on in the background? How do I find out? Thanks.—Al12si (talk) 05:03, 25 July 2014 (UTC)

Go to Special:Preferences#mw-prefsection-gadgets and enable the "labelLister" gadget. I filed bugzilla:41994 for this in the early days of Wikidata. Still no remedy it would seem.--Jasper Deng (talk) 05:22, 25 July 2014 (UTC)

Hmm. Enabling “labelLister” does not seem to have any effect. Labels shown are controlled by babel, and if I clear my babel declarations it just shows the last three languages I switched to. And the Chinese label for that page is still shown as blank (even though History claims that it’s still there). Very strange.—Al12si (talk) 05:34, 25 July 2014 (UTC)

Oh… I see how “labelLister” works now. Thanks for the suggestion!—Al12si (talk) 05:44, 25 July 2014 (UTC)

It is likely a caching issue. Can you purge the page please and see if it still happens? You do that by adding ?action=purge to the URL of the item. --Lydia Pintscher (WMDE) (talk) 07:44, 27 July 2014 (UTC)

Hmm, yes, that does indeed resolve the issue. But that also means different things on the page are separately cached, which isn’t something I would expect. Why would aliases (for example, or edits caused by actions on Wikipedia) not cause a caching issue but (local edits to) labels would? This makes no sense to me.—Al12si (talk) 10:33, 27 July 2014 (UTC)

The in-other-languages box is cached separately, yes. Content that is user-specific needs to be cached differently from the one that is not. But it's really not a big deal. It happens rarely, fixes itself and is something we have to live with given Wikimedia's large caching infrastructure. --Lydia Pintscher (WMDE) (talk) 10:49, 27 July 2014 (UTC)

I don’t think it happens “rarely”. When I saw it the first time I thought I was hallucinating because it happened to just one of the two pages I was editing, and I almost went ahead to re-enter the label and would have kept re-entering it (and maybe, I just found out yesterday, get blocked for what amounts to a UI bug) if I didn’t decide to go to the history page to just take a look to see if someone, or something, had reverted my edit. I’ve seen two more instances of this in the past week and I haven’t even edited a lot of pages (less than ten I think), so my impression is that this is actually a very common problem.

When I saw it the first time the page that was not affected has the label imported from Wikipedia. All the affected pages I’ve seen so far are pure local edits.—Al12si (talk) 12:22, 27 July 2014 (UTC)

Typo in language menu

Resolved There is a language “français cadien” in the language menu. I’m pretty sure this should be “français canadien”.—Al12si (talk) 05:30, 25 July 2014 (UTC)

@Al12si: it is not a typo: see Louisiana French (Q880301). --Ricordi samoa 02:45, 27 July 2014 (UTC)

@Ricordisamoa: Oh thanks. I never knew that.—Al12si (talk) 02:49, 27 July 2014 (UTC)

Feature request: string-item datatype

We have many situations where to create a new item for something is "too much effort", but sometimes there is indeed an item to link with. This happens a lot with sources metadata, but the most recent case is Property_talk:P1420#Why_item.3F, where ideally it should be a "red-link" string datatype, that would allow to launch the creation of an item, and it would to link automatically once created. Is that even possible? It would bring much efficiency and a satisfactory workflow.--Micru (talk) 17:01, 20 July 2014 (UTC)

As far as I am concerned, the "red-link" feature would be extra. Having a mixed datatype by itself would already be worthwhile. - Brya (talk) 18:05, 20 July 2014 (UTC)

The issue is: How do we know what to link it to? And if we just allow string how do we get people to link them to proper items once an item exists for it? I am not sure if it is even technically possible but those conceptual hurdles are big. Because we really need the connection between items and Wikidata would become a lot less useful if we have strings all over the place representing the same thing as some items. Machine-readability bye bye. --Lydia Pintscher (WMDE) (talk) 07:41, 27 July 2014 (UTC)

Well Wikipedia uses a format like "[[Q12345|Fantastica horribilis]]", so a mixed field could consist of something like "[[Q12345|Fantastica horribilis]], [[Fantastica amabilis]], Fantastica alba", or a variation of that.

As to the second argument, the alternative would be to have two properties, side by side, one using string, one using item. This would cause the exact same number of strings that are not linked to existing items. So this remains a problem however this is handled. - Brya (talk) 16:35, 29 July 2014 (UTC)

@Micru, Brya: <joke><mode GerardM><grin> GrmRmmm please stop bothering Lydia and the devteam every time you have a Bikeshedding idea and start using the tools you have :)</grin></mode></joke> More seriously, there is also things like monolingual text in the pipe, what is the real issue here ? You can make a statement but not click on create new item ? You better maybe ask to create a new item more easily if it is so hard, not to uselessly conceptually add a new concept in the Wikibase datamodel to bypass a user interface issue. TomT0m ^(talk) 19:06, 29 July 2014 (UTC)

Malformed URL

I get a malformed URL error message when trying to add this url to a statement :

http://www.bundespraesident.at/index.php?id=20&no_cache=1&tx_ttnews[tt_news]=1347&L=0,

Actually, the same string is also buggish when written in a Wikitext:

http://www.bundespraesident.at/index.php?id=20&no_cache=1&tx_ttnews[tt_news]=1347&L=0

--Zolo (talk) 17:06, 29 July 2014 (UTC)

I think we're using the same mechanism as the wikitext parser to see if something is a valid link. In this case the brackets probably annoy it. Which is correct since in wikitext they serve as the signs to mark up a link. I don't think we can deviate from that. You might be able to url-encode them though. --Lydia Pintscher (WMDE) (talk) 15:20, 30 July 2014 (UTC)

Unable to add links to Commons

@Lydia Pintscher (WMDE): It's not possible to add links to Commons, at least via UI. I haven't tried adding from the client site. When there is no link to c: it says that the list of values is complete and the "add" link is gray. Purging doesn't help. I don't know since when this happens. Matěj Suchánek (talk) 11:48, 30 July 2014 (UTC)

Ewwww! Thank you. Will look into it. --Lydia Pintscher (WMDE) (talk) 15:16, 30 July 2014 (UTC)

Should be fixed again. A purge of the page might be necessary. Sorry! --Lydia Pintscher (WMDE) (talk) 15:23, 30 July 2014 (UTC)