Wikidata

Wikidata:Contact the development team/Archive/2015/10

< Wikidata:Contact the development team‎ | Archive‎ | 2015
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Typo at http://wdq.wmflabs.org/api_documentation.html

"are no more that RADIUS km [...] away from LATITUDE,LONGITUDE"

"that" should be "than".

Cheers! Syced (talk) 08:23, 5 October 2015 (UTC)

https://bitbucket.org/magnusmanske/wikidataquery/pull-requests/9, merged by Magnus (but not deployed yet, it seems). --Ricordisamoa 14:18, 5 October 2015 (UTC)

Strange search engine behavior

Hello, When I search for some word (which in my case is item alias) in top-right side search bar, some suggestions come up, and when I click "Enter" the same suggestions I see in the search results. For me this is normal behavior. But when I search for "♀" character, again several suggestions are shown but without any result when I click "Enter", even if I use "Everything" option from the searcher. I don't know is this normal for the searcher but for me is strange. Also I notice the same problem when I search for some item label which is category, for example "Category:Mammals" - there are suggestions but no results. I thought the problem is in colon (:) but its work for "Template:Taxobox". Regards --Termininja (talk) 10:14, 6 October 2015 (UTC)

Thank you! Will look into it. --Lydia Pintscher (WMDE) (talk) 16:14, 8 October 2015 (UTC)

Typo at http://wdq.wmflabs.org/api_documentation.html

"are no more that RADIUS km [...] away from LATITUDE,LONGITUDE"

"that" should be "than".

Cheers! Syced (talk) 08:23, 5 October 2015 (UTC)

https://bitbucket.org/magnusmanske/wikidataquery/pull-requests/9, merged by Magnus (but not deployed yet, it seems). --Ricordisamoa 14:18, 5 October 2015 (UTC)

Strange search engine behavior

Hello, When I search for some word (which in my case is item alias) in top-right side search bar, some suggestions come up, and when I click "Enter" the same suggestions I see in the search results. For me this is normal behavior. But when I search for "♀" character, again several suggestions are shown but without any result when I click "Enter", even if I use "Everything" option from the searcher. I don't know is this normal for the searcher but for me is strange. Also I notice the same problem when I search for some item label which is category, for example "Category:Mammals" - there are suggestions but no results. I thought the problem is in colon (:) but its work for "Template:Taxobox". Regards --Termininja (talk) 10:14, 6 October 2015 (UTC)

Thank you! Will look into it. --Lydia Pintscher (WMDE) (talk) 16:14, 8 October 2015 (UTC)

Item limit for client

Recently an item limit of 500 for client wikis was added. Despite Wikidata not being a client wiki, it was added here as well.

As Wikidata isn't actually a client wiki, would it be too much of a drain of resources to exempt it from that? --- Jura 09:18, 24 September 2015 (UTC)

