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

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

Gadget broken, again

FYI --Ricordisamoa 23:41, 2 May 2015 (UTC)

Thanks. And sorry again. I've bumped up the prio of the ticket you opened for documenting a stable framework. --Lydia Pintscher (WMDE) (talk) 12:24, 6 May 2015 (UTC)

Next step for sister project access

Now is it time for:

  • Enable phase 2 in Wikinews and Wikibooks, and/or
  • Sitelink for Wikiversity?

--GZWDer (talk) 10:52, 4 May 2015 (UTC)

I'd like to go with data access for Wikibooks. But let me ask on Wikidata:Wikibooks to verify it is ok. I had the impression that the rollout of sitelinks didn't go too smoothly. --Lydia Pintscher (WMDE) (talk) 12:31, 6 May 2015 (UTC)

Can we add script codes to monolingual text language codes?

See the discussion at Wikidata:Project_chat#If_it.27s_written_with_a_different_alphabet_is_it_a_different_language?.

Some languages can be written in multiple different scripts. When we put some text in a 'monolingual text' datatype it will be in one of these scripts. We may even have two values for the text - in the same language but in different scripts. ISO 15924 supports additional codes to indicate what script a language text is written in,. Can these additional codes be made legal in "monolingual text"?

See also T97882 on Phabricator which seems to be related. Filceolaire (talk) 00:11, 6 May 2015 (UTC)

links in descriptions

In the discussion at Help_talk:Description#Putting usage instructions in descriptions I suggested that if we could put links in descriptions then we could write descriptions which give guidelines on what is excluded from and included in an item but which are also useful when exported or reused away from wikidata. Could a developer comment there on whether this is a possibility? Filceolaire (talk) 12:41, 30 April 2015 (UTC)

I've seen the issue but I really think we should solve this within the description field. For example by rewriting the description or agreeing that 3rd parties can always remove things in brackets from descriptions. --Lydia Pintscher (WMDE) (talk) 13:38, 30 April 2015 (UTC)
It's a workaround, not a solution ;) TomT0m (talk) 16:28, 30 April 2015 (UTC)
Yes TomT0m it is a work around. The other solution proposed is to have a multilingual 'instructions' field as well as the 'description' and have both show up in the property drop down lists. Lydia how practical is that compared to my 'workaround'?
Lydia Like you I think we should solve this in the description field and having thought about it I came up with this proposal for how to do this. What I want to know is whether there are technical issues that make this proposal for 'links in the descriptions' impractical. Can you give me some feedback on that? Filceolaire (talk) 00:44, 2 May 2015 (UTC)
I don't understand how being able to link in descriptions will make the situation of having usage instructions in the description better. Can you explain please? (I need to do some more research on if it is possible/feasible next week.) --Lydia Pintscher (WMDE) (talk) 09:38, 2 May 2015 (UTC)
when we include notes on using properties or items in the descriptions these notes in every case refer to other properties or items which should be used under certain circumstances and refer to those other properties of items by their Q or P ids. When the descriptions are reused away from wikidata these Q and P ids make no sense. See the examples in the discussion linked above. If the ids are replaced with links then it is a lot easier to rewrite the descriptions so they still make sense even when away from wikidata. It is also a lot easier to follow the notes if you can just click on the link. For example
  • banana - the fruit (for the best-known species, use Q10757112; for the genus, use Q8666090)
can be rewritten
OK? Filceolaire (talk) 19:33, 2 May 2015 (UTC)
Ahhh now that makes sense :) It doesn't however solve the problem we're having here. The issue is that the description is shown when viewing the article on the Wikipedia app. It is shown right below the article title. So there it is really unfortunate to have. That also would not be solved with links in the description. Solutions are being discussed in phabricator:T97566. --Lydia Pintscher (WMDE) (talk) 12:22, 6 May 2015 (UTC)
Lydia I don't think it is that 'unfortunate'. Effectively what we have here is a disambiguation hat-note and that is info that we normally put at the top of an article. There is the issue of what the Wikipedia app does with the link. Options include:
1. keep it as a link to wikidata
2. translate it into a link to a wikipedia page
3. change the link into plain text
4. the wikipedia app could ignore anything in brackets.
This leaves the question as to what other sites should do when they reuse the descriptions and how we indicate the reccommended course of action to those sites.
There is of course the other option - delete all 'Descriptions' and replace these with autogenerated descriptions based on the properties. Then we could rename 'Description" to 'Comment' and use it exclusively for these injstructions. Filceolaire (talk) 05:12, 9 May 2015 (UTC)

Lots of specialist properties or fewer properties with qualifiers?

There is some discussion on Wikidata:Properties for deletion calling for the deletion of specialised properties because they can be replaced with more general properties with qualifiers to clarify the application of the property.

