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

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

Fate of multilingual datatype

@Lydia Pintscher (WMDE), Lea Lacroix (WMDE), Egon Willighagen, Pigsonthewing, Jura1: Hi, I just want to know if the development plan is still up-to-date about multilingual datatype (is it always plan to create this datatype) and if yes, if there is an idea about the timeline for its creation. We had a discussion about this datatype for some properties which will be used in the chemical compounds field and we will be happy to have a feedback before taking any decision.

In that discussion I tried to list some advantages/disadvantages of this datatype but as I am not a soft engineer so perhaps I am wrong. Thank you Snipre (talk) 23:09, 3 September 2017 (UTC)

Hey :) Yes I still want to have it. It wasn't pressing so far because pretty much everything could be done with monolingual text just not as nicely. For the work on Wikimedia Commons support it becomes more relevant again I think. I unfortunately don't have a more concrete answer than "not this year". Sorry. I hope this helps at least a little bit. If you need anything else let me know. --Lydia Pintscher (WMDE) (talk) 17:36, 5 September 2017 (UTC)

Can we get a list of all pages using an entity ?

When editing a Wikipedia article, we can now see a list of all items used by the page. Can we also get a list of all pages using one particular entity ? Can we also see the properties used in an article ? --Zolo (talk) 13:55, 5 September 2017 (UTC)

For the first question, use w:fr:Special:EntityUsage. Matěj Suchánek (talk) 14:03, 5 September 2017 (UTC)
Yes. Alternatively you can click the "Page information" link in the sidebar of an item or article and you will find a list there. It is also shown at the bottom of the edit window of an article. It will not be able to show you (yet) which specific properties are used. --Lydia Pintscher (WMDE) (talk) 17:38, 5 September 2017 (UTC)

Wikis subscribed to this entity

In this page, I see the text: "Wikis subscribed to this entity". What are you trying to tell us by this sentence? (The current word by word-translation into Swedish does not make sense to me, but if you could explain a little more, I maybe can suggest a new translation.) -- Innocent bystander (talk) 19:42, 5 September 2017 (UTC)

Hehe. Fair enough. It is basically a list of wikis that are to be notified about changes happening to this item. These wikis have at least one article using data from that item. If you then go to the wiki in question you can find out which articles exactly. Hope that makes it clearer. --Lydia Pintscher (WMDE) (talk) 20:15, 5 September 2017 (UTC)
Thanks, Lydia! I have proposed a change on sv:WP:WF#Translatewiki. -- Innocent bystander (talk) 16:12, 6 September 2017 (UTC)
Cool. If someone has a better wording... --Lydia Pintscher (WMDE) (talk) 17:24, 6 September 2017 (UTC)

Own datatype for counts

I think datatype quantity should only be used for measured and calculated values for which units may vary.

For properties representing counted values (integer), like number of inhabitants of a country or number of cars involved in an accident, or estimated number of wolves in a pack/area, there should be a separate datatype count. Unit is not to be specificed, but inaccuracy can be given.--Even Thorbergsen (talk) 21:57, 6 September 2017 (UTC)

see Phabricator:T72341 --Pasleim (talk) 22:40, 6 September 2017 (UTC)
@Even Thorbergsen: I have seen population numbers from INSEE, France with decimals. I am quite sure those numbers were estimates, but they were still there! -- Innocent bystander (talk) 06:39, 7 September 2017 (UTC)
The alternative would be to have an “integer constraint” for quantity datatype properties and manage such cases with exceptions. See phab:T167989. —MisterSynergy (talk) 06:50, 7 September 2017 (UTC)
Nice to see that this viewpoint has some support. The technical implementation might be pragmatic, but relevant property values should be presented, for the general public, as an integer regardless of statement input.--Even Thorbergsen (talk) 10:21, 7 September 2017 (UTC)

Small tweak in search results

I'd like to suggest a small tweak in search results. While it's obvsiously very sensible to get a clickable result, it would be great if the item number (Q...) or property number (P...) could also be written somewhere in plain unlinked text in the results. More often than not, I have to copy & paste this number, and it's very inconvenient to have the format copied with it, or have to use all sorts of workarounds depending on the browser and the program you paste the number into. Since there is no SPARQL way that I know of to search descriptions, but only the ridiculous ItemDisambig page that does not support wildcards and is limited to 100 results anyway, the search engine is very very important, and it is already enough user-unfriendly as it is (not being able to restrict search to "in label" or "in description" for example). --Anvilaquarius (talk) 13:49, 8 August 2017 (UTC)