I thought Katie had already done that. How much higher would you need it? --Lydia Pintscher (WMDE) (talk) 10:41, 25 September 2015 (UTC)
The per-year lists at Wikidata:Database reports/Deaths at Wikipedia used to display entirely. Maybe 2000? --- Jura 17:53, 25 September 2015 (UTC)
The limit is already set to 500 for Wikidata (while it is 400 for all other clients). Performance-wise it doesn't make a difference whether entities are being used on Wikidata or on any other client (as Wikidata is just a client to itself). How expensive loading an entity actually is depends on many factors, thus sometimes the limit of 500 will already be way to much, while in other cases it might be ok to include more entities. Due to that, it's very hard to have an upper limit that meets most use cases while still making sure the infrastructure wont be negatively affected. - Hoo man (talk) 10:22, 28 September 2015 (UTC)
Technically the difference might be that if it's set higher for any client, the impact might be thousandfold, whereas a change only at Wikidata concerns just one instance.
While it may appear technically as a client, functionally it's the place where all this is maintained and consolidated.
Given that the reports didn't generate any performance issues in the past, we might as well keep them working. We did reduce the backlog from 30k to 18k since they were set up! --- Jura 09:02, 29 September 2015 (UTC)
@Lydia Pintscher (WMDE), Hoo man: until or unless a system issue comes up, would you mind increasing it again? --- Jura 08:56, 1 October 2015 (UTC)
Marius says we definitely can't go above 1000 without causing issues right now - probably less. Can you load less entities by using the more specialized Lua functions to get the label etc? Those don't count into the limit. --Lydia Pintscher (WMDE) (talk) 10:51, 2 October 2015 (UTC)
I think using the getLabel function would solve the most important cases, but afaik it only works in the project's default language, so would be English-only. --Zolo (talk) 11:48, 2 October 2015 (UTC)
You should be able to specify the language for them. --Lydia Pintscher (WMDE) (talk) 12:09, 2 October 2015 (UTC)
@Lydia Pintscher (WMDE): can you specify the language using mw.wikibase.label() ? It is not documented. You can specify a language for entity:label(), but as it only if the entity has already been loaded, I don't think it make things any better ? --Zolo (talk) 12:16, 2 October 2015 (UTC)
@Zolo: Making it possible to use convenience functions in Lua for this is tracked in T75460. Do you also need access to labels in languages other than the content language or the user's language in that way or are these needed rarely enough so that it's ok to load the whole entity in those cases? - Hoo man (talk) 17:21, 2 October 2015 (UTC)
@Hoo man:, thanks, I think the user's language would be enough here (the same thing for Wikipedia links would be very useful for Commons). -Zolo (talk) 17:48, 2 October 2015 (UTC) (edited 3 oct)
Given the problem there was with LUA, the list was designed to work mostly without it. It relies primarily on {{#property . Labels are added on import. If it's a problem to keep those lists, I suppose we could drop them. Eventually someone else can come up with another solution. --- Jura 11:52, 2 October 2015 (UTC)
The other option would be to split them up. --Lydia Pintscher (WMDE) (talk) 12:09, 2 October 2015 (UTC)
Hmm .. that seems to work: test. Really odd actually. If you prefer, I suppose we could do that. --- Jura 06:23, 3 October 2015 (UTC)
It would make us loose the convenient check of earlier versions though (of date entered etc). --- Jura 06:28, 3 October 2015 (UTC)
I numbered the lines instead and try to display details only for the first 500 items. Not ideal. I still think that lists of 2000 should be reasonable. --- Jura 12:32, 12 October 2015 (UTC)
Yeah agreed. We'll need to make such lists possible. But we're not there yet. We'll need to spend time on speeding that up. --Lydia Pintscher (WMDE) (talk) 13:47, 12 October 2015 (UTC)
Well we were there in July ;) --- Jura 14:59, 12 October 2015 (UTC)

Problems with Safari using image of grave (P1442)

Two times I could not use image of grave (P1442) with Safari, an waiting circle was turning endlessly, with FF it works. I was probably using different versions of Safari and systems. Perhaps you can consider Safari.--Oursana (talk) 12:51, 4 October 2015 (UTC)

I was wondering if this is a Safari issue, because I have the same problem in Safari but also in Chrome. Do we have a bug for this? It seems another bug that only happens when you work fast. Sjoerd de Bruin (talk) 13:07, 4 October 2015 (UTC)
To me that happens when I select the property, paste the QID after the property name, then notice that I'm in the wrong field, remove it, try to move to the value section ..  – The preceding unsigned comment was added by Jura1 (talk • contribs).
I don't think there is an open one. phab:T96466 describes the same sort of behaviour, but that was closed back in April (not sure whether the bug came back or whether it's a different one). I also see it (using Chromium). It usually happens with instance of (P31) if the value field doesn't appear fast enough - I accidentally start typing in the property field and then when I remove the text again, the value field never appears. - Nikki (talk) 15:03, 4 October 2015 (UTC)
@Oursana, Sjoerddebruin, Jura1: I found a way to reproduce it, so I created phab:T115267. - Nikki (talk) 16:22, 12 October 2015 (UTC)

Creative Destruction !!!

I see there seems to be work on phab:T95287 - creating a separate datatype for 'identifiers', independent of that for strings.
Lydia's comment on Wikidata:Project_chat#Mandatory_language_fields_for_languages_not_recognised_by_Wikidata suggests monolingual text datatype could be changed so we can use any random item as a "language" just as we can use any random item as a "unit" for a quantity.

I think this is a great idea. I was shocked when 'number with units' appeared with no constraints and no built in conversions but it does in fact make thing much more transparent and now I'm convinced it's better.