This discussion seems to resolve around assertions about how the code for importing data into infoboxes works and how it will work in future and assertions about what external clients will and will not be able to do once queries are working. Unfortunately these assertions seem to be completely lacking in references and sources. Specifically:

  1. If we have a 'station code' statement with a 'catalog' qualifier specifying which system the code belongs to then how difficult is it for infoboxes to get the catalog info from the qualifier? Will this change in future?
  2. Will it be difficult for external clients to get info from qualifiers? Will this change in the future?
  3. If we have an 'MTR station code' property which is a subproperty of 'station code' will an infobox be able (at some point in the future) to ask for info from 'station code; including subproperties' and find statements using the 'MTR station code' property? This would let us have generic station info boxes. If yes then how soon?
  4. As above but for external clients fetching info?

This is a fairly fundamental issue that affects our design strategy but without some guidance on what tools the development team plan to give us and what tools external query engines will need it is difficult to know how to proceed.
If the questions are already answered in the documentation somewhere then I would be really grateful for some links. I feel woefully ignorant about how this all works. Help? Filceolaire (talk) 00:24, 2 May 2015 (UTC)

In general anything that is "hidden" in qualifiers will be harder to use for 3rd parties. I'll give you a more elaborate answer early next week after clarifying a few things. --Lydia Pintscher (WMDE) (talk) 09:39, 2 May 2015 (UTC)
There is an ongoing discussion at Wikidata:Project chat#Level of granularity of properties. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 2 May 2015 (UTC)
I added a comment on that Project chat section but will add some points here. In my opinion, qualifiers aren't actually needed in lots of places to describe the context and meaning of a property. It is rather clear by the context of the item itself which meaning of a property is required. For example instead of querying for 'MTR station code' one could also query for 'station code' on items which are stations in Hong Kong issued by MTR. I think such queries will be easier for clients than having a bunch of specific properties which can only be used in special contexts. Too many properties require more translation work and seperate things which are connected in reality. -- Bene* talk 12:31, 2 May 2015 (UTC)
So I talked with Daniel some more about this. My comment above still stands. The whole sub-property thing will probably have to be done at some point but I don't expect it to happen in the next months. More than that is really hard to say at the moment. We'll need to test this on actual data I believe once we have the query demo system set up. That should be this summer. Sorry I can't give you more concrete help here :(
Beyond that the one place where we'll definitely need different properties is identifiers that have different URL formatter patterns. Because they are defined per-property. --Lydia Pintscher (WMDE) (talk) 12:39, 6 May 2015 (UTC)
Thanks Lydia. I earnestly ask that the developers have a good look at a timetable for this "query including subproperties" function once you have the query demo system set up. Whether such a function is years away or months away will definitely influence how I (and others I believe) will vote on a lot of property proposals. Filceolaire (talk) 05:51, 9 May 2015 (UTC)

Bruno Bettelheim

Someone has, I believe, erroneously changed Bruno Bettelheim page. I don't remember the stuff about cold parenting and autism, nor the gross reference to a plastic bag over his head. (unnecessary)

The article didn't mention his later, and, as I recall, very happy years at Mills College in Oakland, California in the late 1970's.

thank you,

janet parks swanson, (650) 948-3806

Mills College e-mail not working

Not sure if this is the right place, you might want to try en:Talk:Bruno Bettelheim instead. history show the changes to the page. --- Jura 19:39, 6 May 2015 (UTC)

Illegal value error when adding motto text

The official motto of the Comità per l'Útzil del Glheþ (Q5152026) is "Estetz Talossan, Parletz Talossan" (which means "Be Talossan, Speak Talossan" in English).
When I tried to add it using the official ISO 639-3 language code "tzl" (Talossan (Q1063911)) I got the error "Illegal value: tzl".
Can somebody else add the motto text (P1451) or fix this?
Robin van der Vliet (talk) (contribs) 00:52, 12 April 2015 (UTC)

It isn't a language supported by ULS at the moment so it isn't supported by the monolingual text datatype. We have phabricator:T74126 to add more languages. --Lydia Pintscher (WMDE) (talk) 12:23, 15 April 2015 (UTC)
It is supported now, my pull request got merged. Is there something more that needs to be changed in order for this language to work for motto text (P1451)? Robin van der Vliet (talk) (contribs) 12:04, 20 April 2015 (UTC)
It needs to be deployed here. I will ask the responsible team when that will be. --Lydia Pintscher (WMDE) (talk) 14:38, 20 April 2015 (UTC)
Ok if I got it right it should be coming in 1 week. --Lydia Pintscher (WMDE) (talk) 14:58, 23 April 2015 (UTC)
Does that mean the backend will automatically also support it? Or is there more that needs to be changed? Robin van der Vliet (talk) (contribs) 13:16, 26 April 2015 (UTC)
Almost 2 weeks have passed and I still get the error "Illegal value: tzl". Robin van der Vliet (talk) (contribs) 01:20, 5 May 2015 (UTC)
Bah. Sorry. Then the info I got was wrong it seems. I have now opened a ticket to get this sorted: phabricator:T98314. --Lydia Pintscher (WMDE) (talk) 12:16, 6 May 2015 (UTC)
Maybe it has something to do with this file? Because 'tzl' => 'Talossan' is not included in that file. Robin van der Vliet (talk) (contribs) 15:03, 10 May 2015 (UTC)