Could you tell me what you are doing and what your current workflow looks like with an example please? I'd like to understand the problem better. --Lydia Pintscher (WMDE) (talk) 15:32, 27 August 2017 (UTC)
I search for a placename, let's say, Manchester: https://www.wikidata.org/w/index.php?search=&search=manchester&title=Special:Search What I need is Q18125 in possibly plain text in my clipboard, to paste it to OpenOffice Calc (or Excel, or whatever). Now of course I can "copy link address" in my browser, but that's complicated and gives me more than Q18125, namely https://www.wikidata.org/wiki/Q18125. Of course I could go to the Q18125 text shown on the page and try to get that, but it will always get some parantheses or colon, and most annoyingly the format (as link). The quickest way now is actually to click on the entry I neeed and then copy from there, most conveniently in the URL bar by the way (since even in the https://www.wikidata.org/wiki/Q18125 page, the Q18125 is only there in too big a font which will get on my nerves when pasting into another application). I know there are several solutions for browsers to copy without format, but this is all a hazzle. Why not just write the Q18125 somewhere in the search result page (maybe in a not too big, normal font, without links and with just spaces around it. It would make everything so much easier. --Anvilaquarius (talk) 19:16, 6 September 2017 (UTC)
@Anvilaquarius: A different approach to this kind of challenge, but have you looked into Wikipedia and Wikidata Tools ? It includes a function WIKIDATAQID which returns the Wikidata Q-number corresponding to a Wikipedia article. (And so could easily translate a whole column of such names).
You might also look at OpenRefine, which may get closer to the kind of search you are looking for, as opposed to a 1:1 match. Jheald (talk) 22:16, 7 September 2017 (UTC)
Thanks for the answer. I know about the Wikipedia article function, but this is no use for me. I'll have a look at OpenRefine (didn't know about that, all these tools are so confusing and badly named...). It sounds very interesting. --Anvilaquarius (talk) 08:35, 8 September 2017 (UTC) PS: I tried OpenRefine. Very interesting, but rather useless, since there seens to be no way to include our descriptions (which are Wikidata's only way to dismbiguate between items) into the human reconciliation process. Hence, I will have to stick to my copy&paste methods which in this case are still much quicker. --Anvilaquarius (talk) 09:45, 8 September 2017 (UTC)

Can't save

When entering items as values today, once in a while, I get these nice new green or red borders, but can only click "remove" or "cancel", not "save".
--- Jura 13:09, 10 September 2017 (UTC)

The servers are having problems today. Matěj Suchánek (talk) 13:42, 10 September 2017 (UTC)

Finding the right language for multilingual texts

I think there the monolingual-text datatype now supports a large set of languages including "zxx" or "not applicable" for text with no specific language. But I couldn't find it in the language selector. How should I look for it ? I was trying to add "inscription: 1654 / no specific language" to Q29111144. --Zolo (talk) 09:41, 26 August 2017 (UTC)

This also affects some other small "new" languages. fkv, Kven (Q165795), a minority language in northern Norway, isn't even recogniced by the language-parser: Kvensk -- Innocent bystander (talk) 18:08, 26 August 2017 (UTC)
You can unfortunately only enter them by language code so far because their names are not accessible for us in this place. We have phabricator:T124758 for fixing it. --Lydia Pintscher (WMDE) (talk) 15:39, 27 August 2017 (UTC)
Thank you user:Lydia Pintscher (WMDE), but actually, even using typing the language code "zxx" does not do anything. Maybe that's not the right code ? I used Help:Wikimedia language codes/lists/all. --Zolo (talk) 14:03, 5 September 2017 (UTC)
Hmmmm this should work. You can see an example on Q18343236 for the inscription statement. --Lydia Pintscher (WMDE) (talk) 17:30, 5 September 2017 (UTC)
Ooh I see, somehow, I had not realized that once you entered the language code, you can save it, even though the language name does not show up. --Zolo (talk) 08:19, 6 September 2017 (UTC)
Alright. I'll note down that the input field isn't helping and needs to be improved. --Lydia Pintscher (WMDE) (talk) 10:16, 11 September 2017 (UTC)

index string typed properties

npz should return items with

⟨ subject ⟩ file extension (P1195)   ⟨ npz ⟩

, numpy (Q38347624)

I suspect that aliases are often overused because of this. d1g (talk) 04:23, 3 September 2017 (UTC)

So you would like to have some properties treated as aliases? Or have some properties generate hits on Special:Search? --Lydia Pintscher (WMDE) (talk) 17:32, 5 September 2017 (UTC)
@Lydia Pintscher (WMDE): second, and possibly first (not sure about disadvantages).
Another usage is codes (external id): sometimes major code is copied as alias to help with results in Special:Search
So, external ids + some string properties should be searchable. d1g (talk) 10:07, 7 September 2017 (UTC)

My idea is to have linguistic strings (labels, aliases) separate from machine-readable strings: external ids, ISO codes, extensions, mime types and such. d1g (talk) 10:14, 7 September 2017 (UTC)

Ok cool. Stas is currently looking into indexing some of the statements. --Lydia Pintscher (WMDE) (talk) 10:17, 11 September 2017 (UTC)

Redirects after archive

Wikidata:Project chat‎, Wikidata:Request a query‎ and Wikidata:Contact the development team‎ host a lot of discussions. But once archived, we lose the topic links that initially pointed to a section on one of the corresponding pages. Currently, I am making use of Wikidata search to find them. Is there any other way by which I can use the original links of a topic on Wikidata:Project chat‎, for e.g., and that gets redirected to the archived page, after archival? Is it possible to redirect these links to the corresponding archive page? John Samuel 10:03, 9 September 2017 (UTC)

A bot could be created for this, you can try WD:Bot requests. Matěj Suchánek (talk) 13:57, 11 September 2017 (UTC)
Thanks. I have made a request. John Samuel 17:26, 11 September 2017 (UTC)

préfet de/des/de la/d' ...

Souvent une personne a été préfet dans trois, quatre ou davantage de départements. Il existe sur wikidata une série de pages Liste des préfets de/des/de la/d' .... Il y a un seul exemple d'un duo de pages wikidata liste des préfets des Pyrénées-Orientales (Q3253581) et préfet des Pyrénées-Orientales (Q28570372). La situation étrange arive que la fonction préfet la moins importante apparaît dans l'infobox, mais pas les autres fonctions préfet. Est-ce possible de créer pour chaque page wikidata liste des préfets d... une page correspondante préfet d... ? --Havang(nl) (talk) 20:42, 10 September 2017 (UTC)

Error in watchlist

 
the error

Hello.I use "Group changes by page in recent changes and watchlist" and "Add direct unwatch/watch markers (×/+) to watched pages with changes (JavaScript required for toggle functionality)" together in Wikidata but the second does not work because of the first.Please fix this.Thank you ديفيد عادل وهبة خليل 2 (talk) 20:29, 13 September 2017 (UTC)

Works for me on watchlist. Matěj Suchánek (talk) 15:31, 14 September 2017 (UTC)
@Matěj Suchánek:So, I have the problem, how do I solve it?Thank you ديفيد عادل وهبة خليل 2 (talk) 16:24, 14 September 2017 (UTC)
You should (obviously) have JavaScript enabled. Then, try it without any gadgets or user scripts, using safemode=1 in the url. When I enable it, it works as it's supposed to. Matěj Suchánek (talk) 16:40, 14 September 2017 (UTC)
Both work alone, but the problem is to mix them together.How do I add text?"Special:Watchlistsafemode=1"?Thank you  – The preceding unsigned comment was added by ‎ديفيد عادل وهبة خليل 2 (talk • contribs).
https://www.wikidata.org/wiki/Special:Watchlist?safemode=1 Matěj Suchánek (talk) 17:24, 14 September 2017 (UTC)
@Matěj Suchánek: They also do not work together.Please request a solution for this error.Thank you ديفيد عادل وهبة خليل 2 (talk) 17:32, 14 September 2017 (UTC)
Fixing something that doesn't work but not knowing why is impossible, I can request nothing but more information and cooperation. Tried in Arabic, works as well. Matěj Suchánek (talk) 18:16, 14 September 2017 (UTC)
@Matěj Suchánek:Image added ديفيد عادل وهبة خليل 2 (talk) 18:34, 14 September 2017 (UTC)


A Gadget does not work with one of beta features

<translate> Mark as patrolled: Adds a [<tvar|mark>Mark as patrolled</>] link to change list items, which have the red exclamation mark.</translate> does not work with "MediaWiki:Eri-rcfilters-beta-label".Please fix this.Thank you ديفيد عادل وهبة خليل 2 (talk) 17:24, 14 September 2017 (UTC)

ambiguous descriptions

 
ambiguous results (similar labels, incomplete descriptions)

Possible solutions:

  • extend width, so that every description in every language would fit it (with respect to max description length)
  • wrap text of description
  • provide full text in html alt= (alt is not used at all now)

d1g (talk) 13:48, 9 September 2017 (UTC)

Ah yeah. Not nice. Ideally descriptions should be written in a way that this doesn't happen since this isn't the only place where this is a problem. Can this be done in this case? --Lydia Pintscher (WMDE) (talk) 13:42, 18 September 2017 (UTC)

Import of interwikis and labels with gadget slurpInterwiki with the label of more than one of the languages includes (....)

I would like to take the attention of developpers to the following issue MediaWiki_talk:Gadget-slurpInterwiki.js#Import_from_wiktionary_-_problem_with_.28.29 as I have some doubts that this issue is not just due to the gadget slurpInterwiki but is related as well to other gadgets and functions.

Do not hesitate to contact me if you need more information on this really annoying issue. --Robby (talk) 19:32, 14 September 2017 (UTC)

Can't undo an erroneous merger

Hi,

Rivière McKenzie (Q22700013) was erroneously merged with Rivière McKenzie (Q21426652) and it seems impossible to undo it. There is a not-so-helpful "invalid data", error message.

Note that a replacement item for Rivière McKenzie (Q22700013) has been created at Rivière McKenzie (Q40108830), you need to remove the sitelinks there to replicate the bug.

Can you have a look at it ? --Zolo (talk) 17:25, 18 September 2017 (UTC)

Know issue. Currently only rollback works to undo this. It's logged as T175984. Mbch331 (talk) 17:51, 18 September 2017 (UTC)
Sorry for that. We're currently preparing a fix. --Lydia Pintscher (WMDE) (talk) 16:02, 19 September 2017 (UTC)

relative position within image (P2677) allows the position of a detail within a larger image to be specified.

it would be nice to show links to image details direct from the Wikidata page; for example on Idleness (Q19953492), for the qualifier-value to be linked in the statement

Idleness (Q19953492) -> depicts (P180) -> kitten (Q147) ;
relative position within image (P2677) -> pct:65,81,35,15

What is needed is a URL formatter of the form:

https://tools.wmflabs.org/zoomviewer/proxy.php?iiif=$P18/$1/,240/0/default.jpg

where $1 is the value of the P2677 qualifier, and $P18 is the value of the underlying image (P18) statement.

I know that special URL formatters have been created for some properties. Is it possible to create one here, that would draw on the value of the P18 property as well as the P2677 qualifier to make the relevant URL ?

As some examples of what this property can do, User:Shonagon has created the first iteration of a tool to create such position strings by drawing a box on a picture; and two nice ways to display all the positioned details in an image can be found in his own Crotos and in Masahide Kanzaki's image-annotator, for example:

It might be nice to think of running an image-centred Wikidata drive, eg to record the positions of all the animals in works containing an animal -- or any other type of detail.

But it would be valuable to see the results linked from the Wikidata page, by linking the value of the P2677 qualifier.

Jheald (talk) 23:26, 18 September 2017 (UTC)

It's a really great idea, thanks Jheald. Indeed, the main issue on using this property is the difficulty to see what is stored. Having the display of image fragments directly on Wikidata page will help for contributors and readers. More, it could reveal all the potential of this property. The wide perimeter and the big volume of visual artworks with image on Wikidata, could make it a so great playground for iconographic indexation, especially in art history. For now, we have the structure but we lack of tools, and the improvment proposed should be a major step.
However there is theoretically an issue on making the correspondance between P2677 in a statement qualifier and an image. Which image ? P18 can have multiple values. Considering the first value of P18 could be a solution. In practice the use of p180 with p2677 in qualifier correponds to 2 dimensional visual works and in those case we have (or should have) almost always only one image for the item.
Best regards --Shonagon (talk) 00:00, 19 September 2017 (UTC)
We could try to deal with this in the legacy gadget. Matěj Suchánek (talk) 07:23, 19 September 2017 (UTC)