Once the 'identifiers' have been moved to a new datatype we can combine 'string' and 'monolingual text' into a new 'text with optional language/script tag' datatype, where a text can be labelled with it's language/script, however obscure it's language/script might be. Where the item on 'The One Ring' can record that it's inscription is in 'Elvish' or 'Sindarin' or 'High Elvish' and we don't need to raise a bug - or get an ISO standard amended - first.

Or have I misunderstood where you are going? Joe Filceolaire (talk) 17:56, 6 October 2015 (UTC)

So no more rdfs:label ...@en ? Jheald (talk) 19:23, 6 October 2015 (UTC)
Personally I'm not convinced by that idea. There is already a widely used standard for language tags and it makes sense to me to continue using it. The main problem we have is that only a small subset of the options available are included in our list. Just making any ISO 639-3 language (which are all by themselves valid IETF language tags) available would already solve the majority of the requests I've seen.
Scripts can actually be determined programmatically without the user having to explicitly specify it in almost all cases I can think of (the main exception I'm aware of is simplified vs traditional Chinese). Many languages also have a default script defined by the IETF language tag registry (e.g. Latin for English) and the script should only be specified in the language tag if it's different from that. A well-designed language selector could avoid making the user pick a script at all most of the time (which I think would be good, script is quite a technical idea and in my experience people often get quite confused about it) and determine itself what the script is and whether it should be specified, and something like that would allow using any script for a language without users having to ask or create new items first.
I can think of other issues with using items too, e.g. the default languages shown for a user are based on the Babel extension, which uses language tags, not items. The UI language stuff would also have to understand which items correspond to which language in order to add the right languages for labels when changing the UI language. And if labels/descriptions/aliases are based on items, not language tags, merging two items would affect how labels/descriptions/aliases are merged too, and that would add even more nasty effects if someone does a bad merge (e.g. merging two languages). - Nikki (talk) 12:15, 7 October 2015 (UTC)
Nikki: the whole point of monolingual text is that it does not get adapted to the users preferences. The inscription was in this language, and all users should see the inscription as it is inscribed.
Here is the comment I just added to phab:T97882:
There are Three separate use cases which need to be treated differently
.
Sitelinks. These are determined by the wikis we have. If we have a multiscript or even a multilingual wiki then the sitelinks should follow that.
.
Labels, Descriptions and Aliases. We have agreed in principal that we should be able to have labels etc. in any language and in the different script versions of those languages.
Here the program needs to be able to tell what language each label is in and - for multi script languages - what script. This needs to be combined with fallback languages, automatic transcription, automatically generated descriptions based on claims etc. In practice this does not extend to all languages. A language needs to have a been recorded in some way and be in use to some extent.
.
Monolingual Text datatype. This is used to record actual text - official names, inscriptions etc. It is important to record exactly what language and script the text is in. The whole point of this datatype is to record the original exactly so it must never be automatically transcribed or translated (though there may be a transcription or translation in a separate qualifier claim using a 'translation' or 'transcription' property with some sort of 'multilingual text datatype'). It must be possible to tag this with it's language and script even if that language or script is so rare that this inscription is the only existing example known or if the language and script was invented for one movie.
Joe Filceolaire (talk) 13:54, 8 October 2015 (UTC)
@Filceolaire: I didn't mean that monolingual text properties should be converted in any way. What I mean is that if you can add native label (P1705), name in native language (P1559), etc statements (which are monolingual text properties) to something, it should also be possible to add the same thing as a label or alias for that language. That only works if labels and monolingual text have the same set of allowed languages. - Nikki (talk) 14:10, 8 October 2015 (UTC)
@Nikki Reading my thing above I realised there is a Fourth case - Multilingual Text datatype for comments, instructions, translations etc, where the text is displayed in the users preferred language. This should be more like the Labels and less like the "Monolingual text". Joe Filceolaire (talk) 14:23, 8 October 2015 (UTC)
That's the planned "multilingual text" type, as I understand it. - Nikki (talk) 14:58, 8 October 2015 (UTC)
Oh, ignore that, that's what you said. :D (I do wish monolingual and multilingual didn't look quite so similar) - Nikki (talk) 15:02, 8 October 2015 (UTC)
Also, I wonder if inscription would make more sense as a string with qualifiers to describe exactly how the inscription is written (there is another property like that, but I can't remember which off the top of my head). Looking at the other monolingual text properties, none of the others seems to be quite so tied to a specific script like inscription is, e.g. whether a Serbian name/title/quote (to pick a language where multiple scripts are valid) should be written down or displayed in Latin, Cyrillic or both scripts is user preference, it's also user preference whether it should be all caps or not and what font colour and style should be used, whereas a Serbian inscription does not work like that, the script, whether it's written in all caps or not, the font colour and style are all properties of the inscription itself. That would let people describe that an inscription is in particular styles of scripts (Insular, Fraktur, Sütterlin, etc, just to mention a few Latin script ones) even though it doesn't make sense to have those variants available for other monolingual text properties or labels, since they can't be represented in plain text, since they're considered glyph variations. - Nikki (talk) 14:58, 8 October 2015 (UTC)
Sometimes a place will try to control what it is called and declare the official spelling of it's name in various scripts and in French and English too. Maybe it would be better to combine "string" and "monolingual text" into a "text" datatype to use for quotations and inscriptions etc. and have qualifiers for language, script, font etc. rather than a language tag. Joe Filceolaire (talk) 15:08, 8 October 2015 (UTC)
Well, Kensington Runestone (Q969351) is probably written in a combination of language and script that is unique for this sample. Both the nature of the script (dal/younger/combined futhark) and the nature of the language (medieval/modern scandinavian) is disputed. That looks hard to describe with the present monolingual datatype. -- Innocent bystander (talk) 14:44, 12 October 2015 (UTC)

Stability issue with Primary Sources Tool

It might just be my browser/connection, but each time I add a statement with the tool, the page reloads in slow motion. Is this a general issue or something I should check on my side? --- Jura 12:53, 5 October 2015 (UTC)

I could find this ticket which is about getting rid of the reload completely. --Lydia Pintscher (WMDE) (talk) 16:12, 8 October 2015 (UTC)
If it's a known issue and a ticket already opened for it, I suppose this solves it. --- Jura 13:24, 15 October 2015 (UTC)

Time in hours, minutes and seconds

Hi everybody. As suggested by @Filceolaire: on Wikidata:Property proposal/Event where I ask three properties for time, I ask you if it will become possible in the future to enter the time of a race, for example 3 h 56 min 30 s, or 3:56:30 instead of using decimal numbers. On Wikidata:Cycling, I explain the project to centralise on Wikidata the classifications of cycling races, to make people contribute to Wikidata, it must be very easy and very fast (sorry for my English..., and it is worst when I speak). Jérémy-Günther-Heinz Jähnick (talk) 08:29, 7 October 2015 (UTC)

Yeah we should allow that in the future. It looks like it'll not be super easy on the coding side but we'll need it for a few other things as well. --Lydia Pintscher (WMDE) (talk) 13:53, 12 October 2015 (UTC)
RE:Lydia Pintscher (WMDE) "it'll not be super easy"? Haven't you already a solution in the the coord-datatype? The GUI tells everything in deg/min/sek, but the code behind is only decimal. -- Innocent bystander (talk) 14:24, 12 October 2015 (UTC)
Yeah but the underlying concept is different. For time and others the software will need to know about which strings to shorten how and support two different modes of input (one compound and one not). For geocoordinates we just have to parse a considerably simpler case. --Lydia Pintscher (WMDE) (talk) 12:16, 13 October 2015 (UTC)
Thank you Lydia. Jérémy-Günther-Heinz Jähnick (talk) 13:34, 15 October 2015 (UTC)

Conversion between string properties and external references

Somehow it should be possible to change this from one to the other without breaking everything. Actual text is likely to be monolingual string anyways. --- Jura 09:27, 9 October 2015 (UTC)

Can you clarify what you mean exactly? In general changing the datatype of a property is a breaking change for 3rd parties so we really really shouldn't do it without very good reason. --Lydia Pintscher (WMDE) (talk) 13:49, 12 October 2015 (UTC)
phabricator:T95287 seems to conclude that there should be two different datatypes of strings: strings as we have know plus another new type for external references.
Convertibility between the two isn't planned.
Rather than creating a new type, couldn't we distinguish the two with a new column on the wb_property_info table? --- Jura 14:21, 12 October 2015 (UTC)
Ah. Ok. So we will have a one-time conversion between them based on a list we'll provide for checking before we do the actual conversion. This will minimize impact and keep the property IDs for the existing ones. But it's a breaking change nevertheless which is why we'll only do this when absolutely necessary (and when the underlying data structure allows it). The new datatype is needed as we'll for example do special things for the linked data interface. Right now Wikidata is a dead-end in the linked data web. With this I want to change this by actually making our identifiers link in our exports as well. I consider this very important for the future of the project outside Wikipedia. --Lydia Pintscher (WMDE) (talk) 12:20, 13 October 2015 (UTC)
How would such a new datatype affect for example Finnish Ministers database ID (P2182)? As you see, formatter URL (P1630) in this property depends on your preferred set of language. If I have to choose between Finnish and any other language there is no doubt what I choose. Belive me, I have several Finnish-speaking clients and I have to be in contact with Finnish tax authorities, banks, municipal authorities etc. -- Innocent bystander (talk) 14:10, 13 October 2015 (UTC)
I don't think anything would change for that. --Lydia Pintscher (WMDE) (talk) 14:16, 13 October 2015 (UTC)
What is the difference then? -- Innocent bystander (talk) 14:33, 13 October 2015 (UTC)
The differences are: We no longer rely on the gadget for linking which should speed up page loading time. We put full links instead of just the ID for those databases into our machine-readable exports which makes Wikidata not a dead-end in the linked open data web anymore. And we will separate them in the user interface from the rest of the statements to unclutter it. --Lydia Pintscher (WMDE) (talk) 14:35, 13 October 2015 (UTC)
I don't think it's that much a dead end: beacon files are already available with full details.
This would make them more like Special:Interwiki#Interwiki prefixes. For merely adding or removing external links, a datatype change shouldn't be needed.
What happens when a website goes off? Do we need to change the datatype? What happens when an external identifier finally gets a website? --- Jura 16:01, 13 October 2015 (UTC)
Beacon files exist kinda - not in the core of Wikidata. Also RDF and JSON are what really matters for the larger linked open data web. When a website goes offline we simply remove the respective statement on the property. If an identifier gets a website we simply add it as a statement on the property. --Lydia Pintscher (WMDE) (talk) 16:51, 13 October 2015 (UTC)
Seems to be an non-issue then. Will be able to convert between linked external identifiers and unlinked ones. Anyways, I flagged the string properties that are not external identifiers with Wikidata property with datatype string that is not an external identifier (Q21099935). Some are obviously debatable. --- Jura 09:12, 14 October 2015 (UTC)
Thanks! That's useful. --Lydia Pintscher (WMDE) (talk) 09:19, 14 October 2015 (UTC)
Lydia, could you clarify how much is proposed to change for the (human) user interface? I presume people will go on being expected just to edit the identifier, rather than the full url (since being expected to type in the invariant base elements would just be unnecessary work, and inevitably lead to typos) ? Indeed, as regards what the (human) user sees, I hope there will be no change from the present -- just the simple identifier presented, but formatted as a valid link, since everything else would just be clutter.
Which suggests that the changes should be limited to just the RDF and the JSON -- but even then, will that make it harder for third-party apps like Reasonator to go on presenting to humans just the identifier (albeit linked), rather than the cumbersomeness of the full URL? Jheald (talk) 20:09, 13 October 2015 (UTC)
In the user interface nothing will change besides that we'll move identifiers out of the statement section into their own section to make it less cluttered. 3rd party tools like reasonator can choose if they want the linked or non-linked version. --Lydia Pintscher (WMDE) (talk) 20:13, 13 October 2015 (UTC)

Incremental dumps

I take it that the constraint reports are not updated as there are no new incremental dumps.

What is the status on the dumps? --- Jura 10:38, 2 October 2015 (UTC)

Thanks for poking. I wasn't aware. Marius just poked Ariel. He is looking into it right now. --Lydia Pintscher (WMDE) (talk) 10:49, 2 October 2015 (UTC)
Dump creation has been fixed, thus a new incremental dump for Wikidata should appear within the next hours. - Hoo man (talk) 17:41, 2 October 2015 (UTC)
Thanks. Constraint reports have been generated since. --- Jura 03:35, 3 October 2015 (UTC)

Same problem since 12 October (http://dumps.wikimedia.org/other/incr/wikidatawiki/). --Jklamo (talk) 22:42, 14 October 2015 (UTC)

Seems ok again. Sorry for those hickups but it's not in my hand. I'll poke the people who handle it. --Lydia Pintscher (WMDE) (talk) 16:21, 16 October 2015 (UTC)

Pywikibot: Float numbers

When setting a quantity with pywikibot one needs to create a WbQuantity object: 

    wb_quant = pywikibot.WbQuantity(14.1, None, 0.1)
    print(wb_quant)

The print statement will output this: 

{
    "amount": 14.1,
    "lowerBound": 14.0,
    "unit": "1",
    "upperBound": 14.2
}

But when I try to set this value (https://test.wikidata.org/w/index.php?title=Q1746&type=revision&diff=20758&oldid=20757) then I get a number with around 50 digits. Why does this happen and how can it be avoided? The self-contained example that edits test.wikidata is here: Wikidata:Pywikibot_-_Python_3_Tutorial/Quantities_and_Units#Example. --Tobias1984 (talk) 21:21, 14 October 2015 (UTC)

Many programming languages can't handle floating-point numbers properly. In [1] I use a custom 'float-like' class, but the decimal module may also help you. --Ricordisamoa 22:22, 14 October 2015 (UTC)
@Ricordisamoa: Is it not possible that the API between pywikibot and Wikidata has a bug? If I put some debug-print statements into site.py I can see that the params['value'] is a string: {"amount": 14.1, "lowerBound": 14.0, "upperBound": 14.2, "unit": "http://test.wikidata.org/entity/Q1748"}. Is it PHP that is not able to deserialize the string into a float number? --Tobias1984 (talk) 15:31, 15 October 2015 (UTC)
@Tobias1984: this only seems to show up on the diff page, it looks like it displays correctly (as 14.1, not 14.099999...) on each given revision page. One issue may be that something is switching to single-precision floating-point when it should stick with double-precision all the way through, so there may be a real bug in there. But anything beyond single-precision is rarely necessary for recording measured scientific quantities. So this seems like mostly a display bug to me. ArthurPSmith (talk) 19:11, 15 October 2015 (UTC)
@ArthurPSmith: With a lot of help from the pywikibot irc, we could figure out that the json-dict pywikibot was sending, numbers were without quotes and sign. Sending "+14.1" instead of 14.1 makes all the difference. The patch is on its way. So in a few days the git-version of pywikibot will send clean numbers. --Tobias1984 (talk) 19:20, 15 October 2015 (UTC)
Not only a display bug, you can see it actually saved 14.0999999... --Ricordisamoa 20:06, 15 October 2015 (UTC)
The patch is in the pipeline: https://gerrit.wikimedia.org/r/#/c/246791/ --Tobias1984 (talk) 22:02, 15 October 2015 (UTC)

Rounding

Why do I get rounding to 10^1 digit in this case? I also inputted 10^0 digit for the value and to, what I think is, the standard deviation: https://www.wikidata.org/w/index.php?title=Q1058364&type=revision&diff=254767249&oldid=254576568 --Tobias1984 (talk) 13:56, 4 October 2015 (UTC)

Which string did you input exactly? --Lydia Pintscher (WMDE) (talk) 16:11, 8 October 2015 (UTC)
@Lydia Pintscher (WMDE): I inputted "92,161,753" but after clicking save only "92,161,750" is shown. When you click on edit you can see the exact number i inputted. The interface seems to do the rounding. --Tobias1984 (talk) 20:55, 14 October 2015 (UTC)
Thanks! Will look into it. --Lydia Pintscher (WMDE) (talk) 11:49, 19 October 2015 (UTC)

Useless phpinfo() File

http://tools.wmflabs.org/wikidata-exports/tmp/test.php This file shouldn't be here. Lcy2000 (talk) 10:34, 14 October 2015 (UTC)

@Markus Krötzsch: Can you have a look? --Lydia Pintscher (WMDE) (talk) 16:24, 16 October 2015 (UTC)
Thanks. Tracked at https://github.com/Wikidata/Wikidata-Toolkit/issues/216. --Markus Krötzsch (talk) 12:07, 19 October 2015 (UTC)

Category not found in wikidata response

Hi, I am new in wikidata my requirements is suppose end user type iphone in search filed we got repose from wikidata is


id "Q2766" concepturi "http://www.wikidata.org/entity/Q2766" url "//www.wikidata.org/wiki/Q2766" title "Q2766" pageid 3746 label "iPhone"

but i want Category also in response but here is no filed which is define unique Category for user search "iphone", this is the issues for me please update for same.

Thanks Arvind Aaswani

Thanks. I'll put that on the list. --Lydia Pintscher (WMDE) (talk) 11:02, 21 October 2015 (UTC)

Display references in edit summaries

I was wondering if you already had any requests for this? It seems that in some wikis, instead of adding references to articles, users just add them in edit summaries. It doesn't strike me a useful, but if there is demand for it, maybe we should attempt to address it in one way or other. --- Jura 06:27, 20 October 2015 (UTC)

We really need the reference to be attached to the statement so it can be reused and all. I think doing it via the edit summary is very bad practice - especially on Wikidata where we can properly store it. --Lydia Pintscher (WMDE) (talk) 11:10, 21 October 2015 (UTC)
Agree. In dewiki, people seem to store references in edit summaries instead of articles. Seems very strange. --- Jura 12:04, 21 October 2015 (UTC)

Notifications

Tracked in Phabricator
Task T116485

I start getting notifications for things I do myself, like linking to items I created.

Before only when other people linked to such items, I received a notification.

BTW, it would be helpful if one could deactivate the notifications for some items. --- Jura 14:27, 23 October 2015 (UTC)

@Legoktm: Any chance you have an idea what's going on there? --Lydia Pintscher (WMDE) (talk) 14:34, 23 October 2015 (UTC)
@Legoktm, Jura1, Lydia Pintscher (WMDE): Same thing is reported on svwp. -- Innocent bystander (talk) 11:50, 25 October 2015 (UTC)
Uh this is weird. I'll take a look. Legoktm (talk) 16:20, 26 October 2015 (UTC)
@Jura1, Innocent bystander: The fix for this will be deployed to Wikidata tomorrow and Wikipedias on Thursday. Sorry about this! Legoktm (talk) 05:38, 28 October 2015 (UTC)

Tools is down

https://tools.wmflabs.org/ doesn't respond. --- Jura 16:50, 27 October 2015 (UTC)

It's back. --- Jura 16:55, 27 October 2015 (UTC)

Qualifiers for formatter URLs

  • How shall we specify formatter URLs that shouldn't apply to all items?
  1. Can the sample at Property:P426#P1630 using format as a regular expression (P1793) be made to work?
  2. Could we also add statements that need to be matched?
  3. Some URLs only take part of the identifier (MediaWiki_talk:Gadget-AuthorityControl.js#fix_for_P1323). This could be a block in the regex.
    --- Jura 09:44, 14 October 2015 (UTC)
    • OK I've been trying to understand the first one. Basically what you're trying to do is have several formatter URL statements and based on a regexp one of them should be chosen for a given identifier? My gut feeling says this is pretty bad and something is broken there. Do you have two items where the same property should be linked one way in one and another way in the other? --Lydia Pintscher (WMDE) (talk) 11:54, 19 October 2015 (UTC)
      • Q941612 should link as all "N", Q769736 should link as all "G" to [2] (without the "G" though).
        I think this is likely to happen, e.g., when several authorities issue identifiers within agreed ranges of a common scheme and there is no centralized database.
        Don't worry, it's not broken just because Wikidata lacks a feature ;) --- Jura 12:31, 19 October 2015 (UTC)
        • Aha! Ok thanks. That makes it clearer. I will need to talk to Daniel if we can do this when he's back from vacation. If we can I don't think it'll be done right away though. Do you know how many identifiers we currently have that would need it? --Lydia Pintscher (WMDE) (talk) 11:01, 21 October 2015 (UTC)
          • In the above #1 and #2 includes potentially all properties for external identifiers that don't have a formatter url defined yet or require some special coding in the gadget. #2 (catalog code, inventory number, postal codes, etc) seems more frequent though. We will be able to tell once the properties sorted with this. --- Jura 12:15, 21 October 2015 (UTC)
          • Made the list with that instead. --- Jura 16:20, 28 October 2015 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team/Archive/2015/10&oldid=2149656309"