Classements de courses cyclistes


Je travaille régulièrement sur des courses cyclistes comme le Grand Prix de Denain 2015 et j'aurais souhaité centraliser le classement général sur Wikidata afin qu'à terme, toutes les versions linguistiques de Wikidata puisse en bénéficier. La propriété ranking (P1352) se verrait associer une valeur, et un qualificatif indiquerait le coureur, puis un autre son temps pour le premier, et l'écart avec le premier pour les coureurs suivants, de telle sorte à ce qu'ensuite ces données puissent être réutilisées par Wikipédia. Je pense que l'association entre le coureur et l'équipe pour laquelle il roule doit se faire dans l'élément du coureur, le tout encadré par des dates.

Ce qui m'intéresse également, c'est de pouvoir centraliser sur Wikidata les palmarès des courses cyclistes (comme le Grand Prix de Denain), de sorte à ce que les petites Wikipédia aient à terme la possibilité d'avoir ces données mises à jour grâce à d'autres locuteurs.

Je m'exprime en français car mon anglais est assez mauvais, mais il est toujours possible de traduire via Google Translate. J'aurais besoin de conseils pour d'autres possibilités offertes par Wikidata car je souhaite que le projet Cyclisme se développe beaucoup plus, et pour cela, il faut que les contributeurs gagnent du temps sur la mise à jour.

Cordialement, Jérémy-Günther-Heinz Jähnick (talk) 16:47, 29 April 2015 (UTC)

@Jérémy-Günther-Heinz Jähnick: You should ask this question at WD:Bistro, or if you do not think that page has enough activity, at the (English version) WD:Project chat. --Izno (talk) 17:08, 29 April 2015 (UTC)
@Izno: : I already write on WD:Bistro and at other users. My questions concern the possibility to create lists on Wikidata , and are sent to developers (Google translate). Jérémy-Günther-Heinz Jähnick (talk) 17:41, 29 April 2015 (UTC)
When I pushed your comment through Google Translate, I did not see anything which required developer intervention (rather, it looks to me like a comment for the community). Do you have a query or request for the developers? --Izno (talk) 20:40, 29 April 2015 (UTC)
Oui, je voudrais qu'il soit possible de créer des listes/des tableaux directement sur Wikidata. Sur fr:Grand Prix de Denain 2015#Classement final, il y a un tableau, et j'aimerais qu'il soit possible de le remplir à partir de Wikidata, avec les 124 classés. Pour celà, il faudrait programmer un modèle de tableau, qui associer à une place (1er, 2e, 3e...) un coureur cycliste et un temps de parcours (pour le 1er) ou un écart avec le 1er (pour tous les autres coureurs). Je pense que de retrouver la nationalité du coureur puis l'équipe pour laquelle il roule lors de la compétition cycliste pourrait se faire directement depuis les éléments concernant les coureurs cyclistes. Il s'agirait de créer une nouvelle fonctionnalité qui n'existe pas encore.
Une deuxième requête serait de disposer d'un système de tableau similaire pour fr:Grand Prix de Denain#Palmarès où je pourrais associer une année/une compétition cycliste un coureur terminant 1er, un terminant deuxième et un terminant troisième (là encore je pense que le pays pourrait être généré automatiquement depuis country of citizenship (P27) dans l'élément du coureur).
Avec ces dispositifs mis en place, ce qui m'intéresse ensuite, c'est leur intégration à la Wikipédia francophone, puis aux autres Wikipédia.
Enfin, j'aurais besoin d'être en contact avec quelqu'un de vraiment compétant pour discuter des propriétés à créer dans le domaine du cyclisme, puisque des infobox vont bientôt être adaptées à Wikidata. Le but est d'avoir un plan bien précis et imposé pour que ça fonctionne et que tout le monde comprenne. Le cyclisme va comptabiliser près de 1 % des articles de la Wikipédia francophone et devient très bien illustrée, c'est donc un domaine qui bouge bien/en pleine progression. Jérémy-Günther-Heinz Jähnick (talk) 10:35, 30 April 2015 (UTC)
I think it is an interesting use-case and at some point it would be useful to hear the developers' solution to it (or the stages of related developments and non-MediaWiki solutions). --- Jura 11:00, 30 April 2015 (UTC)
Pour apporter quelques précisions sur mes demandes, je vais donner deux exemples concrets :
  • Grand Prix de Denain (Q583208) existe en douze versions linguistiques. La dernière course a eu lieu il y a deux semaines et a été remportée par Nacer Bouhanni. La mise à jour s'arrête en 2014 dans la version en italien et à 2011 dans la version en luxembourgeois. Sur sept versions parmi douze, il n'y a que le vainqueur qui est indiqué au lieu du podium. Tout rédiger depuis Grand Prix de Denain (Q583208) permettrait à un seul et unique locuteur de mettre à jour douze versions linguistique, et ce juste après la publication des résultats. Un autre effet est de permettre aux locuteurs des petites Wikipédia d'économiser beaucoup de temps sur la maintenance et la mise à jour.
  • 2015 Paris–Roubaix (Q18720386) existe dans onze versions linguistiques. Chaque locuteur doit lui-même se charger d'écrire le classement, ce qui constitue une énorme perte de temps puisque les informations sont les mêmes, et sont facilement traduisibles grâce à Wikidata. Par manque de temps, on se cantonne à me marquer que les dix premiers alors que grâce à Wikidata, le temps gagné permettrait ici de classer les 133 coureurs qui ont terminé la course, et aux autres locuteurs d'avoir beaucoup plus de temps à consacrer à la rédaction de l'article.
Et ce ne sont ici que deux exemples, étant donné que je réfléchis à d'autres usages de Wikidata. Comme Wikidata va changer pas mal de choses, je préfère demander leur avis à ceux qui développent Wikidata, et qui par rapport à moi sont compétents en la matière. Actuellement, je me déplace chaque semaine pour aller faire des centaines de photos, le but est de centraliser les données de Wikidata pour que le travail soit facilité pour les autres, et ainsi qu'il y ait beaucoup plus de traductions, mais pour ça, il y a énormément de choses à revoir, mais aussi à établir pour que nous avançions tous de manière coordonnée peu importe notre langue. Jérémy-Günther-Heinz Jähnick (talk) 12:21, 30 April 2015 (UTC)

Sorry I am having a hard time understanding this and Google Translate is not very helpful. Can someone who speaks French summarize? --Lydia Pintscher (WMDE) (talk) 12:36, 30 April 2015 (UTC)

He wants to do this (fr:Grand_Prix_de_Denain_2015#Classement_final), that (fr:Grand_Prix_de_Denain#Palmar.C3.A8s) and some terribly detailed stuff in 11 different Wikipedias based on querying full data from Wikidata. --- Jura 12:43, 30 April 2015 (UTC)
Ok that will be possible in the future. --Lydia Pintscher (WMDE) (talk) 12:45, 30 April 2015 (UTC)
A more specific answer would be helpful. Possibly as soon as random access to items is available, it could be possible (provided the rankings are on items such as Q19249082). So 1 to 2 months? --- Jura 12:50, 30 April 2015 (UTC)
Some things can be done when arbitrary access is enabled. Others will need query support. I can't give a date for that unfortunately. Too many things are still up in the air. --Lydia Pintscher (WMDE) (talk) 13:36, 30 April 2015 (UTC)
In fact, I try to have a partner who knows perfectly Wikidata whether what I do is correct vis-à-vis the properties used. I make big changes in how to contribute to the French version of Wikipedia so that our work can benefit immediately to the other language versions, as the 7,000 photographs taken last two months can already benefit to those other language versions. This will actually be a long process of adapting all language versions of Wikipedia, but it will be a big win. I'm in a draft list of the properties which I will propose the establishment.
For fr:Grand_Prix_de_Denain#Palmar.C3.A8s for example, there are different cases to which one does not think immediately, as when the stroke is canceled and it must be shown in the table, when riders arrive tie, or where riders who are doped were downgraded. For rankings cycling races, it's a little simpler, though there sometimes has peculiarities. That's why I prefer to ask all the right questions immediately to avoid causing errors.
I'm in no hurry, and I can wait a few months for some features. The key for me is everything to be functional for 2017, where I plan to make a much bigger project on cycling, which means that Wikipedia articles can be easily translated into many languages​​, given the cost of the project illustration.
Thank you for your reply. Meanwhile, I will devote my free time to settle the missing points one by one, particularly with regard to the properties required for infoboxes. Jérémy-Günther-Heinz Jähnick (talk) 13:48, 30 April 2015 (UTC)
I take care of the problem in the french chat. The problem with this kind of request is their specific application which require a quite important effort of data structure. --Snipre (talk) 13:52, 10 May 2015 (UTC)


The module attempts to check how many items can be retrieved. Is there a way to do this in a more memory efficient way? --- Jura 19:39, 6 May 2015 (UTC)

@Hoo man: is the right person to tell :) --Lydia Pintscher (WMDE) (talk) 19:41, 6 May 2015 (UTC)
In the meantime, I found one way (see code). --- Jura 13:27, 7 May 2015 (UTC)
Not really no... given how entity sizes vary there's no exact limit. Also in the future we will have an own limit on how many entities can be loaded and we will make our in process caching smarter so that memory is probably not going to be a problem (unless you prevent Lua from garbage collecting entity tables you no longer need). - Hoo man (talk) 12:38, 9 May 2015 (UTC)

Eastern Armenian & Western Armenian

Hello Project developers. Armenian language is divided two parts Eastern Armenian & Western Armenian, but has one Wiki (armenian). That is why, I contacting to you. I offer in ltem in armenian section add another article place. --Դեմ խմբակային իշխանությանը (talk) 01:19, 8 May 2015 (UTC)

Items already exist for Eastern Armenian (Q181059) and Western Armenian (Q180945). Or did you mean that it should be possible to enter labels and descriptions and monolingual text in these languages? If so then they need ISO 639-3 language codes but these items (and the infoboxes for these languages on English wikipedia) don't include such codes. If there are codes then please add them to the items for these languages. If these codes don't exist then I don't think these languages can be added. Filceolaire (talk) 05:29, 9 May 2015 (UTC)
You misunderstood me. In Armenian Wikimedia projects articles has written & in Eastern Armenian, & in Western Armenian. --Դեմ խմբակային իշխանությանը (talk) 18:47, 9 May 2015 (UTC)
So you want to be able to link to a Wikipedia article both in Eastern and Western Armenian from the same item (which is not possible atm)? -- Bene* talk 20:47, 9 May 2015 (UTC)
Q19788905 and Novosibirsk (Q883) describe the same object. — Ivan A. Krestinin (talk) 06:23, 10 May 2015 (UTC)
nnwiki has the same problem. Q12715471 and Nynorsk (Q25164) are about the same subject. Høgnorsk (Q1420587) is a third way to write Norwegian. -- Innocent bystander (talk) 08:17, 10 May 2015 (UTC)
This is a known problem and occurs on a number of wikis. See phabricatorT54971 and Wikidata:Wikisource/Development#OldWikisource. It has not yet been solved. Sorry. Guess that is not much help. If you are interested in following up on this then you might want to get a Phabricator login (your wikidata username and login will work) and add your use case. Filceolaire (talk) 15:57, 11 May 2015 (UTC)

Usage of arbitrary access

How can the use of arbitrary access be tracked on a given wiki or centrally? --Daniel Mietchen (talk) 16:35, 11 May 2015 (UTC)

It'll be possible once the database tables are synced to tool labs. The ticket for that is phabricator:T98748. A nice special page and so on is on my plan but not right now. --Lydia Pintscher (WMDE) (talk) 16:26, 12 May 2015 (UTC)
I might suggest you require (socially, via policy/guideline) the use of a template to do so for the interim. That's probably going to be a part of your wiki's solution regardless of getting things together on Wikidata's side. --Izno (talk) 16:58, 12 May 2015 (UTC)
@Lydia Pintscher (WMDE): Is there a bug/task for the special page on phabricator already? If the lookups etc already exist it should be fairly easy to setup a special page for that purpose. -- Bene* talk 17:06, 12 May 2015 (UTC)
No I don't think we have anything yet for that. Feel free to create. --Lydia Pintscher (WMDE) (talk) 17:25, 12 May 2015 (UTC)

WDQ problem: claim[1476]

That problem isn't fixed yet. We still don't get a single result for Query: claim[1476] even though the property is used widely. --Jobu0101 (talk) 11:07, 11 May 2015 (UTC)

Magnus will have to look into that. I can't help there, sorry :( --Lydia Pintscher (WMDE) (talk) 16:24, 12 May 2015 (UTC)
I think Magnus Manske misunderstood the problem. He thought that a new dump could solve it. But it seems to be a problem with a special data type. --Jobu0101 (talk) 19:55, 13 May 2015 (UTC)

strange error on description editing

Please see this. Seems like a bug of the labels-descriptions-aliases box. Candalua (talk) 15:29, 14 May 2015 (UTC)


Are there any plans to add tel to the allowed protocols in the URL data type? At the moment we have the two properties P1244 (P1244) and phone number (P1329) but a decision for one of them would be desirable. --Pasleim (talk) 21:56, 10 May 2015 (UTC)

Both is in theory fine but I'd say string makes slightly more sense here as basically everyone who uses the data will want it without the protocol. --Lydia Pintscher (WMDE) (talk) 16:23, 12 May 2015 (UTC)
P1244 (P1244) is unused since it was created one year ago. I think we sinply can delete it.--Giftzwerg 88 (talk) 22:35, 15 May 2015 (UTC)
Couldn't this be handled along the same sort of lines as identifiers, i.e. storing them as strings and having a way to take the string and format it as a URL? I can't find any decent explanation of what is/isn't allowed in tel URLs (that doesn't require speaking RFC-ese) but looking at the existing data (TABernacle) and the format constraints on phone number (P1329) it looks like it could be fairly straightforward. - Nikki (talk) 06:17, 25 May 2015 (UTC)

Not possible to Automatically add descriptions for templates

When I use the function "Automatic Addition" in the left column to add a description to Q19921848 I get an error message. Error: {"servedby":"mw1130","error":{"code":"not-recognized-language","info":"The supplied language code was not recognized (Unknown language: bh)","messages":[{"name":"wikibase-api-not-recognized-language","parameters":[],"html":{"*":"The supplied language code was not recognized"}}],"*":"See for API usage"}} I used the description "Wikimedia template". Mbch331 (talk) 06:51, 16 May 2015 (UTC)

that was a bug in the autoEdit gadget. should now work but you may have first to clear the cache. --Pasleim (talk) 14:18, 18 May 2015 (UTC)

Finland Swedish (Q1461092)

Fwd: This! Swedish (sv) as it is spoken i Finland have some differences in the preffered set of vocabulary. I think it could be useful both for labels and for the monolingual text-properties. An example is submachine gun (Q178550) where we in Sweden prefer 'kulsprutepistol' while they in Finland prefer 'maskinpistol'. User:Stryn in the diff above talks about bicycle (Q11442) which have some aliases in East-Swedish, who looks strange for a Swede. -- Innocent bystander (talk) 09:37, 14 May 2015 (UTC)

I don´t think this is an issue for the development team. It just depends how things are worked out at fiwiki. There are wikis out there, that respect different regional forms of a language. For example dewiki accepts swiss and austrian terms although there are additional alswiki and barwiki that represent Swiss German and Bavarian /Austrian and also local spellings as long as the article is about a local theme and has not a greater significance. Alswiki initself accepts articles in about four different dialects: Schwizerdütsch, Schwäbisch, Badisch, Elsässisch which differ a lot in spelling and choice of words.--Giftzwerg 88 (talk) 16:48, 18 May 2015 (UTC)
I think that it depends more of svwiki than fiwiki, since it's still Swedish, not at all Finnish language. --Stryn (talk) 17:22, 18 May 2015 (UTC)
Yes, it would fully be up to the template-developers on the local sv-wikis to choose when sv-se or sv-fi is preffered. -- Innocent bystander (talk) 18:59, 18 May 2015 (UTC)
To be more specific: On svwikipedia, dialects are not allowed, otherwise than to describe local versions of words for example in Jämtland. But the Finland-Swedish is not regarded as a dialects. It's regarded as a second official set of vocabulary and grammar, supervised by local authorities in Finland. There are dialects that in some standards are regarded as own languages, like Skånska, Gutamål, Dalmål and the semi-Norwegian Jamtska and Härjedalsmål, but they are not accepted on svwikipedia. The Estonian and Ukrainian versions of Swedish today not have the same official recognition as Finland-Swedish have. -- Innocent bystander (talk) 19:19, 18 May 2015 (UTC)
@Giftzwerg 88: The difference is that Wikidata accepts de-at and de-ch as language forms for labels, descriptions and monolingual text values but it doesn't accept sv-fi. That's why it's an issue for the Wikidata development team rather than the Swedish Wikipedia. - Nikki (talk) 07:12, 25 May 2015 (UTC)


Item (in some languages translated to words for subject, object or element in the user interface) is a page

Is this really a good idea to say an entity is a page in the Glossary ? especially when the entities url are not exactly pages ... TomT0m (talk) 17:34, 21 May 2015 (UTC)

The page is the users simplified model of what (sh)he see. An entity is "the thing out there", and the item is "the thing in here". The thing in here resides on a page, for now. Perhaps this is not how we should describe it, but it is sort of the simplest description that makes sense. Should we say that the item might be just a part of the page when we newer show it as such in the present UI? Perhaps we can say that "is a data structure that resides on a page", but is that easy to understand for the users? Jeblad (talk) 15:13, 22 May 2015 (UTC)
@Jeblad: I would say that primarily an item is an identifier that refers to an external object of concept. Wikidata has infomations about this concept (labels, statements, …), that are available throught, amongst other thing, a wikipage. Is this clear ? TomT0m (talk) 10:50, 25 May 2015 (UTC)
An Item is a representation of the external entity, the identifier is only one attribute of the Item. Note that the internal Entity is a superclass for Item, it is easy to confuse them with external entities. I assume you are referring to the API in "the entities url are not exactly pages". Jeblad (talk) 14:17, 25 May 2015 (UTC)
@Jeblad: And also data dumps and so on. OK for this, what about An item in Wikidata refers to a real world object, concept, event that is given an identifer (an equivalent of a name) in Wikidata together with informations about it. Each item has a corresponding Wikipage in Wikidata. [more bla bla to explain identifiers are used to give the url of pages and to refer to other items in stataments].
This sounds good to me. --Lydia Pintscher (WMDE) (talk) 18:08, 26 May 2015 (UTC)

Scalability: Performing ~100 Wikidata calls per Wikivoyage page rendered

Wikivoyage is the Wikimedia-backed travel guide. Each Wikivoyage article has about 50 sights/etc.

We are considering moving each sight's details (latitude/longitude, price, hours, type, etc) to Wikidata, in order to foster collaboration between the Wikivoyages of all languages. It also allows us to re-use latitude/longitude that Wikipedia have already put on Wikidata.

While it seems technically feasible (and we have indeed started a proof-of-concept, see the "National Art Center" sight here), we are starting to wonder how Wikidata will handle the load.

For each article's ~50 sights, there will be:

We will cache what we can, but still, the page should be re-rendered every time a used Wikidata item's value changes. Typical use case: User modifies latitude/longitude (stored on Wikidata) via a custom embedded UI, and expects the sight to show at the right place when the dynamic map reloads immediately afterwards.

So, that's about 100 calls for each page. Questions:

  • Will it be too taxing for Wikidata servers?
  • Will it be too slow?
  • How can we decrease load, and improve speed?

Thanks for your expert tips! Syced (talk) 04:41, 25 May 2015 (UTC)

Project:Don't worry about performance (Q11864757) is probably the correct approach to take since we don't know what the limits are. --Izno (talk) 07:11, 25 May 2015 (UTC)
Can 100 simultaneous Wikidata requests all return in less than one or two seconds, so that the user don't feel that the site is sluggish? As for server-side load considerations, a quick calculation gives a long-term average of 10 requests per second if we don't make things smarter: Wikivoyage get about 50k edits per month (all languages). Let's guesstimate that associated Wikidata articles get 10 times that amount (better estimates welcome). With 50 sights per edited article (articles with a lot of sights get edited more often than small ones) that would mean 2.5 million Wikidata requests per months, meaning 1 requests per second. If each Wikivoyage renders pages independently (which I believe is the case right now), multiply by 17 (actually less as smallest Wikivoyages have less sights referenced, so let's say 10). Syced (talk) 09:18, 25 May 2015 (UTC)
I would go to WD:DEV for such concerns. They are working on usage tracking of datas on pages and the query requests, who seems to be imporant pieces of the puzzle for such questions. @Lea Lacroix (WMDE):. TomT0m (talk) 09:56, 25 May 2015 (UTC)
You don't need to worry about the performance implications of the {{#property:…}} parser function or of using Lua in this case, as those are cached with the page content (so that data is only being retrieved on edit/ purge). I can't tell for the map endpoint you plan to use for sure (as it's not build/ maintained by us), but that might get overwhelmed easily. - Hoo man (talk) 10:19, 25 May 2015 (UTC)
I am not a developer but as I understood the problem, all data of an item is downloaded once when you open the associated Wikipedia or wikivoyage article. So if you use the data of the page, you don't have any problem of calling several times WD. The problem is if you want to access data of others items: then we need to call several times WD. A limit will be fixed to the number of calls you can perform for other items than the one you are reading. Snipre (talk) 13:58, 25 May 2015 (UTC)
Each of our articles uses about 50 different Wikidata items, that's why I posted this. Syced (talk) 06:49, 26 May 2015 (UTC)

Hey :) What Hoo man said. If you encounter any issues please let us know so we can look into those cases further. --Lydia Pintscher (WMDE) (talk) 18:09, 26 May 2015 (UTC)

Change rank

Hi! Is it already possible to change the rank of a statement per API call?  — Felix Reimann (talk) 19:48, 26 May 2015 (UTC)

No. You'll have to use wbeditentity. --Succu (talk) 19:51, 26 May 2015 (UTC)
Would a specialized call for this be useful? --Lydia Pintscher (WMDE) (talk) 10:36, 27 May 2015 (UTC)
wbsetstatementrank was dropped by the development team. It would be easier to use and safer, but not really necessary, I think. --Succu (talk) 11:40, 27 May 2015 (UTC)
Hmmm right. Now that you say it I remember. We dropped it because it seemed unnecessary back then. So I guess we'll leave it at that unless someone really wants it? --Lydia Pintscher (WMDE) (talk) 12:02, 27 May 2015 (UTC)


Maybe this is already in the pipeline, but a special page sortable by sitelinks to a given wiki could be helpful.

There seems to be no easy way to get items without statements. --- Jura 02:12, 28 May 2015 (UTC)

Does Special:ShortPages come close enough to what you want? --Lydia Pintscher (WMDE) (talk) 07:16, 28 May 2015 (UTC)
If such a special page is created, it should be named Special:EntitiesWithoutStatements and allow filtering by entity type. -- Bene* talk 07:48, 28 May 2015 (UTC)
It's not built into Wikidata, but Wikidata:Tools/External tools#Items without statements by Magnus Manske might be what you're looking for. --Yair rand (talk) 08:02, 28 May 2015 (UTC)
  • Something in the lines with Magnus' tool would be fine. The problem with that tool is that it doesn't really help monitoring new pages for a given wiki nor do much sorting. The existing categories in a given Wiki might be more helpful than the number of sitelinks.
    Of the current MediaWiki ones, Special:UncategorizedPages (at Wikipedia) is probably closet in the general idea. Not sure if we care about PropertiesWithoutStatements, but maybe it should be EntitiesWithoutStatements for the sake of completeness ;) --- Jura 08:33, 28 May 2015 (UTC)
    • Currently there are about 3 million/20% of them (here). --- Jura 08:43, 28 May 2015 (UTC)
      • I've been working on adding statements to those items, by using a autolist that displays items without the most common statements (just for nlwiki atm). You can see the newest items at the end of the list. Just a temporary thing, but a special page with a siteid filter would be great. Sjoerd de Bruin (talk) 08:46, 28 May 2015 (UTC)
        • Even a filter by creating user might help. Personally, I try to make sure that items I create have at least one statement. --- Jura 08:50, 28 May 2015 (UTC)

Link for

Hi! When I am opening an articl in other languages its corresponding link in bhojpuri languge is not diplaying "भोजपुरी" but "bh:article name". For example, open en:Panama and see the link to bhojpuri page appears to be "bh:पनामा". --सत्यम् मिश्र (talk) 05:50, 14 May 2015 (UTC)

I checked and notice it too. In the column with interwikilinks on local Wikipedias (checked EN en NL), it indeed shows the language code followed by the article name. For Panama (Q804) I checked the corresponding entry at the sitelinks and there is only the article name. So it must be hardcoded to show the language code. Just took a random other article United States of America (Q30) and notice the same thing, languagecode + article name. Mbch331 (talk) 07:04, 14 May 2015 (UTC)
@Aude, Hoo man: Can you have a look at this please? --Lydia Pintscher (WMDE) (talk) 15:59, 18 May 2015 (UTC)
The problem is that the language code of bhowiki was changed from bh to bho (see T91240) and bh is no longer supported by MediaWiki. I tried to update the page identifiers using the expoert/importSites maintenance scripts, but caused a minor enwiki outage in the process... due to that I will proceed here with caution, thus this is going to take a few more days. Cheers, Hoo man (talk) 23:49, 18 May 2015 (UTC)
@Hoo man, Lydia Pintscher (WMDE): It is resolved now. But I am not sure how. You people fixed it locally on wikidata or that T91240 has been completed/closed (I see no signs of that)! and we are facing some other problems on bhwiki still i.e. with contentTranslation etc. That is why I curious!--सत्यम् मिश्र (talk) 23:20, 27 May 2015 (UTC)
This is working again as the change causing this got reverted (gerrit:211906), but that's only temporary. I'll file the necessary bugs to get this fixed properly. Cheers, Hoo man (talk) 23:12, 28 May 2015 (UTC)

Logged in but not logged in

I have universal log in, whilst logging in to my en Wikipedia account, I noticed two items that needed to be linked at ko Wikipedia and zh Wikipedia. Using the edit links button on both I received a message that I needed to log in here which I subsequently did. However, on returning to the pages I still received the message that I needed to log in. I rebooted and refreshed the pages and still I got the error warning. This is a problem with Chrome running on Android KitKat 4.4.2. I tried it with my device's other factory supplied browser (unhelpfully called Browser) and that worked.--KTo288 (talk) 19:54, 14 May 2015 (UTC)

Can confirm. Sjoerd de Bruin (talk) 19:55, 14 May 2015 (UTC)
Just for clarification, is this happening on Wikidata or on the client wikis (ie. on Wikipedia itself)? -- Bene* talk 20:58, 14 May 2015 (UTC)
It happens on all wiki's, I was just browsing and you get logged out. (but get the popup in the right to log in) Sjoerd de Bruin (talk) 21:42, 14 May 2015 (UTC)
I've been seeing the same thing in an old version of Chromium in an old version of Ubuntu (Version 34.0.1847.116 Ubuntu 12.04 (260972)) while trying to link Wikipedia pages from various Wikipedias to Wikidata via the "Edit links" option in the sidebar. Every other browser I've used so far has been fine, including Chromium on other computers. Looking at the developer tools, it seems it requests which returns {"query":{"userinfo":{"id":0,"name":"IP address here","anon":""}}} in the browser it doesn't work in and returns my username in the ones it does work in, if that's any help. - Nikki (talk) 02:00, 15 May 2015 (UTC)
@Hoo man: Can you comment? --Lydia Pintscher (WMDE) (talk) 18:06, 26 May 2015 (UTC)
They already closed phab:T99129 as a duplicate saying that it's only a problem if you disable third party cookies. I checked and that's the problem for me too, it works if I re-enable third party cookies. - Nikki (talk) 10:49, 28 May 2015 (UTC)
As said in the bug that should only be a problem if you disable third party cookies (also some privacy plug ins might do that or something similar for you). There are some possibly ways to work around the limitations of disabled third party cookies, but sadly none of these are easy to implement nor integrate nicely with the JavaScript api abstraction we're currently using. For details see phab:T50389. - Hoo man (talk) 23:03, 28 May 2015 (UTC)