Well, I am not sure if this is really a bug but in Q2300097's history. It says (Created an [en] item with values), but that isn't correct as it was created with simplewiki item with values shouldn't it read as follows: (Created and [simple] item with values).? Also it has happened on several of the items I have created with the simplewiki value. I am using Chrome version: 23.0.1271.97, with Windows 7 OS. If you would like any other information or specs to help you reproduce it let me know. Thank you, --Clarkcj12 (talk) 19:26, 2 January 2013 (UTC)
It does that if you're editing with your language set as "English". You can change it to "Simple English" by clicking the link beside your username, and that'll switch it. Ajraddatz (Talk) 19:29, 2 January 2013 (UTC)
I don't know but the only page I have found this on is this page Q899626. It shows all of the languages as English. And they all link to that Page in Wikidata, the number page. When they should be linking to the items on the language projects. And when I click edit then cancel it shows them linking to the English project even though its supposed to link to the Arabic one. I am using Google Chrome 23.0.1271.97, and FireFox 18.0. On Windows 7. If you need any more information let me know thanks. --Clarkcj12 (talk) 20:22, 2 January 2013 (UTC)
I believe this was also a problem shortly after the last update. I did also show all links to English Wikipedia. --Wiki13talk20:34, 2 January 2013 (UTC)
Language specific properties
Is there is any considerations ho language specific properties could be implemented? For example links to articles in old encyclopedia(s), works in online libraries, clones of IMDB, etc? Probably putting all such properties into single data scheme (like, writer, movie, etc) will be overkill because of number of languages. --EugeneZelenko (talk) 04:26, 3 January 2013 (UTC)
From my understanding properties will never be language specific. The properties will be localized (just as the items are) so there will be one property serving all languages. In addition properties can have Wikidata items as values which will work for any language. I cannot see an overkill there. --Spischot (talk) 05:01, 3 January 2013 (UTC)
Creating new Data Items - Some thoughts from a Non-en Wikipedian
As I see it, "Create an item" should have some important change in its user interface sequence.
Instead of asking for a label first, it should initiate a form with a new ItemID (Like Q123456...) and then
let the user add a language code;
then a page name;
Then (s)he could click an option to autocheck any interwiki names in other namespaces corresponding to this page name. If the option is checked, and if there are interwikis, those fields should be displayed and autopopulated. Even the label would be picked up. If a DataItem already exists with those links, user gets a choice to abandon the "new creation" and instead, update the pre-existing item withthe same label.
Then appears the label and detail fields.
If there is an en.wiki page name, that name could be used to autofill the label. (With an option to correct / replace by user's input if he so wishes.)
If there are no direct Interwiki links, user could search for a 'possible' string at the en.wiki. A brief combo list should pop-up from which he may click and choose a link. (Reason: Many non-en Wikis may have equivalent pages, but the interwiki links are just not added by someone yet.)
Once, the en interwiki is chosen, he may even go for another round of interwiki search to try and autopopulate more interwiki links.
This way, adding/updating items from non-en wikis will be much more easy, fast and user-friendly. This method will avoid the need of excessive typing as well as improper labels (i.e. in foreign languages)
Please let me know if this could be discussed and implemented. Thanks
Steps 1 and 2 can be done first by using ItemByTitle. By using that the user will know right away wheter the item exists or not.
Step 3: Two points here. Firstly, entering all interwiki links before adding an label and description would not be an good idea. The current method on Wikipedia is to add interwiki links to articles, so I think that most wikipedia users would skip adding descriptions and labels since they allready have added the interwiki links.
Secondly searching for pages with the same page name in different namespaces is an bad idea. Example: Lets say that the page name is Wikipedia and the user searches in all namespaces and gets Wikipedia:Wikipedia.
Also, the pywikipediabot framework that many bots use has the feature to exclude interwiki links that are from other namepaces. Why do you think that is the case? I'll have to reject your suggestion in this step. This method is way too error prone.
Step 4 can be done right after using ItemByTitle and then add the remaining links (given that the user has enabled slurpInterwiki).
Step 5: Before wikidata was launched, an item without an label showed the page name as the label on the demo repo. If the user chose to edit the label, then that field was blank and the user could type in the label. Your suggestion looks to me as an more complex alternative to that.
Step 6: I think you need to clarify this one. I don´t get either why you specify en.wiki. There are articles on wikipedia that en.wiki does not have, you know. My experience with interwiki links is that wikipedia languages in the same geographical area often have articles about the same thing. For example, the nordic languages (is, fo, da, nn, no...) have articles about the same thing.
There will be a link on each Wikipedia that enables the WikibaseClient extension to add an article to Wikidata. It will behave a little different if the article has sitelinks (add a new sitelink) or if it is new (search for an item and possibly create a new item). I think the plan is to let the gadget prompt for label and description in the given language, but the label can be extracted from the added sitelink if it is missing. Jeblad (talk) 05:31, 31 December 2012 (UTC)
I believe Viswaprabha's message is merely the implementation of a Wizard for creating items. However, I think we need to translate the MW pages so as to have the Create New Item page in local languages. --Rsrikanth05 (talk) 12:40, 3 January 2013 (UTC)
Half as a joke, and out of a mixture of boredom and wanting to try my hand at SVG editing, I created File:Wikidata autopatroller.png, and a corresponding userbox and TopIcon. First of all, improvements to any of these are greatly appreciated. Secondly, do people think the userbox and TopIcon would be useful around here? In a way, they may be more useful on our various home wikis than on here, since virtually every trusted Wikimedian active here is an autopatroller. If even one person thinks they'd like to use either of these, they should feel free to create them locally (preferably at the corresponding locations in my userspace, though there's no way I can require that), giving attribution, of course; but I'm curious as to whether more experienced Wikidatans (Wikidatites? Wikidataers?) think these could see broader use, in template form; clearly it's about as run-of-the-mill as a user right can get, but I can think of a few reasons they could be useful. — Francophonie&Androphilie(Je vous invite à me parler) 15:50, 2 January 2013 (UTC)
Might as well make ones for autoconfirmed and emailconfirmed users as well, since that's about the equivalent level of trust :P. Not opposed to it, but I don't think it's really necessary. Ajraddatz (Talk) 17:09, 2 January 2013 (UTC)
Ooh, very nice. Think I'm gonna switch to that one! I was going off of the File:Wikidata mop.svg model - I wonder if it would be possible to create an alternative for that one too? I think the File:Wikidata barnstar.svg model, which I take it you went off of, is much more aesthetically pleasing.
The way I see it, pretty things like this project a sense of community to any interested new users. (To be clear, Ajraddatz, I have no pretentions that autopatroller is at all important! I mean, user rights in general aren't supposed to make you considered more senior, but that's even more true in this case.) — Francophonie&Androphilie(Je vous invite à me parler) 19:21, 2 January 2013 (UTC)
Only when adding interwikis, there is a warning that Q2377384 has the same.
Unfortunately, the warning doesn't even link to the first item.
How are bots meant to do it?
For items with a frequent label, I might have needed to click on several items (with identical titles) before noticing that one already has the same interwikis (or doesn't). --Docu (talk) 19:40, 3 January 2013 (UTC)
It seems that bot can added interwikis directly. Thus if an item with the same iw already exists, an error appears. --Docu (talk) 23:00, 3 January 2013 (UTC)
New data on population of Greece and Greek cities/villages
Hello, I would like to inform you that the Greek Statistics Authority has issued the population data for all Greece, Greek cities/villages after the 2011 census in http://www.statistics.gr/portal/page/portal/ESYE/BUCKET/General/resident_population_census2011.xls . The list is in Greek. It can be used to update the population data in all relevant articles. I understand that Wikidata aims to take care of such data also in the future.
I would like to know, if someone can tell:
when will Wikidata be able to handle such data? (what are current estimates?)
when in practice you expect it to actually work? (even more guesswork, but just an indication will suffice)
what kind of assistance we can provide?
Furthermore, I want to inform anyone interested for the data from the Greek census, that I have processed the file, so that all data contained in it are in a machine readable form. Just let me know where to upload it or the email address to send it. It is about 11 MB for now. As it is approx. 21.000 lines or so, it might be a good idea to use it as the first mid-scale application of Wikdata for census information. Greetings from Βικιπαίδεια. --FocalPoint (talk) 22:53, 3 January 2013 (UTC)
I'm fairly new to Wikidata, so you might get more precision from other users. Still, an attempt to answer some of your questions:
m:OTRS has arrived! The email is info at wikidata dot org, or wikidata at wikimedia dot org. Anyone with access to Sister projects (f) has access to it. Not really sure what we want to do with this address, but it's ready to go. --Rschen775401:45, 28 December 2012 (UTC)
The queue could be used (for now anyways) for general support requests relating to Wikidata. Lots of emails would get a response directing them to here or another on-wiki page, but quite a few people are more comfortable with sending an email first. Ajraddatz (Talk) 18:50, 28 December 2012 (UTC)
Yeah, I get the feeling that when we go live, we'll start getting people asking "What is this? How do I edit?" etc. --Rschen775419:07, 28 December 2012 (UTC)
Okay, that should be fine. It's not like we have the multiple queues that the English Wikipedia or Commons do :) --Rschen775419:59, 1 January 2013 (UTC)
Hi, I thought this might be a bit handy to help avoid duplication.
Perhaps, each user can be given a page on their Sandbox where they can test whether a link is in use or not. This would greatly help avoid cases of duplication. --Rsrikanth05 (talk) 12:42, 3 January 2013 (UTC)
Try out this script: User:Bene*/sitelink.js it's just beta but it works already. You can enter the language and the title and check whether the sitelink is already in use. Hope you'll like it. --Bene*talk14:47, 3 January 2013 (UTC)
In the toolbox a link called "Check sitelink" should appear. If you click on it, a form appears where you can enter a langcode and a title to search, same as when editing an item. --Bene*talk18:39, 3 January 2013 (UTC)
I would say recently is like some minutes ago. But I don't even re-use items if I create one. I just delete the item. I think Lydia told this to me once that re-using an item is a bad habit as all items should be stable and not be changed to something else. --Wiki13talk16:04, 4 January 2013 (UTC)
How does an item become empty? If it's a duplicate, it should be deleted. Otherwise, it'll at least have a label, right? -- Duesentrieb (talk) 16:05, 4 January 2013 (UTC)
Always delete when something is a duplicate and never reuse, that makes it a lot easier to maintain data integrity. Jeblad (talk) 20:34, 4 January 2013 (UTC)
deployed new code
Hey :)
Just a quick heads-up that we deployed new code earlier today with quite a few bugfixes. All commits that went in are listed here. Let me know if you notice any problems or anything unusual. --Lydia Pintscher (WMDE) (talk) 21:36, 4 January 2013 (UTC)
The last code didn't allow items with the same label and description. Now it's possible to enter duplicates again: Ambra (Begriffsklärungsseite) = Q282745 and Q2515387. --Kolja21 (talk) 00:46, 5 January 2013 (UTC)
Sorry, I manually resolved "Ambra" before reading this. There are more instances of identical pairs (label/description):
A constraint is removed from the transaction handling and is replaced by a soft constraint. I guess something does not work as good as expected, some additional changes done late in 2012 didn't make it into this changeset. The reason for the change is that we had timeouts in the transactions because the uniqueness checks for the label and description pairs took to long time. The new checks will not guarantee uniqueness, only make the duplicates very rare. Jeblad (talk) 06:21, 5 January 2013 (UTC)
Categories and new data pages
Hellow, I have two questions
Will the data pages be categorised? We all know how usefull are the categories, especially when someone wants to add new data in related articles (eg. census data that where published recently) a problem that is more obvious with the use of code instead of a title, but in 4 pages in checked there were no categories.
How does someone knows whether the page (s)he (or the bot) created doesn't already exists.
The items (the data pages) will at least not be categorized initially. There are some ideas floating around but categories as such is a concept that has some really difficult quirks if we shall do it right.
The properties can't be used as a replacement for categories, they are designed to hold values (or something similar, or even none at all) as part of the statements in items. Jeblad (talk) 20:03, 31 December 2012 (UTC)
Things put in a category is not necessarily of the same instance, even if they often are similar. For example a category for municipalities of a county are the same type of instance, that is municipalities, but things put into a category for a specific municipality are not, that is lakes, roads, cities and so forth. Some newspapers have encoded this types of differences between articles as classes and topics instead of categories, but lately it seems like they all switch to categories. Jeblad (talk) 00:37, 2 January 2013 (UTC)
Item without Finnish label, but search results shows label
Who can explain for me, why item, where is not Finnish (language) label, shows me the label in search results. E.g. Q415845 (Nasser) without Finnish label, and Q437221 without Finnish label. But when I searched something and found those two items, another item showed label (Nasser), and second didn't show label. If you don't understand what I try to explain, please tell me, and I can also take a picture. --Stryn (talk) 16:43, 4 January 2013 (UTC)
Heh, now I understand... I think. Because first one has English label and second hasn't. I wondered a long time what's wrong, and just when I sent the message above I realized. :) --Stryn (talk) 16:49, 4 January 2013 (UTC)
It would be helpful if search result were displayed differently. Detailing interwikis could be helpful. --Docu (talk) 19:55, 4 January 2013 (UTC)
Fallback languages… In some cases the very simplistic fallback language chain from the messages are used, and that will use English if no label is set in the present language. I would like a better solution, but we can't agree on whats "better" in this case. That is, its not obvious that a geographical close language is a preferred choice if that includes two countries that has been in war the last couple of hundred years. Jeblad (talk) 20:23, 4 January 2013 (UTC)
For Finnish, English as a fallback language is definitely better than Swedish or Russian - just based on the number of speakers.--Ymblanter (talk) 20:37, 4 January 2013 (UTC)
Ja, intressant, maybe would be good to add possibility to hide fallback languages in preferences, or is it possible? --Stryn (talk) 20:51, 4 January 2013 (UTC)
At least the fallbacks should be marked somehow, perhaps make them slightly grey and ghostlike. They are somehow not for real. Jeblad (talk) 07:25, 5 January 2013 (UTC)
I was just wondering if this gadget should be marked as "default" so that every user and even IPs can check whether the specific sitelink already exists. There is also a link added at Special:CreateItem to check if the sitelink is already in use. Any opinions? Otherwise I will make it available for everybody. --Bene*talk09:14, 4 January 2013 (UTC)
No. Gadgets should not be default unless there are a very clear reason why they should be marked as default. In this case there is already a special page for the same operation. I'm not sure I like adding a bunch of stuff in Special:CreateItem without fixing the overall usecase. Why would I want to check a sitelink at a page that by default does not let me set the sitelink? The whole idea seems wrong to me. Jeblad (talk) 20:44, 4 January 2013 (UTC)
Let me explain. First I don't know any Special page where you can check for a sitelink, second it would prevent lots of duplicate entries because at the moment you can only test if a sitelink is used when you have created the item yet. It was requested in a previous discussion. Do you now understand my request? --Bene*talk21:04, 4 January 2013 (UTC)
Argh. I understand... Sorry, I was a bit confused. But I think it would help the IPs or other users if there was a link next to the button "Create" so that they can directly test it. I think they would create less duplicates. --Bene*talk09:46, 5 January 2013 (UTC)
Would it be a bad idea to make it possible to directly add the link in the "create item" form. It seems to me that it would make things simpler. --Zolo
Back to my first question: Should we now enable this gadget for all users? The arguments for it are that there will be created less duplicates because you immediately see if the sitelink is already used and it is much easier to create it. --Bene*talk21:45, 5 January 2013 (UTC)
I had not realized that the link was also on the "create item form". To me it makes sense to have it by default there, but it would make even more sense if the form had also a "sitelink" field similar to "label" and "description". That done, the other "check sitelink" line of the left-hand menu would be redundant. --Zolo (talk) 09:06, 6 January 2013 (UTC)
Just a random guess, but is it possible that when you create a new item with the sitelink already in it, it doesn't check for duplicates? πr2 (t • c)14:52, 5 January 2013 (UTC)
I noticed it when I tried changing the Label to include the full enwp name. It said the sitelink is already in use and popped up the entire list. --Rsrikanth05 (talk) 17:00, 5 January 2013 (UTC)
Yes, this has links of Wikipedia, but what about Wikitionary, Wikisource and such? They would be valuable to have indexed here as well (especially Wikitionary). Ebe123 (talk) 18:26, 5 January 2013 (UTC)
I like it the coordinate prototype. Will we have the map on Wikidata ? It would be even better if the map could be zoomed automatically, depending on the number of significant digits we add to the coordinates. --Zolo (talk) 08:49, 4 January 2013 (UTC)
Islamic (example: 22 Safar 1434), Iranian (example: 13 Dey 1391) and Hebrew calendars (example: 23 Tevet 5773) do not work in the prototype.--Snaevar (talk) 00:32, 7 January 2013 (UTC)
There are lots of usefull linsk on this page. Sometimes there are items that have no links to a german article, yet they are marked als "fehlende Bezeichnung" (missing label). There are also lots of items marked as "fehlende Beschreibung" (missing description). Whenever I check one of these I found very often, there is a description in one out of twenty languages or sometimes not even in one language. Is it sensible to ad a description in every case? Or on the other hand, if both parts are absolutely necessary, why is it possible to save uncomplete edits?--Giftzwerg 88 (talk) 01:11, 7 January 2013 (UTC)
Hi folks, time for brainstorming! We have somewhat loosely said that we would like search results to be in rank order, that is usually the only order that works for search results. The thing is most ranking mechanisms use inbound links, text analysis or some popularity measure. We have none of those in items so the rank value will be more or less a single value. In addition we have a lot of similar labels and aliases, that makes the situation even worse and we gets a ton of items with nearly the same term (string value). Imagine all the places called "Berlin" when everything except the initial name is stripped off. If we want the drop down list in the search box to work properly we need some kind of ranking, but this is important also for ordinary search results. We want the important hits to show up on the first page of results.
We could perhaps reuse ranking from Wikipedia, and boost values when searching in a language that has a sitelink to a project for that language. That sort of work but it will need some back propagation of rank values from Wikipedia and to Wikidata. We can also boost items with a label or alias closer to the search string in length, that is what we did in an earlier version of the search. That doesn't work to well when the term is basically the same as in "Berlin", but we could compare with the title from the sitelink instead. We can also use some kind of hit count for the search, and we can use some kind of popularity measure.
Actually, we do inbound links, from the task forces. And things which are in the taskforces (or may be in some taskforces) usually deserve to be in the top of the search. But this only covers a small fraction of all items.--Ymblanter (talk) 11:15, 28 December 2012 (UTC)
Ranking from Wikipedia would be fine for me, unless it takes too much of resources (and consequently slows down the whole thing).--Ymblanter (talk) 11:16, 28 December 2012 (UTC)
Simple, and better than nothing. However, I am not sure that the number of Wikipedia articles is a good indicator of the importance of a topic. For instance, there is an enormous amount of articles about cities and other administrative units. It is not so much because of their importance as because it is easy to create semi-automatically - and it will be even easier with Wikidata phase 2. On the on the other hand, those bot-friednly ropics, are also those where Wikidata items are more relevant. --Zolo (talk) 09:47, 7 January 2013 (UTC)
And of course, number of items can easily be artificially heightened. I am kind of amazed with Q1859 listed in #Items by number of interwikis. Plus I susspect that when an article reach a certain number of interwikis, a self-perpetutating trend toward more translations arise.
Both of those pages have de labels. It can't add labels in other languages, because there are no interwikis for them. Ajraddatz (Talk) 20:01, 3 January 2013 (UTC)
There really should be a way to see other-language labels, descriptions, and aliases without having to switch the interface language. For instance, I understand Italian well enough that I can sometimes translate descriptions into English, but that doesn't mean I can actually understand anything else on the page once I switch languages. — Francophonie&Androphilie(Je vous invite à me parler) 15:30, 7 January 2013 (UTC)
is it possible to wiki data also can standardize data about coordinates? eg. at some articles about cities, lakes and mountains, each wiki their own coordinates and location can vary by up to ½ kilometer--Trade (talk) 08:06, 7 January 2013 (UTC)
Hopefully we can fix some of the differences, but note that some coordinates have different interpretations in different context. For example is the center of a city the towns hall, the church, the post office or some calculated mean of the area? This kind of differences are difficult to replace with a simple value. There are also differences between the datums and grid systems which further complicates this. Jeblad (talk) 08:55, 7 January 2013 (UTC)
How many Wikidata links to pages which are Lists of (marginally notable) Items/Entities?
On the various Wikipedias List pages are used to list out Items which are not sufficiently notable to each get their own page but are still worth a mention:
Lists of minor characters in works of fiction
Squad lists for sports teams
etc.
(I am not considering Disambiguation and Portal type lists here - those are lists which are made up of links to Wikipedia pages).
As these are Lists of Entities or Items I think it would make sense to have a separate Wikidata page for each item, maybe linking to the appropriate section in the List page. This way
we allow different language Wikipedias to organise their content as they wish, without imposing a single model (who is a major character in a soap opera and who gets relegated to the minor character list);
we keep Wikidata as a collection of Entities/Items which can be reused / put in a table etc.
Even if it is created items for each individual person on such lists, the entry for the overall list should still be created. Without an item for the overall list, that is the page on Wikipedia, it would be necessary to maintain the langlinks as before on those Wikipedia pages. One of the core reasons for Wikidata is to centralize langlinks. Later on (Phase III) there will be queries that can extract and create lists, and then it will be interesting to split out those minor entries so the lists can be recreated as queries. If we do that the pages in Wikipedia will have the initial textual part like now, but the table (or list) will be created from a query in Wikidata. Jeblad (talk) 09:22, 7 January 2013 (UTC)
On the Scottish island of Coll there are 2 castles - Breachacha Castle and Old Breachacha Castle. On the english Wikipedia these are described on the same page with a paragraph for each castle. On the German Wikipedia each castle has it's own page and these are linked from Q2018293 and Q3649.
At present the English Wikipedia page is linked from Q3649 only. As this page describes 2 different buildings I would like it to have links from both Wikidata pages but the software doesn't allow this. Can we change the software to allow this? Restrictions on how we use this facility should be part of the guidelines and policies rather than hard coded into the software.
Further confusion is introduced by the Portuguese wikipedia page linked from Q3649 as this page (erroneously) describes a medieval building rebuilt in the 1800's. Filceolaire (talk) 09:32, 7 January 2013 (UTC)
Hi Filceolaire, Wikidata is linking 1:1 the same subject. Wikipedia interlang linking however is wide open to interpretation and similarities. So in future Wikidata will provide the main langlinks and you can add additional langlinks in the old way. In the case you mentioned there should be three items: Breachacha Castle, Old Breachacha Castle and Breachacha House. For more conflicts like this see: Wikidata:Wiki import task force. --Kolja21 (talk) 11:15, 7 January 2013 (UTC)
I understand how the system works now. I am proposing a change to how it works for the reasons I have outlined above as I think it will be more useful than the current system. The fix you propose sort of works for 2 items and 2 languages but when we have hundreds of languages and tens of items split between multiple lists in different ways on each of those languages then I don't think this fix will work. Filceolaire (talk) 15:24, 7 January 2013 (UTC)
Actually the way you propose will work in the future, but we must still maintain the 1:1 on the same subject pages like Kolja21 outlines it for the infobox-stuff to work. Jeblad (talk) 18:40, 7 January 2013 (UTC)
Infoboxes are each about a separate item so I would have thought that a Wikipedia page which lists multiple items works better if there are multiple Wikidata pages - one for each item. The Wikidata info can then be imported as multiple infoboxes on the Wikipedia page or imported into a table on the Wikipedia page. 1:1 correspondence between Wikidata pages and Wikipedia pages works best when each Wikipedia page covers one item/entity. Anything else needs a fix of some sort and the fix I have proposed above is the best I can come up with. Filceolaire (talk) 09:55, 8 January 2013 (UTC)
I'm not too sure about commons, but you can create an item for stuff like Templates just like you do for regular articles. --Rsrikanth05 (talk) 17:45, 8 January 2013 (UTC)
How do I see all language labels?
Is there an option to see all the labels and descriptions in all languages for a page? I just noticed that the deletion page says to check these before marking a page as blank. Filceolaire (talk) 20:49, 8 January 2013 (UTC)
I think it would be interesting to know which items have the most interwiki links -- is there any way to find out? Furthermore: Is there any chance to find out the number of items for each "number-of-interwikis"? (Sorry for being ununderstandable.) Example:
Simple database query on toolserver. Runtime was about 100 second. User Make added two item numbers. I added some more, because the query contains this data, too. Merlissimo (talk) 01:12, 9 January 2013 (UTC)
When browsing Wikipedia today, I noticed one area Wikidata might be useful. On the page [1], under Births there is a list of people with each person's birth year, name, profession, and death date. I think it would be possible to have these bits of text generated from Wikidata, particularly once Wikidata is used to store information from info boxes. I imagine lists like the above would be much easier to maintain if the author could extract the data from the person's Wikidata entry, rather than manually maintaining all of that text.
Getting the same: Unexpected non-MediaWiki exception encountered, of type "Solarium_Exception" while trying translation for Hindi as well. --Rsrikanth05 (talk) 11:42, 9 January 2013 (UTC)
Nikerabbit has fixed that specific instance of the problem by increasing the timeout, root causes are still being investigated. Thanks for the report, Nemo15:00, 9 January 2013 (UTC)
Upcoming breaking change; use of unprefixed ids will be dropped
Several places, for excample in the API, it has been possible to use unprefixed ids if the prefix is given by the context. This has been in a sort of half-way deprecated state, it has been marked with warnings in the API result for some time, but will most likely be dropped in the future. Make sure your bot is updated and support this change, always use prefixed ids! The change will probably go live in short time. Jeblad (talk) 14:37, 9 January 2013 (UTC)
Hi guys, I have just written a new tool for Wikidata. Don't treat me if it still is quite buggy. You can enter a category of a specific language and the tool will give you all existing items (max 1000) which have a page in this category. Don't worry if it takes some time for big categories. Hope you'll like it and please report bugs to me. --Bene*talk16:26, 5 January 2013 (UTC)
Fantastical! Finally, it's not necessary anymore to use the wiki search for every single item. Thank you for your work! Regards --Iste (D)17:20, 5 January 2013 (UTC)
Very nice, would it be possible to add the label in addition to (or even instead of) the item number ? --~~unsigned comment by Zolo
Nice tool, thank you for your work. Could you please add a option to show only pages that have no wikidata item in this category? Regards, IW20:20, 5 January 2013 (UTC)
I do not know how everything works here yet, but I have looked at some items here: Q501545 (Falu municipality) had "Hillersboda" as a Swedish alias, and Q514815 (Kramfors municipality) had "Bålsjö" as a Swedish alias. This has been made by a bot, and it looks very strange to me. It looks like these aliases has been taken from the redirects on svwiki. These redirects has been made, not becase these names are alternative names for these municipalities, but because these articles about small villages has been regarded as lacking notability. They have been redirected to another article, instead of being deleted. This (bad) habit of redirecting instead of deleting articles is a common habit on svwiki, and I do not think I can change it.
We should stop having bots adding aliases from redirects, and we should start having bots remove all those that they have already added, in my opinion. --Yair rand (talk) 20:40, 8 January 2013 (UTC)
My bot and I think also Merlbot are currently adding redirects as aliases from every language excluding: "hu", "simple", "mk", "en". I will add sv wiki to this list. --Sk!d (talk) 21:00, 8 January 2013 (UTC)
It is not possible for me to tell if a Alias is wrong. I also dont know if the sv community wants this. --Sk!d (talk) 01:12, 10 January 2013 (UTC)
It doesn't need to remove all wrong aliases, it just needs to remove all aliases that it added. Re your second point: You don't know if the sv community wants to manually deal with hundreds of thousands of your bot's mistakes added across Wikidata, and your bot was never even approved for the task of adding them in the first place, so I think it's clear what the appropriate course of action is at this point. --Yair rand (talk) 04:19, 10 January 2013 (UTC)
Project names
Currently Wikipedia is referred as wiki on item and special pages. However, when items will be able to store other project links, it may lead to confusion, since other projects are also wikis. I think will be good idea to refer to Wikipedia with full name.
Other question how links table are envisioned when other projects will be supported? One table for all links will be hard to handle for items with many links? Will links be divided by project?
I believe they are using the database names, so they would most likely be like enwiktionary etc. The Wikipedia database names are xxwiki (due to historical reasons). Hazard-SJ ✈ 02:07, 11 January 2013 (UTC)
New template
After Yair rand (talk • contribs • logs) pointed out that the now-functioning {{Top icon}} was causing problems in right-to-left languages, I wrote something to detect if users are viewing a page in a right-to-left language, and adjust things accordingly. Bene* (talk • contribs • logs) turned this into its own template, {{LangDirSwitch}}. The main problem, though, is that I couldn't find any authoritative list of RTL languages to which users can set their preferences. So if anyone knows of any I've missed, it would be great if they could add them, but also, I'm curious as to whether anyone on the developer side might be able to find a complete list, like by checking to see which languages include a .sitedir-rtl or something like that. — Francophonie&Androphilie(Je vous invite à me parler) 16:53, 10 January 2013 (UTC)
The simplest is to define two styles with absolute positioning and use the body class to adjust the position. You simply flips the left-to-right and right-to-left calculations depending on the defined body class. To make this work you must set up a selector chain either in Mediawiki:Common.css or in each of the skins. If you use Javascript you can also peek into the class definition and act accordingly. Not sure if we have a parser function for this, but it should be fairly simple to implement. Downside is that it would only work for non-cached pages, which we should not depend upon. Jeblad (talk) 17:58, 10 January 2013 (UTC)
grep -l "\$rtl\s*=\s*true" Messages*.php |grep -oP "(?<=Messages).*(?=\.php)"
Arc
Ar
Ckb
Dv
En_rtl
Fa
He
Khw
Kk_arab
Kk_cn
Ks_arab
Ku_arab
Mzn
Pnb
Ps
Sd
Ug_arab
Ur
Yi
These are the languages which are rtl lanugages. There are also variants and fallbacks which must be added to have a complete list. e.g. ks ist not a defined languages. It falls back to ks-arab. I created messages in languages listed above, so that {{int:rtl}} is 1 for rtl languages. Merlissimo (talk) 02:01, 11 January 2013 (UTC)
completely reworked and simplified inclusion syntax draft
Hey :)
The Wikipedias will need a way to access data from Wikidata in their articles. We had previously published drafts of our plans how the syntax for this should work. Denny has now reworked this completely and we'd love your feedback. Please have a look at this and this email for details. --Lydia Pintscher (WMDE) (talk) 21:20, 10 January 2013 (UTC)
Let's improve the search field
Current state of the entity selector
We've been thinking about how to best improve the search field here. And what we came up with is to use the entity selector that is being worked on for statements. This would mean that the search field will be replaced by a new one that gives items as results as you can see in the image. This includes the label as well as aliases and descriptions if they are available. In addition it'd have a link "more search results" at the bottom that gets you to the usual search page. What do you think about that? (Improvement of the search result page are a topic for a later discussion.) --Lydia Pintscher (WMDE) (talk) 14:26, 9 January 2013 (UTC)
contents of the search index: fields used, multi-language aspects
Looks nice! To be sure I understand correctly: Label, aliases and description should be included not only in the returned list but also be applied for the search pattern (I'm not sure if this should be done directly in the search box or later when chosing "more search results". In addition I request in "more search results" to be able to seach not only my own, selected language but in all languages. This is important since the completeness and correctness of labels, descriptions and aliases is very variable and the search could be required to find(!) an item in order to overcome the deficits in the current language. This should not be a deadlock. --Spischot (talk) 18:19, 9 January 2013 (UTC)
Label and aliases are applied to the search (not the description though). For now we plan only to use the user's language. We have to figure out how language fallback could make sense. --Denny Vrandečić (WMDE) (talk) 10:23, 10 January 2013 (UTC)
Will the search results work for aliases? If a user starts typing out an alternative name for an entity, will the suggestions box show it? If so, in these cases it might make sense to either display the alias as though it were the label, or to bold the alias instead of the label. --Yair rand (talk) 18:24, 9 January 2013 (UTC)
Aliases are used for the search, but they are only displayed if they are actually hit. It is not the case that all aliases are displayed always, but only if the search actually hits on a given alias, that alias will be displayed. --Denny Vrandečić (WMDE) (talk) 10:23, 10 January 2013 (UTC)
what about fallbacks and variants? For example: A user has interface language "en-gb". Are labels with language "en" consideredwhen a search is performed? And vice versa: interface language is set to "de" Does search consider labels with language "de-ch"? -- Make (talk) 08:14, 11 January 2013 (UTC)
stupid me. has already been adressed above: For now we plan only to use the user's language. We have to figure out how language fallback could make sense. -- Make (talk) 08:17, 11 January 2013 (UTC)
This aspect of the search algorithm has consequences for aliases. For example: It is not uncommon to search for films with the original title as search term. A user with interface language "de" looking for Q181795 types "empire strikes back" although the German release had the subtitle "Das Imperium schlägt zurück" If the English label would be visible there would be no need to add the original English title as an alias for all other languages? -- Make (talk) 08:14, 11 January 2013 (UTC)
Yes, this is correct. Eventually we would improve that by marking specific properties as also being used for search (e.g. the latin name of a species, the title of a book in the original publication language, the name of a city in its native language, etc.) but for now we would rely on Aliases for that. --Denny (talk) 10:41, 11 January 2013 (UTC)
user interface / efficient use of screen real estate
Descriptions can also occasionally be longer than the space that is shown in the search box. How will those be handled? Maybe by cutting it off with a "..."?
Many items have quite a lot of aliases. I'm not sure it would be helpful to list all of them in the suggestions box. Additionally, the text "Also known as:" takes up quite a bit of space. Perhaps that could be shortened, if it is kept. Or maybe just shrunk, actually. --Yair rand (talk) 18:24, 9 January 2013 (UTC)
I second the idea by Yair rand to cut-off long aliases with '...' and would add that indenting them perhaps two spaces would help to differentiate them. CWDillon (talk) 01:31, 10 January 2013 (UTC)
I think this would be good. But one question: if I hit enter, what is going to happen? I would prefer to show the normal search-result-page and if I use the up/down arrows to mark an item or click on a result in the new search bar I should get directly to the item. --Sk!d (talk) 01:16, 10 January 2013 (UTC)
You would go to the selected item. But there will be an extra field that will let you go to the current normal search-result-page (this is not implemented yet). --Denny Vrandečić (WMDE) (talk) 10:23, 10 January 2013 (UTC)
We need to warn users who are not logged in that their IP will be stored in the edit history. This can't be done the same way it is done for article edits (ie at the bottom of the edit window). What we've implemented now is a bubble that pops up when you click edit on an item. You can try it on this page. What do you think about it? --Lydia Pintscher (WMDE) (talk) 13:57, 10 January 2013 (UTC)
Note that you must not be logged in on the page to see the bubble informing you that you're IP will be saved in the history of the page. The bubble will only appear if you do not see your user name in the upper right corner. It can also be necessary to reload the browser cache to get the relevant Javascript changes.Jeblad (talk) 15:38, 10 January 2013 (UTC)
It works fine for me, but I had to purge my cache. However, I think the buuble should be next to the edit button and not in the top right corner so that the user can also see it when he has scrolled down the page. --Bene*talk16:11, 10 January 2013 (UTC)
The bubble is a standard notification mechanism in Mediawiki. If you scroll down on the page the bubble will pop up relative to the edges of the viewport. Jeblad (talk) 17:45, 10 January 2013 (UTC)
Thanks for that pointer, Jasper. I think this is a related but independent issue, that we should also prioritize soon. In theory, if you are blocked away from editing, the edit buttons shouldn't even be active. I am aware that this does not work yet as it should, but it's on our list. At the same time, the messages you mention should be displayed. I will try to keep it in mind, feel free to ping us about it. --Denny (talk) 10:33, 11 January 2013 (UTC)
Sorry...
I did something that I am not sure if I should. I set pt-br version of "Wikidata:Translation administrators" to "progress". I was trying to translate it using translation extension, but something is not working because I can't save what was translated. Sorry if I did something wrong and, if somebody can tell me, please, where I can add pt-br version of the text, it is already done. Thanks.—Teles «Talk to me˱M@CS˲» 08:51, 11 January 2013 (UTC)
Don't worry about the states - in progress, need proofreading, etc - those are just there to tell other translators what stage the translation is at, and has no technical function. Ajraddatz (Talk) 11:52, 11 January 2013 (UTC)
Should the namespace be translated too when localizing project pages? Or should it still say "Wikidata:" or "Help:"? -happy521421:45, 11 January 2013 (UTC)
The current advice in Help:Label is to include the namespace in the Label as it appears in that language wikipedia so the Wikidata page linking to Portal:History in en:WP has the label Portal:History. Labels in other languages will have the namespace name in their language. Filceolaire (talk) 15:00, 12 January 2013 (UTC)
I think that Happy5214 meant project pages which are translatable to other languages, like Help:Aliases. I think we shouldn't change the namespaces, and at least there is then following message (in translation tool): "Namespace changed from the definition". --Stryn (talk) 15:25, 12 January 2013 (UTC)
I have no idea. That is why I started this conversation..... Can anyone who knows about it reply to this conversation.. ?????? —The preceding unsigned comment was added by117.193.127.201 (talk • contribs) .
Is there a reason why this couldn't be added? In the list of interwikis? Usually to each Wikipedia article, there should be a matching category at Commons.
Yes, there are items for categories with sitelinks to the same category in different language. But the proposal was about a "match" between an article and a commons category and to handle this just as common was another language. --Spischot (talk) 07:57, 6 January 2013 (UTC)
Comment. It would be useful, but apparently it is not as technically straightforward as it may seem. Inclusions of sitelinks for other things than Wikipedia articles (Commons, Wikisource, Wikipedia categories, external websites) has been discussed in various places (for instance Wikidata:Requests for comment/Inclusion of non-article pages), but we still need to implement a solution. --Zolo (talk) 08:39, 4 January 2013 (UTC)
Neutral It'd be useful, but as Spischot stated, a cat isn't a page. However, we do need to include the Commons somewhere. --Rsrikanth05 (talk) 10:54, 4 January 2013 (UTC)
A category description page is a page and many Wikipedia articles have a matching category at Commons. --Docu (talk) 19:52, 4 January 2013 (UTC)
I think a separate section is needed for links to galleries and categories on Commons, as well as pages in Wikispecies. Those aren't (inter)language-links, but interproject-links, so it would not fit in the list of languages. Also Wikisource, Wiktionary, Wikiquote and Wikivoyage have interprojectlinks to Wikipedia pages. Also VIAF, IMDb and other databases and websites should be connected to articles. Tomake all these links possible is depending on the developers, we are enthousiastic and want it, but the developers need time for that to make it possible. Romaine (talk) 22:14, 4 January 2013 (UTC)
I am not sure that you will stay in a 1:1 relation between the iw-links if you include the categories from Commons. The same problem exists on Wikisource. (s:sv:Vårt land has four iterwikis to s:fi:.) The Author-ns in Wikisource should have a 1:1-relation, but the namespace is not installed in some subprojects. -- Lavallen (talk) 16:52, 5 January 2013 (UTC)
Support Wikidata was never meant to be limited to just the interwiki links. The ambition is that it provide a repository of data that can be used in various ways. Links to galleries of pictures associated with an item would certainly fit that model. Let's not close off possibilities unneccessarily. Filceolaire (talk) 09:50, 7 January 2013 (UTC)
Support I would like to see a thin grey line after all of the Wikipedia interwiki links, and then have all of the inter-WMF-projects links. I see a value in linking the Wikivoyage, Commons, Wikispecies, Wiktionary, and Wikisource pages in with articles, where appropriate. Sven ManguardWha?17:22, 13 January 2013 (UTC)
Support Large fraction of categories on commons carry interwiki links to wikipedia articles. Most articles on most wikipedias have or should have some sort "Commons Category" templates pointing to a category with graphical resources related to article topic. We have bots similar to interwiki bots updating "Commons Category" links. The whole proces would be much simpler if all wikipedia interwiki links were handled by Wikidata. --Jarekt (talk) 13:04, 4 February 2013 (UTC)
Non-content pages
A look at WD:Statistics reveals that there are 2.8 million pages, 2.4 million of them content pages. That means that there are 400,000 non-content pages. I'm just curious, what are they? There aren't nearly that many project or user pages. -- Ypnypn (talk) 05:06, 13 January 2013 (UTC)
Non-content pages include disambiguation and category pages and there are lots of them. Project pages are few in comparison. User pages are not included until now.--Giftzwerg 88 (talk) 11:39, 13 January 2013 (UTC)
I doubt the statistic knows the difference between articles with one subject and multiple subjects (disambiguation). And yes there are user pages in Wikidata, for example Q640 and Q1170. --Kolja21 (talk) 12:05, 13 January 2013 (UTC)
I didn´t know that. These userpages are not just for testing? At least the category pages are distinguishable for the software as non-content pages, and there are millions of category pages and many of them have langlinks. It is my wish to overcome the categories in its existing form by wikidata someday. --Giftzwerg 88 (talk) 12:23, 13 January 2013 (UTC)
The date for deployment on the Hungarian Wikipedia is getting closer (14th of January if there are no issues) and since Friday the code that will be deployed is running on test2.wikipedia.org. If you have not done so already it'd be lovely if you could give it some testing there and report bugs if you find any problems.
Reminder: What's there so far is:
use of language links from wikidata.org and link in the sidebar of articles to change them
relevant changes show up in recent changes
option in recent changes to toggel showing of wikidata.org edits or not (plus an option in your preferences to change the default)
In general: Are we prepared for hungarian Wikipedians clicking edit button for interwiki and arriveing in Wikidata in look of speakers and people who can gives advices for editing Wikidata? Greetings, Conny (talk) 15:21, 7 January 2013 (UTC).
Seems to work good but it is not self explanatory since Wikidata and lang-links hidden in the source text are mixed. Cinnamomum verum contain both types. If an author clicks on "Edit links" he will come to Wikidata and be lost.
Why are there two Wikis?
Why Wiki-2 is not showing all links?
Why Wiki-2 is showing a different "fr" link than Wiki-1?
All this needs to be explained. To every author, again and again. A better way would be to make clear that we have two types of links:
general lang-links (provided by Wikidata) and
additional lang-links (hidden in the source text).
Ideally the ones in the wiki text will vanish sooner than later in most articles and then the confusion isn't there anymore. The interface will also improve. This is however what we have for the first deployment. It's not perfect yet but we have to start to get it out there. It'd be great if the necessary help pages could be created in Hungarian of course in case they don't exist yet. --Lydia Pintscher (WMDE) (talk) 10:54, 8 January 2013 (UTC)
Perhaps a "help" button could be added near the new edit links tab, to explain the interwiki side of Wikidata to the uninitiated? —WFC— 19:38, 7 January 2013 (UTC)
Good idea. It would also be great to have a link back to the site you were at on Wikidata. I know on Wikia, similar modules to Q&A sites had lots of resistance because people didn't know how to press the back button on their browser - the links only went one way. I expect similar resistance here, but this could be fixed (possibly). Ajraddatz (Talk) 00:49, 8 January 2013 (UTC)
Its not added in the sidebar because there are no matching item. In those cases the link (Special:ItemByTitle) to a previously resolved item (that is one with a sitelink to the Wikipedia article) should be replaced with a link to search (Special:Search) or to item disambiguation (Special:ItemDisambiguation). There are some plans to replace the direct link with a gadget of some kind. There are several storyboards in Commons:Category:Wikidata storyboards - Linking Wikipedia articles v0.3. Jeblad (talk) 09:24, 8 January 2013 (UTC)
Maybe it is said allready, but it would be nice to add a link, when there are no Interwikilinks to understand what happend. Conny (talk) 09:50, 8 January 2013 (UTC).
I think it's reasonable to have add link for pages without interwikis. When dialog box for this purpose will be available, it should provide existing items look-op (when specifying language, project and name to search for). If item will be found found, link should be added to it, and in case of duplicate items, nomination for deletion should be added quietly. --EugeneZelenko (talk) 15:24, 9 January 2013 (UTC)
Why do links in wiki text "overpower" WikiData-Links, wouldn't it make more sense if it were the other way round, since WikiData is the should-be-used-system? --Sixsi6ma (talk) 13:35, 10 January 2013 (UTC)
I wonder. How does it work. Should the Q-number be entered in the specific wikipage (eg. Budapest Q1781) or does it all goes automatic?--Wester (talk) 15:33, 13 January 2013 (UTC)
For my bot i still don't know how it can work on huwiki after wikibase client is enabled. Main blocker for my bot is bugzilla:41345. If there are local and wikidata langlinks to one wiki the local one must be removed. But how should a bot know about this using api? I'll deactivate my bot on huwiki if there is no solution until first client release. Merlissimo (talk) 21:58, 8 January 2013 (UTC)
Other Bot frameworks
Is there any solution implemented that will prevent bots using pwb or awb framework adding langlink to articles having langlink from wikidata? Merlissimo (talk) 21:58, 8 January 2013 (UTC)
There are many cases where one wikipedia divides a subject into multiple pages while another covers all of that subject on one page. see for example Assassination, Murder, Manslaughter and Homicide. This can mean a link ends up on the wrong page because I didn't know the other page existed.
I have been told that eventually we will have the ability for a WD page to link to more than one page in a WP and for more than one WD page to link to the same page in a WP (where the WP page deals with multiple entities). In the meantime could we add a see also field to the Wikidata page. This would be a field where links to multiple other WD pages could be put.
Use cases:
Where there is a WD page for a taxonomic Genus which lists all of the plants/animal species in that genus and there is another WD page which links to WP pages which deal with one of the species in that genus, especially where the name for the species and the genus are very similar.
Where there is a WD page with links to WP pages which deal with a local government area including a town in that area and there is another WD page which links to WP pages which only deal with the town, especially where the town and the local government area have the same name.
Where there are 2 WD pages which deal with the same topic because there is one language WP which has two pages under different names with the same topic and they haven't been merged yet
Wherever one WP has a number of pages with very similar topics and other WPs combine these topics in one page.
Where two WD pages could easily be confused such as Q752211 and Q351015 - two different Russian opera-ballets with the same name and the same lyrics and both with music by Rimsky-Korsakov.
Where the difference between WP pages is due to the language such as the various disambiguation pages for different words all of which mean Star.
If I understood you right it would be an opposite of the aliases. So the see also fields would say: This sounds equal but it isn't the thing you're looking for. Sounds good. --Bene*talk16:22, 13 January 2013 (UTC)
Looks like we have a rough consensus in favour of this. Is there a wish-list of agreed changes somewhere that this should be added to? Filceolaire (talk) 08:54, 15 January 2013 (UTC)
First steps of Wikidata in the Hungarian Wikipedia
Heya folks :)
Today is the day. We've deployed Wikidata on the Hungarian Wikipedia \o/ I wrote a blog post with all the details here.
Thank you to everyone who has helped make this happen and especially the Hungarian Wikipedia community for agreeing to be the first. --Lydia Pintscher (WMDE) (talk) 20:35, 14 January 2013 (UTC)
The Swedish article about Wikidata was moved from ns-0 since the website couldn't prove notability, and the article was considered Conflict of interest. :) -- Lavallen (talk) 21:35, 14 January 2013 (UTC)
It was discovered that the interwiki bots would be restoring the links anyway, so a decision was made to rollback all the link removals. It seems that the bot community on every Wikipedia needs to be made aware of the changes so that we don't have this problem again... --Rschen775421:40, 14 January 2013 (UTC)
I was reminding two month ago and last week again that pywikipedia interwiki bots might be prepared for this step, but unfortunatelly they are not yet. JAn Dudík (talk) 11:35, 15 January 2013 (UTC)
I've been involved in a couple of similar "edit wars" with stubborn editors that simply will not accept that the world moves forward and Wikipedia with it. Some of them will not even have recognized on-going discussions and consensus building on a topic, even for a case like this. Take the discussions to the appropriate project-specific community discussion pages and build consensus for each necessary guideline and policy, and make sure that everyone are informed and heard. If necessary use the site messages to inform everyone. Jeblad (talk) 03:42, 15 January 2013 (UTC)
Well in this case these are bots who cannot discuss I do think that we need to have a discussion with Hebrew and Italian Wikipedia about the interwiki bots issue; I've started one on the English Wikipedia, but that's step 3. --Rschen775403:50, 15 January 2013 (UTC)
May be a good thing to note is that the Hyngarian Wikipedia uses flagged revisions, and therefore pages edited by users without local flags are marked as not patrolled. So whereas it is great fun to remove interwiki links (I have just done it in three articles), it creates unnecessary burden for local patrollers and is best left to bots.--Ymblanter (talk) 22:33, 14 January 2013 (UTC)
Congratulations to the developers, Wikimedia Deutschland and everyone else who worked to bring this great idea online - Badseed (talk) 01:11, 15 January 2013 (UTC)
The English versions of Help:Label, Help:Description and Help:Aliases are currently only proposed guidelines. I suggest that they be promoted to full guidelines now. They've been around for over a month now and I'd like to see if it's time to take them to the next step. This, of course, would not mean that the guidelines are in their final perfect state. The guidelines can still be discussed and altered when consensus is demonstrated. What does the Wikidata community think? We could even promote 1 or 2 and work on the other/s.
Sounds really strange, it is like saying: do whatever you think you can do in other languages, but in the English labels we should use this. Sorry, but I don't think that is right. Romaine (talk) 19:13, 15 January 2013 (UTC)
comment Not sure if I like the pages to be frozen now. I would like these pages to be project wide, translatable to each language, with one or more general section(s) and additional section(s) for ow they apply to each language. Jeblad (talk)
Oppose too early. There should be at least one or two months of testing in real use in en:wiki. The users might need much more help than we can expect now, it is also necessary to communicate it to a broader audience. Only in real use all the issues will show up. --Giftzwerg 88 (talk) 15:57, 13 January 2013 (UTC)
I don't think the pages should be frozen or uneditable, but they do reflect the current consensus, so I think the pages should give some indication of that. --Yair rand (talk) 04:35, 14 January 2013 (UTC)
Oppose - as I understand there is a guideline for English labels only...? Really sounds very strange to me. Of course there can be little differences between languages, but I think we should (like Commons) use for all parts of the project the same guidelines, and not cut the project in pieces. Romaine (talk) 19:13, 15 January 2013 (UTC)
Comment. I supported thinking it was for all languages and I think the current English guidelines shoul apply to all langauges. So it may rather be a 3-choice question pro-all languages; pro-English; pro-nothing. --Zolo (talk) 19:21, 15 January 2013 (UTC)
Question
Are we going to have a default version for languages which don't already have a label/description/alias policy? The alias policy is pretty adaptable to many languages, but I'm not sure about the description one. Should the description be how it appears in a sentence like "Did you mean the __(description)__ or are you looking for the __(description)__"? In some languages, it matters whether it's in the nominative [for subjects] or the accusative [like for objects]. πr2 (t • c)20:08, 13 January 2013 (UTC)
Extra feature for Slurpinterwiki
When you try to use import interwiki it will stall if there are any items with problems. This is a useful feature and helps identify problems but sometimes the problems are as sorted as they are going to be and I just want Slurpinterwiki to ignore the items with problems and import the rest. Could we get this added as an option? Filceolaire (talk) 23:51, 12 January 2013 (UTC)
I think this would be a dangerous feature because it can mislead people to do fast mass importing with ignoring conflicts. But we do not want imports to be done as fast as possible with creating duplicates, hard solvable problems and so on. We need items that are created correctly and completly as possible. Merlissimo (talk) 01:20, 13 January 2013 (UTC)
So what is the best way to go when some of the links in the WP page point to the wrong pages on other WPs? Do we have to fix the WP page before we can use slurpwiki? I just got warned off es:WP for deleting links and they were probably right - es:WP won't be using Wikidata for interlinks anytime soon and in the meantime we shouldn't be messing with their encyclopedia. Filceolaire (talk) 17:21, 13 January 2013 (UTC)
If the link is not allready on wikidata and there are no interwiki-conflicts, then I click on the "create a new item" link.
Fill in the label and description
Run slurpInterwiki.
This workflow has worked for me.
You can either fix the links on WP before you use slurpInterwiki or skip importing the links for that WP page altogether. I prefer the latter option.--Snaevar (talk) 02:27, 16 January 2013 (UTC)
Move items between pages
In checking the import blocking problems on the Import task force I often find I need to move a link between pages. To do this I delete from one page, memorising the link name, then add to the other page. Could we simplify this by adding a move option to the save/remove/cancel options in the link edit menu. Select move and it would ask for the ref of the destination page. Filceolaire (talk) 23:59, 12 January 2013 (UTC)
+1. The move button could be context sensitive to move either the label, description, aliasses or all three together. It is also a problem to save changes as long as the source item is not altered and saved. Cream of the top will be optionaly a window poping up and asking to mark (by using the move option) an emptied Item for deletion, also giving the explanation: "merged by move option with Q####."--Giftzwerg 88 (talk) 12:36, 13 January 2013 (UTC)
This feature should only be implemented as an additional tool not as a default option. This might get used for controversial edits by new users. --Sk!d (talk) 12:59, 13 January 2013 (UTC)
Linking to Wikidata userpage from Wikipedia userpage
On my Dutch Wikipedia userpage I want to create an 'interwiki' to my userpage on Wikidata userpage so I can quickly jump to this project. If I type in "wikidata:" on the searchbox of the Dutch Wikipedia I end up at the home page of Wikidata. This attempt to link to my userpage on Wikidata failed. Can it be done and if so, how can I do that? - Robotje (talk) 06:43, 15 January 2013 (UTC)
I'm afraid Stryn is right, so for now I added the links in the main panel. Both Jasper Deng and Stryn, thanks for your help. - Robotje (talk) 08:34, 15 January 2013 (UTC)
There is a trick: if you write [[en:d:user:Robotje]], it will appear as English interwiki and will work. Since recently a new "feature" was added to MediaWiki that only one iw per language code appears :-( and you have English interwiki there, you might try another language code. Bináris (talk) 20:36, 15 January 2013 (UTC)
I can not translate the page "Wikidata:Introduction"
Hello! I am newbie here in Wikidata translations, but often do translations on Wikimedia Commons and the Portuguese Wikipedia. I'm willing to do translations into Portuguese of Wikidata pages, but there is a minor inconvenience. Within this page, clicking one of the links to translation, the following message appears: "You do not have permission to create pages, for the following reason: This namespace is reserved for content page translations. The page you are trying to edit does not seem to correspond any page marked for translation.". This message is displayed by an error in Wikidata or because my account is not authorized to do translations? Since now, thank the answer. Sincerely, Fúlvio (talk) 13:27, 15 January 2013 (UTC)
Hmmm... I don't know is this related to your problem, but currently I can't translate pages. I get following error message: "Unknown error: "tpt-unknown-page" (unknownerror)". --Stryn (talk) 18:25, 15 January 2013 (UTC)
This is very strange... After reporting the error here, I managed to save some translations, but since yesterday, while trying to save more translations, appears the following: "Saving failed. Please report this error." I also tried to translate as an anonymous user, but also appeared this same mistake. Is this a bug? Already, thank possible answers. Fúlvio (talk) 18:12, 16 January 2013 (UTC)
Two items for the same entity
I noticed that Q165357 and Q1035416 both refer to Herbert Lom, with the latter referring to the huwp article while the latter refers to all but the huwp article. What should be done? Note: This is not related to the previous problem I reported about duplicate items. --Rsrikanth05 (talk) 13:15, 16 January 2013 (UTC)
Just remove huwp link and add it to the another item. Then mark page where huwp link was, for deletion. I already did it. --Stryn (talk) 13:18, 16 January 2013 (UTC)
Could current code of interwiki bot detect that Wikidata client is installed on particular project? In this case it could ignore any operation or just remove interwikis. Otherwise interwikis could stay for too long time. Of course this will not solve problem of old code. But at least bot owners could be advised or required to switch to new code. --EugeneZelenko (talk) 15:52, 15 January 2013 (UTC)
This is the sitematrix-stuff merlissimo has been urging us to do, and we didn't do because it wasn't important enough… Jeblad (talk) 17:15, 15 January 2013 (UTC)
Theoretically, yes. I am not an expert of interwikibot, but I trust xqt. :-) I think we should wait one or two days to allow bot owners update their code. Bináris (talk) 23:05, 15 January 2013 (UTC)
pywikibot has a property site method: site.has_transcluded_data to check whether the bot may edit interwiki links on a site ot not. @xqt07:51, 17 January 2013 (UTC)
new code deployed
Heya :)
We just updated the software here on wikidata.org. It's mostly bugfixes. The things you probably care most about are:
a warning for non-logged in users that their IP will be logged
a lot of localization updates from translatewiki.net
Can I see history of changes in Wikidata in history on huwiki page? How wikipedia's users can watch for changes in interwiki list to prevent vandalism. ShinePhantom (talk) 09:31, 17 January 2013 (UTC)
See w:en:Wikipedia:Wikidata interwiki RFC, a discussion regarding the implementation of the interwiki links on the English Wikipedia. I also suggest that those on the Hebrew / Italian Wikipedias have discussions about stopping the bots and/or implementation as they're coming first... --Rschen775409:35, 17 January 2013 (UTC)
Proposed New features
In the various items on this page above I have proposed a number of changes to Wikidata:
Many-to-many links instead of 1-to-1 links only. Response :This will be added at a later date.
Option to tell Slurpinterwiki to ignore problem items and import the other items. Response: Could be abused. Best not do it.
Add Move option to the link edit menu. Response: Good idea. Might be best to limit it to confirmed users if this is possible.
Add See also field where we can list other Wikidata pages which might be more appropriate for your link. Response: Good idea, especially while we are limited to 1-to-1 links.
What happens now? Is there a wishlist of desired features somewhere I should add 1, 3 and 4 to? Do I need to create a Bugzilla account and add these there? Filceolaire (talk) 00:58, 16 January 2013 (UTC)
I would like to add couple of suggestions:
Process of adding interwikis to pages without item on Wikidata is not evident. There is no link to Wikidata as of now. Such link should lead to page which will allow to search for existing item or to create new if needed.
When links to projects other then Wikipedia will be supported? What interfaces will look like? Will be links tables split by project?
Eugene: I think you need to create two new discussion topics on this page - one for each of these - so we can discuss the alternatives for these issues. When we have an agreed proposal then we can think about what to do with it. Filceolaire (talk) 08:43, 16 January 2013 (UTC)
@Filceolaire: Not sure about your point no 1, but it seems like you have misunderstood my reply. It will be possible to do queries in the future so several items can be collected into a single thingy for inclusion into a page. This (m:Wikidata/Queries) is part of Phase III (m:Wikidata/Technical proposal#Phase 3: Lists). It will also be possible to address more items and other items than the one included by default into a page. This is part of Phase II. That does not mean it will be implemented some kind of many-to-many links. You point no 2 may be directed to the community as the script is a gadget, its not part of the dev project. Point no 3 can be implemented as a gadget by using session storage in the browser. I don't think the dev team will put an effort into this, but it can be something a volunteer might do. Your point no 4 imply changes to the data store. Such a change must go into Bugzilla as an ordinary feature request. Jeblad (talk) 05:03, 16 January 2013 (UTC)
Jedblad:
1. The functionality described for phase III, to create lists and tables, will depend on Wikidata having a separate page for each item in that list or table. For those Wikipedias where these items only appear in a list (or table) you will have many WikiData items all trying to link to the same Wikipedia list. This means Phase III will need many-to-many linking. Do I need to suggest this on Bugzilla?
2. What is the best place to address something to "The community" for a change to an existing gadget?
3. What is the best place to address something to "The community" for a new gadget?
1. I think see how 1-to-1 links will work for highly structured lists. I think there will be problems with lists where each item has more descriptive text but I guess that is why we can add links by hand.
Building on the previous discussion at #Non-content pages, it appears that the article-count method for this wiki is the default "link" method (see "wgArticleCountMethod" in InitialiseSettings.php). Is it the intention that all legitimate pages in the main namespace will contain at least one link? I know that for some time as the wiki was being set up, none of the "Q" pages were being counted as content pages (at least as late as 12 November 2012). Now (as of the time I'm posting this) Special:Statistics is showing 2,621,295 content pages and 3,030,183 total pages, and the highest "Q" page appears to be number 3,196,586. Can the "content page" count at Special:Statistics be trusted as the "real" content-page count of this wiki? - dcljr (talk) 01:25, 17 January 2013 (UTC)
Yes, we have a notability guideline that suggests that all items must have at least one link. Also, I wish to trust that the number of articles, as displayed, is correct. I already reported an issue with it, so hopefully it is accurate now. Hazard-SJ ✈ 02:23, 17 January 2013 (UTC)
Wait a minute... the "link" method only counts links to pages on the same wiki. How can it count pages that only link to other wikis? - dcljr (talk) 21:06, 17 January 2013 (UTC)
It may be that Wikibase modifies the default method MediaWiki uses. I might also think that normal interwiki links may be counted.--Jasper Deng (talk) 05:18, 18 January 2013 (UTC)
This has been since reverted due to issues with bits.wikimedia (as I understand it). There may be residual caching errors with pages getting redirected to enwp. Legoktm (talk) 01:16, 18 January 2013 (UTC)
Seems like there are some caching issues. I get English Wikipedia more or less at random. It could take a day or two before dns servers gives stable replies again. 77.106.133.51
Does anyone else think that this should be added? Some users might want to read the message in a different language. See, for example, the top of m:Template:Welcome. πr2 (t • c)23:11, 18 January 2013 (UTC)
Who knows how to correct link on Wikidata:Contact the development team page, where is text "The current archive is located at January? January link should go to this page. And there if i put my mouse to over "january" text there I can see text "(Seite nicht vorhanden)" when it should be "(page does not exist)" or depending which language is in use. Also this page (project chat) has wrong link on January. --Stryn (talk) 12:36, 18 January 2013 (UTC)
Looks like that parameter doesn't work properly. It's not transported down to the subtemplate who uses it? I have made a walkaround with a special solution for RfD instead. -- Lavallen (block) 19:07, 20 January 2013 (UTC)
january 20
No big deal: It works properly when translating january to other languages, but is it really correct to write "month day" in any other language than en-us? -- Lavallen (block) 19:12, 20 January 2013 (UTC)
data center move and next deployment
Just a quick heads-up in case you have missed it so far: There will be a data center move that affects all Wikimedia wikis including this one. There will be outages. It's planned for tomorrow and the two days after that. More details in this blog post. Additionally we've planned to add the Hebrew and Italian Wikipedias as Wikidata clients on 30th of this month. I expect this to happen in the late evening UTC. As always: Things might go wrong making us move this date but this is what we're planning. --Lydia Pintscher (WMDE) (talk) 11:33, 21 January 2013 (UTC)
Language links at date
Is it possible to use the API to find what language links a page had at a certain date? I'm guessing, because I can't find a revids parameter documented anywhere, but I thought someone more familiar with Wikidata might know for sure (example query showing current links). Thanks, Jarry1250 (talk) 14:44, 21 January 2013 (UTC)
Oh yes, I suppose that would work. I'd just have to run two queries instead of one (assuming I don't know the Q number). Thanks! 163.1.163.25317:08, 21 January 2013 (UTC)
I was thinking that if we had a way of using other items as properties (as if each item were a category of its own), then there wouldn't be necessary to use categories at all. Let's take the example of France: it would connect with the items "Country", "French language", "Europe", "NATO", etc. Then we could produce the searches "francophone countries of europe", or "NATO countries of europe" and then we'd have the same information as we have now with categories. Categories without an associated article mean that they are better used as Properties (infobox information), so no big deal if we get rid of that kind of categories or we mass import that information as item properties.
The downside is that without categories we might lose the recommendation system they offer. It depends on which graphic interface would replace them.--Micru (talk) 16:18, 22 January 2013 (UTC)
The third stage of Wikidata is generating lists from the wikidata info. You will be able to, for instance, get a list of cities in Europe with population greater than 100,000, established before 1500 AD. This might be used for recommendation instead of categories but there is still a lot of work to be done in the various language Wikipedias as they work out how they want to use these tools and if they want to use them to replace categories. Each Wikipedia gets to decide for itself. Filceolaire (talk) 16:44, 22 January 2013 (UTC)
Hello, I've updated that page to reflect the consensus achieved on the now-closed RfC. Please take a look and complain about what I did, or go ahead and fix something yourself. It was a rather painful page to write, so I probably messed up somewhere. Ajraddatz (Talk) 19:06, 22 January 2013 (UTC)
My toolserver query to find items without langlink only shows items having sitelink in data object, but not in sitelink table. Merlissimo (talk) 17:46, 23 January 2013 (UTC)
Request for integrating Wikidata on Bosnian Wikipedia
Hi all! I first want to thank everyone for contributing to this wonderful project! The relatively small community of the Bosnian Wikipedia has voted[3], and the outcome is that we want Wikidata also to be integrated. FYI: I have been chosen as an representative. I don't know what the exact procedure is, so any information regarding this is appreciated. -- Edinwiki (talk) 12:54, 19 January 2013 (UTC)
I would support this, but I don't think this requires double approval - we should instead focus on the steps needed to integrate with bs.wp. Can someone with a fancy bot start running through their pages, and making sure we have the correct IDs here? Since the next batch of projects will be added to Wikidata on the 30th of this month, I see no reason to not add bs.wp along with them. :) Ajraddatz (Talk) 14:02, 19 January 2013 (UTC)
Support we should not delay a wiki who wants to contribute by inactivity. Edinwiki, the Bosnian Wikipedia can pave the road by translating the help-pages and other pages on Wikidata. Missing local translation is a major issue in integrating Wikidata in Wikis, as we have seen in huwiki.--Giftzwerg 88 (talk) 15:31, 19 January 2013 (UTC)
Just a quick update on this: It might not be possible in the next deployment because we need to make some changes first to accommodate a larger number of wikis. I will keep you posted as soon as I know more. --Lydia Pintscher (WMDE) (talk) 11:26, 21 January 2013 (UTC)
Ok I just confirmed: Unfortunately we can't add Bosnian to the next batch or to English after that. It'll go live with the rest after that. I'm sorry this didn't work out. It should be soon though so will not have to wait too long thankfully. --Lydia Pintscher (WMDE) (talk) 11:37, 23 January 2013 (UTC)
Labels in lingua franca languages needed and tool/bot(s) needed
Hello all, Currently we have about 20 items been created every minute. Each item should have at least an English title, and in the major languages like Spanish, German, French as well, as lingua franca. I think it is good to have automated the data been added by bots, as this data is maintained by bots for years. Still I think it is good to discuss and work on how we get managed to have all the labels been added. Partly some bots which create items include a title when a specific language is included as interwiki. Then the name of the title of the article is used as title of the item in that language. But if an article not yet exists the item doesn't get a title. How we make sure that all these items get an article?
One way of doing a large part of the articles is by grouping articles with a universal title for most languages, like species with their Latin name. Example: Flabelligera biscayensis. I think we should have a tool or something with what we can select if the item has a label already, is in a specific category or categories on a Wikipedia, to make it easy to add in large numbers the labels. (Also I think it would be good for Wikipedia's to have such tool with what they can see what article is missing in their own language in a specific category on a wiki compared to theirs.) AWB works fine for Wikipedia, maybe such tool/bot can be developed for Wikidata as well, to make work with large numbers easier to be done by users. Romaine (talk) 02:18, 23 January 2013 (UTC)
As we discussed on IRC, I do not feel that it would be appropriate to require English titles, because Wikidata is by definition multilingual and I see no reason to favor one language over every single other.--Jasper Deng (talk) 02:21, 23 January 2013 (UTC)
Sorry, I think you miss my point. (And still, it would be appropriate to wish for titles in the biggest lingua franca languages as that makes Wikidata better understandable for more users. Just as we are already work on for weeks now: Wikidata:Labels and descriptions task force.) I notice we have a lot of group-wise articles to which titles can be easily added if we can select such group and use a bot/tool to add the labels. I mentioned species like Flabelligera biscayensis with their Latin names as example. Another example is Q136561 and the group around this one. As items are created by bots in large amounts, users should have more tools/bots to make working on Wikidata easier to be able to work away the backlog of missing labels which is growing every day. Greetings - Romaine (talk) 02:33, 23 January 2013 (UTC)
User:Lsj@svwiki has bot-created thousands and thousands articles of species on svwiki. I think it would be a good idea if we could convince him to come to this project. He has the knowledge to add latin names for species-related items. -- Lavallen (block) 07:53, 23 January 2013 (UTC)
There can be items without a page in a specific language, that is not an error and we should not enforce creation of pages on Wikipedia-sites. There can also be missing labels, and those can be added as necessary. In some cases missing labels and descriptions are replaced by similar strings from other languages, and this is done for some of the special pages (they fall back to English) and there will also be a similar of solution for item pages (they will show labels and descriptions for the users Babel languages). On the item pages it is already easy to copy-paste between languages, but we could probably do it even simpler. It is possible to see this in action on Helium at dev repo, but without use of Babel languages unless you create an account. I think latin names is a property and not something the individual languages should be enforced to use, they should use their local names if they exist, but there has also been some discussions about adding a mul language and using that as a fallback. For the moment there is a special page Special:EntitiesWithoutLabel that will list the items that has no label, that makes it simple to find and fix the items. In that list some items will be listed with a label due to the fallback mechanism, see for example Norwegian (bokmål). What we could do is find some simple way to set the missing labels/descriptions directly on that special page. Jeblad (talk) 09:17, 23 January 2013 (UTC)
On the English Wikipedia there are lots of pages for Genus which list out the Species in that Genus but where the Species don't yet have their own pages. As Wikidata links are 1-to-1 only this means Wikidata can link to the WP Genus article but any Wikidata page for a species within that genus can't link to the English Wikipedia page. I don't think we can even link to a redirect page as Wikidata seems to check that and jump to the destination page.
What about project pages that are now inactive? For example there is page on many projects where people can ask questions about topics and other people try to find this information. On dewiki there is de:Wikipedia:Auskunft and enwiki has en:Wikipedia:Reference desk (which has mutiple subpages). On plwiki there was also such a page until 2010: pl:Wikipedia:Pytania merytoryczne. But now this page on plwiki is not active anymore, so it only exists for historical reasons and is full protected.
I think linking to this page from other active pages does not help people. The only reason to use this langlink to plwiki is to ask for local help. But in this case it will embarrass people, because noticing that this page isn't active anymore takes some seconds for not pl speaking people.
So what is the sultion in this case? Removing the pl-sitelink from the item? Or should we make a feature requests to mark a sitelink inactive? In this case "active" pages should only show langlinks to other active sites and inactive page to all other pages. Or has sb. another solution? Merlissimo (talk) 12:18, 23 January 2013 (UTC)
To amend this I have created {{Ll}} (short for Language Link), that is used pretty much the same way ordinary links are (except it's a template). It uses the Special:MyLanguage page (e.g. Special:MyLanguage/Wikidata:Administrators), so in ways it is just a shortcut to writing [[Special:MyLanguage/Pagename|Pagename]].
So, when you make a translatable page, please use this template for linking to other translatable pages – it makes life much easier for translators and non-English readers. :-) Jon Harald Søby (talk) 21:50, 20 January 2013 (UTC)
Save error: The external client site did not provide page information.
Would be nice if we don't need to check every sitelinks, that we can know which one don't exist anymore. Lithuania has so many links that I will not check every links one by one... so I can't update links using slurpinterwiki tool. Maybe some notice, that which link(s) don't work anymore, if possible? --Stryn (talk) 13:00, 23 January 2013 (UTC)
We could add a non-default argument to the API-call wbgetentities that rechecks the sitelinks to see which one exist. That would be a pretty heavy check and I'm not sure I like it. An other solution would be to make somewhat more usable error messages in the cases where we need this to do further cleanup,… The thing is we need to keep the overall load down and avoid those heavy checks if possible. Jeblad (talk) 14:44, 24 January 2013 (UTC)
RfA support ratio
There are two different percentages of support votes needed to pass a request for adminship successfully: In the header on WD:RFP it says 75%, while there is an 80% margin of support defined on WD:A. Which percentage is actually correct? Regards --Iste (D)14:05, 23 January 2013 (UTC)
There are some problems with the subdomain-less url, that is wikidata.org. If you bump into this then try www.wikidata.org instead. It typically pops up as weird redirects and missing pages. Jeblad (talk) 10:02, 24 January 2013 (UTC)
Wikimania in Hong Kong
Wikimania in Hong Kong is coming later this year. Let's get the planning started. It'd be lovely to see many of you there.
Who intends to go?
I will submit a talk proposal about the current state of Wikidata and lessons learned from its development. (Maybe I'll split it into two proposals.) Is anyone interested in doing that together with me?
We need some kind of page where the translators and translate admins can learn how to do the translations, and how to maintain all the translate specific stuff. That is translators and -admins on this project. There isn't much they need to know, but when they somehow screw up then we are loosing previous work. I've been there and done just that, and lately I saw this happen once more but forgot to fix it there and then. Often there are very little evidence that something is wrong so we must be careful and do the right things. Right now we have nearly no working translations of the page Wikidata:Glossary, I'm tempted to reset the source page (diff of the English version) and the translations to the version as of 31. December 2012, and then we can try to piece together translations in other languages that has later changes than the English source page. I think that would be easier than trying to figure out how all sections (statistics) should be changed in all languages. So loose a little work and get going, or do a the bigger job? I say undo… Jeblad (talk) 17:40, 18 January 2013 (UTC)
Part of the problem is that we are translating unfinished pages. We could hold off translation until the pages are "done", i.e. in a few months. Ajraddatz (Talk) 00:01, 19 January 2013 (UTC)
I would like to propose to use mw:Help:Extension:Translate and it's subpages as an guide for translators and translation admins. Infact I want to go one step further and make them a guideline. I think that one of the reasons for this problem is that we are not following that guide.--Snaevar (talk) 01:11, 19 January 2013 (UTC)
None that I know of. Do we have sufficiently high level of vandalism to justify the template, or may be all warnings could be done manually (users tend to better understand manual warnings)?--Ymblanter (talk) 09:42, 23 January 2013 (UTC)
I would love it if we never created or used vandalism templates, and rather left hand-written messages for obviously good faith contributors. Vandals can just be ignored and blocked for short times as needed - years of experience have shown any warnings to be completely ineffective with vandals, and giving templates to good faith users just pisses them off. Ajraddatz (Talk) 22:00, 23 January 2013 (UTC)
Templated messages are not ideal, but I do find it prudent to warn any good-faith contributor before if and when a block is needed. Right now, hand-typed messages seem to be a good way to go, since the purpose of templates is to counter large amounts of vandalism, which is not necessary here.--Jasper Deng (talk) 22:49, 23 January 2013 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Personally, I'd prefer hand-typed messages, although the only advantage with using templates is to help with auto-translation of the message. Hazard-SJ ✈ 04:40, 26 January 2013 (UTC)
Please explain the infobox strategy and data model
I am not clear on the plan for phase 2. Should data for the infoboxes mainly be collected from today's geoboxes and other standard infoboxes at various Wikipedias, or from external sources such as CIA fact book, and then further pushed to the infoboxes? In the first case, should all infobox data be collected to Wikidata from all Wikipedias, or only standard infoboxes, that have corresponding templates in several languages, with harmonized parameter names (or that accept the same English parameter names)?
If for example the enwiki version of the article about a German city gives one geographical position, and dewiki another, should the dewiki be directorial? Or should we rely on an external source for geo-positioning?
I have not really understood the Wikidata documentation regarding how the data model will look for infoboxdata. How wikidata items, entities, properties, attributes, descriptions, labels, etc., should be related to the MediaWiki template (infobox) name, parameters, parameter names, variables, variable names and categories. Is there a standard mapping between infoboxes and wikidata, or do we have to develop a new wikidata model for each infobox? In the latter case, where will the mapping for each infobox be documented? At this site, or in the actual infobox code or documentation in the Wikipedias? Mange01 (talk) 09:40, 24 January 2013 (UTC)
Sorry, this is going to be somewhat lengthy!
I totally agree on your comment about the data model as it is documented now, it is very difficult to go from that one to how it is actually implemented for some existing data set. We should develop some user documentation, and some documentation is some slowly getting in place. Unfortunately it will take time before that is up to a level where it actually describes whats going on in the code, and it will/should also reflect internal policy on this project. The code and the policy might diverge at some point, but that should be according to community decisions.
Items uses a schema-less model, that mean they do not adhere to a specific layout for data describing a specific external entity. You don't have to develop a model (schema) for a specific item, but we could create tools to support building specific items. It is not necessary to use categories to to connect to the correct item, we use sitelinks to do that. Because of this schema-less nature we could get additional errors. The external entity is described by a number of statements in the internal item, and there could even be misplaced statements that describe something completely unrelated. Even if that would be an error in the Wikidata item it would not have any consequences on the client Wikipedia pages unless someone want to include the erroneous entries.
Data from infoboxes will be put inside statements, and those statements will be according to specific properties. Those properties will be defined on their own pages like items, and will have a definition that is the same for all languages. Each property will have localized names and descriptions, they have much of the same structure as items, and if one property is called "navn" like the parameter in w:no:Template:Infoboks forfatter in Norwegian (bokmål) Wikipedia, or "name" in w:en:Template:Infobox writer, or "naam" in w:nl:Template:Infobox auteur doesn't really matter. The important thing is that the data values filled in should be the same. In some cases the data values needs to be localized, but hopefully that happens rather seldom and only for strings. For names that will happen often because of different writing systems in different languages. In other data values like "population" in municipalities that would not happen as we could easily transcribe numbers where necessary. In some cases data values used in one Wikipedia could be in conflict with other Wikipedias, even all other Wikipedias. In those cases users from that Wikipedia could enter a value that is even marked as rank "deprecated" in Wikidata and the Wikipedia could still use the deprecated one by giving an explicit reference to it. We should have tools for identifying use of deprecated values, at least the client Wikipedias should have such tools for identifying its own use of deprecated values.
One important point is that the parameter name on the client Wikipedia do not have to match up with the localized property label on the Wikidata repository, they can be completly different. On the Wikipedia client the property values will be included with parser functions and those use sitelinks and the property labels to identify the property values. There is a whole bunch of magic going on there! Usually the magic will work but in some cases it could be necessary to help the parser function to find the correct item. One important case where this happen is for books if we want to support cite templates in the Wikipedias. Those must be explicitly referenced. More about that on m:Wikidata/Notes/Inclusion syntax v0.3.
Data from infoboxes on wikipedia can be used as an initial source for statements in items, those will probably be without valid source and because of this I think that over time we should shift to use data from external sources and give proper references. We should strive for more or less complete coverage by references for all statements that are promoted to "preferred" status, and we should probably build some tools so we can identify subsets of such statements.
Note also that there is no automatic mapping from the present infoboxes as they are used on various Wikipedias and to the statements used in the items on Wikidata, neither for values used in the infoboxes, and that the existing templates for the infoboxes will not be reused for defining properties. Data that shall be reused must be transferred manually, or with specialized bots and then validated manually. It should be possible to automate some of the process, but not all and it definitely need manual inspection and validation. That is, for iw-linked templates parameter names can be identified as the same by manual inspection or by comparing values. Parameter names could then to some degree be reused for the labels in the properties (upcoming stuff, there will be pages for property definitions like for items) but note that in this case it will be very important to make good labels and descriptions to avoid misinterpreting the properties. In my opinion "navn", "name" and "naam" is all to simple as labels for the properties, they should be "personnavn", "personal name" and "persoonlijke naam" or something similar. This is because the template name gives a context that is missing in the property. The descriptions can't be used for disambiguation in this case because we use the labels for identifying the property. Hopefully we won't run into trouble due to similar properties that should (but can't) be given the same label. Jeblad (talk) 14:31, 24 January 2013 (UTC)
First I want to praise you for your commitment to Wikidata and this forum. Some of your text might be placed in the documentation.
I'm new to Wikidata, and might have misunderstood something, but these are my suggestions:
Phase 2 data uploading strategy
Before phase 2, data should be collected from Wikipedia iw linked infoboxes. In a later phase, data should also be uploaded from external sources.
We need to minimize the manual work, and find a simple and generic model for the bots to collect all parameters of all iw marked templates.
We urgently need some good examples, from which a generic data model can be derived, making it possible to address any piece of infobox data. It should be based on enwiki infobox parameter names. Multilingual descriptions and labels can wait. Any suggestion?
To avoid data conflicts, to start with, the dewiki bot should only upload data related to German speaking countries. (E.g. German and Austrian places, persons and phenomenons). And nowiki data related to Norway, etc.
In case of data conflicts, sourced parameters may automatically override non-sourced parameters. Data with newer source publication date may override older data. (Or should several versions of the data be stored, e.g. based on different sources, or different Wikipedia language versions?)
I don't know how to do with calculated parameters, based on other template calls. Can the result of the calculation be stored in Wikidata?
Next step is phase 2 data downloading, i.e. pushing data to infoboxes in the Wikipedias:
In the template code or template call in the Wikipedias, parameters to be automatically updated should be marked "auto" or with an address to the wikidata piece of data.
Thus, the decision to update, and the choice of version of the data, if several, is not completely left to the bot owners.
Part of phase 3 strategy
A wikidata user interface (a javascript gadget) should be developed, that may show tables with all parameters of all templates of a certain type. One article per row, and one parameter per column. It should be possible to filter, sort and search in the table based on source, article categories, parameter values, etc.
It should be possible to use the gadget to easily edit directly in the table, especially if there is no external source for the data, or if it is not fetched from Wikipedia infoboxes. Otherwise, quick editing of large amounts of data should somehow be restricted for security reasons.
It should be possible to easily upload a whole column, or a whole table, from an external source. (A spread sheet or other file that is imported directly to Wikidata by an administrator using a simple tool, or a file from a web site that is considered reliable.)
Any opinions? Mange01 (talk) 20:44, 24 January 2013 (UTC)
Sketch of the UI with statments and a few referencesThanks for the praise, but I'm on the dev team so that could explain a lot! =) I put in numbers instead of bullet points in your text, it makes it easier to comment specific list items.
Phase 2 data uploading strategy
Bots for stripping out the data and organizing it could already be made, I think that is more work than implementing the uploading strategy.
It should definitely be possible to find a generic way to parse out the data from some of the simpler infoboxes, but in some cases the values can be quite involved and be wrapped in additional templates. That could be messy.
As soon as the properties and statements are available the examples solves themselves, but there are some "screenshots" for usecases that show how this will work. Multilanguage labels can't really wait as they will be used for addressing, but initially we could use English labels if they exist. Perhaps someone in the community can come up with a good matching algorithm to find which labels belong together?
Seems like a good idea for data we get from Wikipedia, but as soon as possible we should use sourced data from external providers.
Sourced data might replace a preferred value, but that is not something that can be done in general. A specific sourced value might be wrong, outdated, or biased. This also holds for newer data. I think that Wikipedia usually try to only use valid and up to date entries in the infoboxes, and we might depend on time and date from the history of the page, but note that Wikidata can hold outdated and deprecated values.
Phase 2 data downloading
We can put in a reference to Wikipedia, just like any other book or site. (Well, it would be a little weird as it will be a self-reference sort of. Perhaps we can use a link to the history.) Later on we can search for and replace preferred values in statements if the reference says they are from Wikipedia, or simply insert new values from external providers. Often those external providers would be national census bureaus, and we could somehow grant them the right to set values as preferred. I think that only trustworthy users should be allowed to set specific values as preferred. (Values in this context is what we call "snaks", but I'm not sure that is a good word.)
Not sure if we should use a consensus model on updating, I think it is better to let users update and limit somewhat who can set the value to preferred. This is a decision for the community.
Part of phase 3 strategy
Seems to be whats planned for "queries" in Phase III, but partly it is also about maintenance pages to identify which items has a specific property. Both are difficult to make as gadgets because of the amount of data that has to be downloaded. Queries will limit the amount of data transferred, and it could be formatted and analyzed both by Lua and Javascript.
Not sure if we plan to implement direct editing of values through a query, but it surely would be possible. All entries in the result set would have the id of the item, and from that an edit interface could be built. The existing Javascript we are using now should support that, but it could be that the UI must be put in a dialog on top of the table. That is you click on a row and then you can edit the item.
We have no special page for that, but I have been wondering for some time if we should make something. Whats make this somewhat difficult is that uploading data is a very iterative process. It was somewhat easy to make an "edit interface" (that is the API call wbeditentity) for composite edits as long as we didn't have statements, but statements makes it very difficult to build regular table-like data. Whats makes it difficult is that properties can have datatypes with optional fields. Perhaps it is possible, I'm not sure.
Thankyou for good comments on each and every of my suggestions and questions. I get the impression we agree on almost all suggestions. Which parts of the above discussion can be transferred to the project documentation - and to which manual pages?
Formulating generic principles is always dangerous without testing the principles on use cases. I suggest that the documentation should as soon as possible link to real template examples and Wikidata entities as reference cases.
Regarding Phase 2 data uploading strategy, point 1, a generic model: Should the parameter names from the actual infoboxes, e.g. ]]en:Template:Infobox settlement, be primarily used, or the corresponding parameter names from the generic mother templates that these call, e.g. en:Template:Geobox?
Regarding Phase 2 data downloading, point 1: You pointed out an important issue - how to make Wikidata history tracable, when data is collected from one Wikipedia and later presented on other Wikipedias. If the template is refering to an external source I guess this is not a big issue. A suggestion is that we skip, or wait with, unsourced template data at this stage of the project.
Another issue is security and vandalism, if we allow non-bot owners to change large amounts of data from this site. Any suggestions there? Uploading data from reliable web sites might be one way, or having a procedure for asking bot owners to manually upload tables in specific sources.
Regarding phase 3 strategy, point 4, uploading or editing tables: Why not use an open-source online spreadsheet tool to view and edit the tables, and to import data from other files of various format? This might in the future also be used to easily and automatically generate charts and plots from tables, to automatically calculate new values based on other Wikidata values, to produce filtered and sorted tables, etc.
Okay, I suppose that the companies that are funding the wikidata development might prefer plots produced using their commercial online spreadsheets. They have insight into the project, and might be developing specific Wikidata retrieval functions. But using one tools does not stop us from using another, and for automatically updating material on Wikipedia, open source software is the only option.
If you want to start on help pages there should be no problem, but be careful with turning them into a rigid guideline or policy before phase II goes live. Examples of templates on Wikipedia and how they interact with Wikidata should be possible, but it is perhaps easier to make things like that on our test and dev servers.
I think the property names should be created manually, it is to easy to end up with really weird names.
Unsourced entries in Wikipedia can be given a reference to the old values in the articles history. I don't think that would be a problem.
The site is a wiki in the spirit, that is all edits will be open. Only limit I know of that is considered is a kind of light-weight FlaggedRevs that only uses ranks of statements. Only admins and/or patrollers and/or other trusted users are allowed to change them. Because the value of the preferred statement is the one going live on most sites, and it is a kind of half-way protected, the infoboxes on Wikipedia will be less susceptible for vandalism.
I don't think anyone has given table editing much thought, it is possible and that is how far we have come on that issue.
My question is rather easy: is it possible to move data from infoboxes to wikidata step by step? (Adding a new statement) And is it possible to delete statements again? If that is true, will there be a history? What happens if I add a new statement in Wikipedia? Will this new statement be seen at once at all Wikipedias? Is it possible to use statements from Wikidata and statements stored in my local Wikipedia together? --Goldzahn (talk) 07:10, 26 January 2013 (UTC)
Yes you can move data by adding statements in Wikidata that describes the content of each parameter in an infobox, and it can be done as a manual step by step process. It will also be possible to remove them again, but we assume old statements will simply be left in the item as new ones are added. You can add new ones without interfering with whats already there. There will be a history for the items in Wikidata, there already is a history tab and it will continue to work like now. When you add something it will always be visible in the Wikidata repo, but it depends on how the inclusion is done in the Wikipedia clients whether the new statement will be visible. A shortened history of changes for the item will also be shown in recent changes and the watchlist, but I'm not sure about the history for the articles.
Technically the updates in Wikidata triggers an event that goes into a queue, and in an regular interval the events for this queue is dispatched to the destination clients. Those clients are Wikipedia. In the clients the events will trigger purging of pages, which will then render (be built) again as necessary, and will add entries in recent changes and watchlists. When a page renders it will have access to the items data and include it on the page as necessary. By triggering a purge the page is rendered with values from the newest statements in the item, and all appropriate changes should be visible in near real time. This happens in parallel on all clients. Jeblad (talk) 07:58, 26 January 2013 (UTC)
Interwiki of the non-encyclopedic pages (Help, "Wikipedia", etc)
Hi,
I don't really remember, if someone says on the project chat, that the non-encyclopedic pages ("Help", "Wikipedia", etc) will have or not their interwiki on wikidata ? And I don't fund some kind of interwiki page on wikidata. So there are excluded ? I remember that maybe there was a discussion (and a post on bugzilla) for the interwiki of user page, but I did'nt found that discussion... --Nouill (talk) 11:50, 25 January 2013 (UTC)
In fact, today I start to write few paragraphs to ask if it will be possible to create some places like wikiprojects for coordinations the merge, split and deleting process and policies between the different wikipedia, to coordinate the help and rules pages between the different wikipedia, and to coordinate the transfers polities between project (Example : Wikipedia to Wikiversity, or to Wiktionary, etc). I start to write that for Individual Engagement Grants, but now I remember that Wikidata:Requests for comment exist, so I did'nt know where to put that text. I think wikidata it the only place where this kind wikiproject can be made. I will be a little similar to Wikidata:Interwiki conflicts, but "Interwiki conflicts" aims actually is just to separate the problematic interwiki but not to coordinated the merge and split process, and not to said at the different wikipedia that they should be great if they can merge or split problematic pages, if they want to be coordinated with the other wikipedia. But I think both of those maintenance pages can't run in long terms without the other. Moreover, maybe it is a little to early to talk to that in wikidata, and this kind of stuff will have much audience when all the technical aspect will be done ? --Nouill (talk) 16:18, 25 January 2013 (UTC)
While Wikidata may generate lists of problem pages on Wikipedia that doesn't mean Wikidata should fix these. I would suggest that we leave each Wikipedia to decide for themselves if they want to split pages which cover more than one wikidata entity. Wikidata will then have to figure out how to manage the sitelinks to pages that cover more than one entity. Similarily for merged pages. Sometimes there is a real subtle distinction between pages that a wikipedia wants to keep separate. That is up to them. For English Wikipedia I will propose a merge because that is my first language and I have editted there enough to start to understand how they do things and I know the language well enough to be able to explain my actions. I don't think I know other languages well enough to do this on other wikipedias. Having said that there is no reason why we can't post a link to our list of possible merges to the village pump, or equivalent, on each wikipedia. Filceolaire (talk) 21:24, 26 January 2013 (UTC)
Wikidata:About
Wikidata:About is a pretty promiment page, linked on main page. Unfortunately it's outdated ("The Wikidata development team aims to have ways to input and browse data available for infoboxes by December 2012 / January 2013"). Also there is a dub on meta.wikimedia.org/wiki/Wikidata. I think the meta.wikimedia.org page should be turned into a redirect. (It's #1 on German Google search if you are looking for "Wikidata", but it's pretty hard to find a way from the meta.wikimedia.org page to the "real" Wikidata.) --Kolja21 (talk) 03:28, 26 January 2013 (UTC)
I would prefer if we could completely rewrite the about page here and additionally work on improving the one on meta so it leads people here more prominently. Please don't turn it into a redirect. If you want we can further discuss this on IRC. --Lydia Pintscher (WMDE) (talk) 08:40, 26 January 2013 (UTC)
The Wikipedia:About page here on this project needs updating, but the page at Meta is a navigational top-page for the documentation about development, process, and so forth. It should not be made into a redirect. See for example m:Special:PrefixIndex/Wikidata for a complete listing of whats beneath this page. Jeblad (talk) 12:10, 26 January 2013 (UTC)
Thanks for the info. I understand (now) why there a two pages but they should offer more than copy & paste. Still much work to be done ... --Kolja21 (talk) 18:12, 26 January 2013 (UTC)
QRpedia (Q2182) provides a link to a page in your preferred language. I have no idea how it manages this but it does seem to marry up to the capabilities of wikidata.
Could we have a function where you can write a URL which links to wikidata but which automagically gets forwarded to the Wikipedia page in my preferred language? Filceolaire (talk) 22:45, 26 January 2013 (UTC)
I don't know about this, because when someone goes to Wikidata they usually would look for data compiled from all languages, and can visit their preferred language if they wish. Are you talking about having a redirect like http://www.wikidata.org/wiki/index.php?title=Q2345476567&forward=yes&lang=fr?--Jasper Deng (talk) 22:49, 26 January 2013 (UTC)
Yes except it doesn't have lang=fr in the url because the web page or QR code doesn't know what language you want. Wikidata queries your browser for your preferred lang if it gets a url with "forward=yes" in it (at least I guess that is how it would work). Filceolaire (talk) 22:59, 26 January 2013 (UTC)
This could be implemented externally e.g. the site wikipediamultilanglinks.com/Q120129 would look up the language settings of the system/browser and then look up if there is a link on Q120129 for the language and if so redirect there automatically. I don't think Wikidata should provide this function. --Sk!d (talk) 00:03, 27 January 2013 (UTC)
Hi, is there a plan to ensure, that updates made between the creation of a specific wikidata item and the final golive of wikidata will not be lost?
e.g. a new interwiki is created only in the wikipedias, but not in wikidata. Meanwhile it might be possible, that some other interwiki is changed in that specific wikidata item. As a result you would have two different sets of interwikilinks, both with appropriate recent adjustments.
How can we ensure, that non of thees changes are lost, when wikidata finally is activated in all the wikipedias (and the old interwikilinks will probably be removed by boots)? --Teilzeittroll (talk) 10:45, 27 January 2013 (UTC)
I hope that old interwikis will be online removed by bots if they are excactly the same as the wikidata item (I think this will be still over 95% of the items). The leftover might be removed by hand or the bot might update the wikidata item befor removing the interwikilinks. (Merlbot has in many wikis interwiki botrights) --Sk!d (talk) 11:50, 27 January 2013 (UTC)
A least one of the bots, I think Merlbot, is already Wikidata proved. If he changes links in Wikipedia, he also change the Wikidata item. --Kolja21 (talk) 13:23, 27 January 2013 (UTC)
I think we should inform Wikipedias on their community channels or place a temporary information in source of the lemmas (or maybe history is enough(, that interwikilinks moved, either. Importand reason is, that there are not building up annoyances at the authors side... Conny (talk) 13:36, 27 January 2013 (UTC).
Working through the anomalies identified by the 'Import task force' I found lots of places where the wikidata page needed to be different from the interwiki links on the wikipedias.
Links were split between two wikidata pages where I merged the wikidata pages, without updating the wikipedia interwiki links to match.
a wikipedia page with links from two different pages in another language wikipedia. This is banned by the wikidata software so I had to figure how best to link to these on a case by case basis but always the result is that wikidata is different from what is on the wikipedias.
Where the bot finds the wikidata and wikipedia languages links are different I think manual intervention will be needed. If a tool can be developed to easily compare the two then I think this should go fairly quickly for most cases. Filceolaire (talk) 14:34, 27 January 2013 (UTC)
As there is a easy api request every bot owner on the different wikipedias should be able to do this. --Sk!d (talk) 16:12, 27 January 2013 (UTC)
Bot-added items
Hi, apparently bots have been busy adding nearly all existing Wikipedia articles to Wikidata. I am a bit sceptical about this (I think at the very least there should have been an announcement on e.g. the mailing list, or did I miss something like that?), because there are a lot of pages that are about the same thing but that were/are not yet linked to each other (or two groups of articles that do not know of the other group). I often encounter such pages, and in the past I just linked them to each other but now, with these bot-added items, there is almost surely an item about both [groups of] pages, so I have to merge them (then I'm even lucky I am able to delete the redundant item). It's very difficult to estimate how many such pages there are, but I'm sure many items will have to be merged from now on. I did not look into the archives for possible past discussion, but imho we should have been more careful and e.g. only have added pages with existing interwikis for now. Anyway, it's too late now... SPQRobin (talk) 15:43, 27 January 2013 (UTC)
It is enough to have one article in one language to create an item. How else can you ever find the corresponding article for a a second new created article about a topic, if there is no item of the first article in Wikidata? You´d have to search all Wikis in all languages and in exotic alphabets. So whoever writes a new article about a new topic will cause a bot to create an item in Wikidata. Giving the item a label and a description in any language that uses the latin alphabet might help in finding corresponding articles in wikidata. It is just necessary to add the sitelink once and for all. --Giftzwerg 88 (talk) 16:32, 27 January 2013 (UTC)
Wikidata only started a few months ago, we don't need immediate full coverage. It's quite easy to find corresponding articles in the languages you know (usually the Wikipedias with a larger number of articles anyway). Anyone who writes a new article should check in the languages he/she knows if there are other articles or a Wikidata item, instead of letting a bot create a separate item for that article. In my experience you can only find duplicates via Wikipedia, not via Wikidata, since you need to know what the article content is about, so I don't really understand your first question. But, as I said, I'm not totally against this, I just think it was not a good idea to do it at this point in the Wikidata development. Also, maybe an easy merge feature could be developed? So we can easily fix duplicate items? SPQRobin (talk) 16:48, 27 January 2013 (UTC)
Yeah, that would already be great, but a tool to merge two items into one would also be helpful. (FYI, there's a Special:MergeHistory in core MediaWiki but disabled by default. I'm not sure how that would/could interact with Wikidata though.) SPQRobin (talk) 17:52, 27 January 2013 (UTC)
The Wikidata:Wiki import task force has links to lists of problematic pages in various languages as tagged by the bot that imports links. The problem pages listed there probably include most of the pages Robin is talking about; Local lists wikipedia pages that seem to be duplicates which should be merged; Global lists wikipedia pages where there are two or more wikidata pages that seem appropriate. I have gone through and fixed nearly all of the Globals on the hu:WP. Doing this I found lots of cases with duplicate wikidata pages which I merged. Filceolaire (talk) 19:25, 27 January 2013 (UTC)
Right now we have a very weak integration between the different WMF projects. Just to give an example, when I want to transcribe a book in Wikisource, first I have to upload the djvu file to Commons, then create an author page in Wikisource, create another book page for the book in Wikisource and link it to the author page, and finally link the author page to Wikipedia. So I'm editing on 3 sites with no direct relation to each other, input 3 times the author data and book data, which could change any time and then it wouldn't be updated.
When the interwiki phase is finished, is it planned to do a similar integration with the sister projects and address such redundancy problems? --Micru (talk) 16:29, 22 January 2013 (UTC)
I think sister projects integration can be sub-divided in three parts. 1) centralize links to siter projects; 2) use infobox data in sister projects; 3) inject information from sister projects into wikipedia (like "show books by this author"). I agree with you that the infobox part has to be done after that is more mature, but it would be great if part 1 is taken into consideration now, since it is similar to the interlink problem. What do you think about expanding the "site" list to include all sister projects with their language versions? --Micru (talk) 00:20, 23 January 2013 (UTC)
I don't think there is any disagreement about that. The point is the dev team is already overbooked with getting phase 2 into shape. Other things have to wait. --Lydia Pintscher (WMDE) (talk) 11:25, 24 January 2013 (UTC)
For Micru´s original example of transcribing a book in Wikisource, we can - later on - have an item with the author data and book data. Lets say that we have an item Q4000010 which has several values. One named "author" for the author, one named "title" for the title, and so on. Then he would add the syntax on all of those pages to include the author. He would also add the syntax on all of those pages to include the title of the book...and so on. Then when the author data and book data needs to be updated, it only needs to be updated on Wikidata.--Snaevar (talk) 13:36, 24 January 2013 (UTC)
I'm quite aware of all the problems you have been talking about and it is not an easy task to solve them in an easy way. Since it is a problem that I would like to harness, I have started a Grant application to explore all the options and to define a vision about how it should be done, please, check my grant application and share your thoughts, thanks!--Micru (talk) 06:24, 28 January 2013 (UTC)
During Wikimania we spoke extensively about this problem, some of our thoughts have been reported here. We also tried to convince Lydia to put bibliographic metadata on Wikidata ;-). Wikidata seems obviously the best way for coping with metadata problem (and with metadata I intend bibliographic data and stuff like that), which are the core values for projects like Commons and Wikisource (if you cover Author/Creator data and Book data, you solve a lot of issues for bot the projects). Thanks to User:Tpt and others, now Wikisource has implemented a OAI-PMH protocol for exchanging Dublin Core metadata, which are stored in Index pages (it is a proper namespace on Wikisource). The problem still is that we have a ns0 and Commons and neither of those can properly exchange these metadata. Defining a good workflow for this would be paramount. --Aubrey (talk) 10:12, 29 January 2013 (UTC)
We intend to have a solid base for the statements of phase 2 at the end of the current sprint (tomorrow). So yes. It'll however not be deployed here in January. I'll let you know as soon as I can when this will happen. --Lydia Pintscher (WMDE) (talk) 18:50, 29 January 2013 (UTC)
VIAF integration?
Authority control: Mockup 1 by Theopolisme
Will there be VIAF integration in the future stages of the Wikidata project? Currently Wikipedia is adding VIAF reference numbers to biographical pages; it would make sense to add that information to the corresponding data items here as well. --Ksd5 (talk) 20:49, 20 January 2013 (UTC)
GND, LCCN etc. are authority files. A person is identified by his name, life data, publications etc. and gets a number. Also works, terms and places get their own number. "New York" is a city (GND 4042011-5), a state (GND 4042012-7) and the name of a publication (GND 4185014-2). The name is ambiguous, the number is unique. (This work is done by humans.) VIAF is a collection of authority files. (This work is done by bots/algorithm/machines.) --Kolja21 (talk) 12:41, 21 January 2013 (UTC)
There should be no problem adding this as a property, but there could also be some reason to handle it different. Jeblad (talk) 13:46, 21 January 2013 (UTC)
It is data from a third party about an entity, it is not a property about the entity itself. It is like the badges problem. Jeblad (talk) 06:05, 22 January 2013 (UTC)
I dont see what makes VIAF different from other good-quality datatbases, and there are hundreds of them. Actually in a few years, it seems very likely to me that most Wikidata entries will be better quality than the equivalent VIAF entry. So authority control displayed prominently at the beginning of the article does not sound like a very good idea to me. Having them as properties -with an "external ID" datatype- sounds simpler. --Zolo (talk) 08:17, 22 January 2013 (UTC)
Imho it's not a question of better quality but a question of cooperation and international availability of data. GND (10 million items) and VIAF are linking already back to Wikipedia. If Wikidata adds their ids, libraries and archives worldwide can use our work. (BTW: They don't have to be displayed prominently, they can be displayed at the bottom of an article like in Wikipedia.) @Jeblad: If the authority ids would be implemented like badges, would it be possible to prepone the ability of using them in Wikidata? --Kolja21 (talk) 13:23, 22 January 2013 (UTC)
It is a nice mockup. VIAF is for authors, I think IMDb is comparable with VIAF in some way as link to the outside world. Perhaps we should make a list of databases we should have field for in Wikidata? Romaine (talk) 01:08, 23 January 2013 (UTC)
I agree with Romaine. Having a list of accepted databases would make things nice. VIAF would be handy for articles about people. --Rsrikanth05 (talk) 10:20, 23 January 2013 (UTC)
We should have some way to maintain uniqueness for a property value… For example, it should be only one person with a specific VIAF-identifier. 93.220.91.5318:20, 23 January 2013 (UTC)
Can I say that it is more than the WPs that have VIAF in use, Commons (Creator namespace) and enwikisource (Author namespace) have been using for an extended period of time. I would think that the ability to match on applied VIAF codes could be something that Wikidata may be able to use to establish interwiki with a bot, especially across the sister sites like Commons and Wikisources with their dedicated namespaces. Though I note that VIAF still has issues with multiple identifiers for the same person, though there does seem to be some effort to tidy that up as the institutions seems to be reviewing the data. — billinghurstsDrewth00:11, 27 January 2013 (UTC)
I'm forwarding this discussion to Max Klein, who was the guy that run the VIAFbot for enwiki few months ago. I think he planned to do the same for Wikidata. --Aubrey (talk) 08:47, 28 January 2013 (UTC)
Firstly, I work for OCLC, who operate VIAF, and I am in contact with the engineering team. I wrote w:User:VIAFbot that imported >.25million VIAF IDs into English Wikipedia. Needless to say, I definitely support VIAF IDs in Wikidata.
Data-type? Ideally I agree that this not really a property of the concept, but a same-as relationship of the concept-ID. That being said, using a property works, fine, and I don't think we should let the special data-type issue stop us from using VIAF.
Uniqueness of ID?. It's true that often VIAF ID clusters can become fractured, or are sometimes wrong. I spoke to the VIAF engineering team, and they told me that they will start to use incoming links as hint in clustering. So if the Wikidata concept points to the right VIAF IDs, but the VIAF ID points to the wrong Wikipedia page, then next time VIAF clusters are recalcutated (approx. every 6 months) the reciprocating link will be corrected.
A synchronizing bot. I would really like to write an VIAF import bot that would check all the Wikipedias and sister projects and in the cases where - via interwikilinks - two or more wikis don't disagree about a VIAF ID, write to Wikidata. When, and where can I get a bot flag? Maximilianklein (talk) 16:37, 28 January 2013 (UTC)
One of the main deficiencies of the Translate extension in that it makes a distinction between the "Source" page and its translations, essentially barring those who don't speak the source's language from contributing. Since all translations pages have to be specifically translations of the source page, users can not add content to them, or really modify the existing content. Ideally, I think we'd have a system where there is no single "source", and all the pages are just translations of each other, and any edits to any of them in any language would translated to the other translations. Under the current system, if we were, for example, to use Translate on Wikidata:Tools, all non-English speakers wouldn't be able to add their tools to the page. Similarly, for all other pages that are just translated from English to all other languages, no non-English speakers have any way to contribute. A partial solution to this might be to just set the source page to be multilingual ("mul") and allow all languages to be used on it, and have all translation pages, including an English page, be translations of it. This wouldn't help people modify existing sentences or sections, but it would allow adding new sections in non-English languages. Would this be possible? Does anyone have any ideas for fuller solutions? --Yair rand (talk) 23:54, 23 January 2013 (UTC)
This annoys me too. But I dont know if this is possible what if there is no one how can translate from a small language to e.g. English? What if I edited some thing in German and someone else edited the same section in English? --Sk!d (talk) 00:12, 24 January 2013 (UTC)
Ideally we'd have some system of merging edits if multiple edits are performed in different languages before translation could take place, probably. If we had edits being done in a small language that weren't translated into English due to lack of available translators, it would still be better than the current situation where the edits couldn't be done in the first place, even for its own language. --Yair rand (talk) 05:08, 24 January 2013 (UTC)
Adding changes to a less used language will not help the overall translations as very few would speak the language. Discuss changes at the talk pages and make a draft before adding it to the English source. 93.220.91.5309:56, 24 January 2013 (UTC)
Adding a change to a less used language would help readers of that language, even if it wouldn't help other users. Users who don't speak English can't discuss it on an English talk page. --Yair rand (talk) 10:17, 24 January 2013 (UTC)
The translator has freedom in translating an english section. Once in a while I dropped a sentence, that is not helpfull in the translated version. I also added sometimes an explanation or i changed the examples to items that also exist as an article in the translated language. No rule demands the translations always have to be 100% the same content. So if yo miss something, just include it to the section, no matter what the english version says. For each section there will be proofreading by other users. The proofreaders will accept a helpfull enhancement or bring in another solution. Most of my alterations were accepted by the proofreaders so be bold! And remember: its a Wiki, so also the english pages can be modified if it is necessary. --Giftzwerg 88 (talk) 00:07, 25 January 2013 (UTC)
I think you're missing the point. Most people can't speak English. They can't change pages in the same way that English speakers can, right now. If WD:Tools used Translate, and a Italian speaker wanted to add their tool to the page, they would be entirely unable to. Imagine if the "source" language was Swahili; most people wouldn't be able to help, even for speakers of their own language, let alone having their changes translated to other language for other users, and essentially everything would be dependent on Swahili-speakers to go through. This is not a good situation to have. --Yair rand (talk) 01:50, 25 January 2013 (UTC)
I´m talking about translators from the English version to the local version. These translators must be able to communicate in English, otherwise they are not qualified for translating and can not contribute to the translations. At least they should be able to bring up enough knowledge to post a request or a complaint on the discussion page. Maybe there are some rare langugages that need an intermediate language as Spanish, French, Arabic or Russian to find somebody for translation. But here the same principle applies: there is sufficient knowledge needed to communicate. Here are lots of multilanguaged Users who can communicate in lots of languages, at least on a basic level. If ever an Italian will post his tool on the discussion pages for integration on the pages, there will be somebody to help him. I sometimes fixed langlinks in languages, I hardly know enough to find out which tab means "read" and which is "edit". If the whole project depends on Swahili, the translator must be able to communicate in Swahili, otherwise he can´t do anything in translation.--Giftzwerg 88 (talk) 17:59, 25 January 2013 (UTC)
A page like Wikidata:Glossary is hard to translate. In my opinion it is much more important for a Swedish user here to know the English vocabulary of this project, than to learn the Swedish translation of it. Maybe it is different in a culture like the Swedish, where a lot of people prefer to read the English instructions, rather than a bad Swedish translation. And reading, writing, talking, and listening to English are four completly different tasks. I have read and listen to English daily for several years, but I almost never speak it, and I only write in English on this wiki. -- Lavallen (block) 18:37, 25 January 2013 (UTC)
This is also part of the freedom of the translator: He or she can use the english words for the translated pages, or he can choose a word in his own language. But you cant avoid to have an explanation in the translated langugage. The english words themselves have a special meaning in wikidata, so it is necessary to define very well whats the meaning of "item", "label", "alias" etc. in every language. I´ve translated some of these words to German, a very hard task indeed, you can´t just look up the words in a dictionary. Time will tell us, if the translation will survive, or if the German speaking users go back someday to the english words, which we can´t give up anyway. One thing is for sure: untranslated or badly translated pages make wikidata less accessible for users without english language skills. You can´t take for granted, that every Person that talks Swedish is also able to speak sufficient English. Pages that are translated only in parts are bilingual, which exludes all non bilingual users (e.g. every Person, that understands Swedish but doesn´t understand English but also all persons, that understand English bot not Swedish). So bilingual pages are a bad choice both ways. Intermix of languages also confuses handicapped users, who have use sreenreaders or braille displays. The availability of good translation is also critical for non-native speakers who want to contribute in an other than their native language.--Giftzwerg 88 (talk) 17:23, 28 January 2013 (UTC)
AbuseFilter
The AbuseFilter is adapted to be usable for Wikidata and it sort of works, but there are still issues so it can take some time before it can be turned on. If so then AbuseFilter is an additional functionality that is somewhat invasive for the editors. Because of that I think we should have consensus before we turn it on. If we turn it on I strongly suggest we limit the use to abusive edits, and disallow filters that only reports or blocks stylistic changes and other good faith edits. That means no filter to report or block upper-/lowercase issues, use of initial particle in descriptions, and similar things. I also strongly advice not to use private filters as all (or nearly all) filters should be public. It would also strongly advice that a project group is set up that reviews all filters, some really bad filters have gone live on some of the Wikimedia projects. In my opinion a filter that is not passing review, both on what it is supposed to do and how it does that, should not be turned on. Jeblad (talk) 13:08, 26 January 2013 (UTC)
Special:AbuseFilter is already active here, though I assume that it doesn't work with items. I personally don't see much need for it as of now, but we can look into it again when this is live on more projects and there is some actual vandalism. Ajraddatz (Talk) 14:20, 26 January 2013 (UTC)
AbuseFilter does not work for items and later properties and queries without updates. When the updates are live I think we should have some policy that says what we can and can not do with it. Personally I don't like AbuseFilter very much because I think it is to invasive and logs actions that shouldn't be logged, but that aside I think some kind of vandalism warning should be in place. Jeblad (talk) 18:33, 26 January 2013 (UTC)
There is not much need right now, but I imagine that in the future we will need it. Thus it's good to start work on it early.--Jasper Deng (talk) 20:24, 26 January 2013 (UTC)
Filters can also give interesting warns and tips in order to spread best practices among newcomers, so we could also plan a wider (and maybe smarter) use, different from simple counter-abuse.--Vituzzu (talk) 14:57, 27 January 2013 (UTC)
Eh, no. As we both know, AbuseFilter sends out warnings when the user clicks the save button and displays the warning without saving the page. However, this has the effect that the user thinks he has made an serious error that needs to be fixed asap, which is not the case when it comes to non-abusive edits. Sevreal research have been made on the effects of warnings and I do reccomend that you read them (they are available on meta). Infact posting a written message to the user would be more helpful than warning the user with the AbuseFilter. ...And if we want to go even further, then I would rather use mw:Extension:Education Program for that purpose.--Snaevar (talk) 14:17, 28 January 2013 (UTC)
The message box that will be used on Wikidata has the same form and semantics as the error box, that is a red box that gives very little indication that the user can in fact continue wit a second click on save. For 99% of the editors, good or bad, that will be interpreted as a blocked edit and they will expect a second attempt to also be blocked. Jeblad (talk) 15:27, 28 January 2013 (UTC)
Proposal: Guideline for AbuseFilter
I am proposing the following three rules as an guideline for abuse filter editors.
Abuse filters should run in "log only mode" for 4 days in order to test the filter, unless in the case of an emergency
Abuse filter editors should understand and be able to craft regular expressions
Filters that match non-abusive edits should only flag and/or tag edits.
Support with the following rationale:
1st rule: AbuseFilter is an powerful tool and can cause disruption, especially when it is not used carefully. It thus makes perfect sense to me to test filters before bringing them to full force.
2nd rule: Altrough users can make abuse filters without any regex (for example by using the variable contains_any instead of rlike) I think it is fair to expect that abuse filter editors have some knowledge about regexes.
Oppose - rule 1 may be reasonable, but rule 2 makes no sense unless we split off the role of editing filters to another separate userrights or ensure admins either know it or know to abstain from modifying abuse filters if not. Rule 3 is subjective - does "abuse" include test edits?--Jasper Deng (talk) 00:41, 27 January 2013 (UTC)
Oppose I don't think we need this, and this ignores the possibility of crosswiki filters being imported. 2 is unenforceable. --Rschen775400:48, 27 January 2013 (UTC)
Oh, au contraire. It is possible to make a test and use that to see who has knowledge about regexes and who does not.--Snaevar (talk) 21:23, 27 January 2013 (UTC)
None of the other WMF wikis do tests. Furthermore, I don't know a lot of regex, but I still set up parts of the Wikivoyage abuse filter just by importing filters from the English Wikipedia. --Rschen775423:38, 27 January 2013 (UTC)
Oppose Sometimes we might have to create a filter when there's widespread spamming/vandalism in progress, and setting an arbitrary period before we set actions would mean people will know we won't respond until after that. Techman224Talk02:32, 27 January 2013 (UTC)
To be fair, even setting up a filter which just logs would help us respond much better, but it would almost certainly be useless after the four days had passed. Ajraddatz (Talk) 03:16, 27 January 2013 (UTC)
I have changed the wording of rule 1 so that filters that are made in emergencies do not have to be tested. I agree with Ajradatz on this.--Snaevar (talk) 21:23, 27 January 2013 (UTC)
comment: On 1, AbuseFilters should be tested, and only if it is necessary they should be tested for some specific time. There is a test facility in AbuseFilter and a filter that is more complex than what can be tested with that is in my opinion not very useful, and the risk when testdriving something like that would be rather high unless of course you only log the actions. I don't think 2 really solves the problem with the complexity and risk with filters, I would like to have a review process for the filters so they are of sufficient quality when they are turned on. Do it like it is done for admin nominations, "I have made (or want to make) this filter and it works by…", nothing fancy just enforce a public process so bugs can be found before a filter goes into production. When the filter is tested, and gets a go from the community, it should log its actions and that log should be checked. The review process should not be closed before it is clear that the filter is in fact doing what it is supposed to do. If an emergency happen that need a filter it should be possible to break the rules and create a filter, but I can't see a good reason why a filter should not get through a review process afterwards. Point 3 should be something like "AbuseFilter should not be used against good-faith edits, it is for detecting and responding to vandalism." I don't see any good reason to use the AbuseFilter for detecting good-faith edits, if you are not going to take action against the users edits, why should you even log her actions as abusive? Jeblad (talk) 09:31, 27 January 2013 (UTC)
Rule 1: I am aware of the batch testing feature in AbuseFilter. However, it only tests the last 100 edits, while my experience is that the filter needs to be tested against at least 1500 edits. Rule 1 allready applies to "log only" actions. Admins are trusted to make the right desicions to protect the wiki. Having a review process for abuse filters would be a step in the wrong direction, IMO. Rule 1 was not ment to stop admins from creating filters in the case of an emergency.
Here we disagree, I think a review process is a step in the right direction. Admins are not flawless gods, so it would be better to add a process that weeds out the bugs before they go into production. Jeblad (talk) 22:14, 27 January 2013 (UTC)
Rule 3: Regarding your "AbuseFilter should not be used against good-faith edits, it is for detecting and responding to vandalism." rule, I know there is not a conseus for such an rule. There are many users that look at AbuseFilter as an EditFilter. Altrough I disagree with that I do sometimes have to negotiate.--Snaevar (talk) 21:23, 27 January 2013 (UTC)
I am veeery uncomfortable with using the AbuseFilter as a general edit filer. I think that should be NotDone™, but looking at filters at some of the Wikipedia projects it is all to clear that there are a lot of filters interfering with good faith edits. Jeblad (talk) 22:14, 27 January 2013 (UTC)
Comment sysops (which are currently allowed to edit filters) are supposed to abide by common sense. Common sense prevents from implement filters without the necessary knowledge, skills and test. So I'd say these three rules are, definitely, pleonastic.--Vituzzu (talk) 14:55, 27 January 2013 (UTC)
I agree, but if those rules calm those that think the AbuseFilter is invasive, or are uneasy becouse of it in any way, then it has served it´s purpose.--Snaevar (talk) 21:23, 27 January 2013 (UTC)
Oppose. Rule 1 ignores that there might be an urge for a fast reaction to some kind of abuse. Rule 2 would forbid regexp-ignorant admins even to edit the log function or to stop an evidently not working filter. Rule 3: There are good reasons for filters to stop or at least warn for non-abusive edits: e.g. a non-existing date or accidentally misplaced wikitext. --Seewolf (talk) 23:51, 27 January 2013 (UTC)
Oppose per above. I don't believe AbuseFilter can be limited to only some languages on a wiki, so these would go for all languages. As was mentioned before, administrators can edit these abuse filters, so proposal 2 suggests that, at present, all administrators would be required to learn about the syntax. Hazard-SJ ✈ 04:31, 30 January 2013 (UTC)
A first draft of an external tool to output Wikidata content in RDF
I've written this week-end a beginning of RDF output of the Wikidata content using common used vocabularies (RDFS, FOAF, Dublin Core, SKOS...). It supports all phase 1 features except aliases and I'm working to support phase 2 properties and statements. Here is some example of request that can be done: Q1 and Q2 in RDF/XML, enwiki:Mars in HTML with only fr, de, en and it languages. The URI of items provided are based on the URI scheme note and URIs of the custom classes used are silly and will change in the future. The source code and some documentation is is available in github. Tpt (talk) 21:02, 28 January 2013 (UTC)
Creating a Redirect
I have been working through the hu:WP import task force Global items.
In doing this I have come accross many cases where two wikidata pages describe the same item. Where there aren't too many sitelinks I have merged these duplicate pages by deleting from one page and adding to the other then I have nominated one of the pages for deletion with the rationale "merged to Q????"
In discussions on bugzilla about the merge function I have been reminded that, after a merge, we should redirect the 'merge from' page so that it's url still works. I hope I haven't broken any URLs till now but in future, now that the sitelinks are live on hu:WP, we need to do this.
It isn't possible to create a Redirect yet but this feature will be added in the next stage. I am talking about marking pages that need a Redirect in a standard way so they can easily be converted to Redirects later. Thinking about it I think the Redirect to Q???? statement should probably go in the Description rather than the Label. The Label should show what page was about before. This way you won't get pages with exact duplicate Labels+Descriptions. Filceolaire (talk) 16:27, 30 January 2013 (UTC)
I make this script to help to repurpose an item. You can choose between many option like delete all labels and/or all descriptions and/or all aliases and/or all sitelinks.
A verification code is required to prevent vandalisms.
Patroller and Sysop can delete all labels, descriptions and all aliases but only sysop can delete all sitelinks.
Be carefull sietlinks can be once on wikidata.
How to use :
Only people who have patrol right can see this gadget on the preference.
If someone wants help me to translate this script go to the talk page here.
I don't see the point of this gadget as we don't want to have items repurposed. Could you please point that out? IMO we should gather some consensus before enabling new gadgets without any code review etc. We're a quite new community and we got the manpower to actually do this. - Hoo man (talk) 22:46, 28 January 2013 (UTC)
I am on the side of Hoo man, it would be nice to have a tool to edit multiple labels/describtions at once without changing to all languages. This means you could also use this tool to remove the labels but I don't think we should use a tool to only delete labels. And I am definitely against reusing items, this only leads to big problems in the future. --Sk!d (talk) 22:57, 28 January 2013 (UTC):I am against reusing items, but am open to a tool that would allow easy modification of other languages.--Jasper Deng (talk) 00:23, 29 January 2013 (UTC)
@hoo man sorry i dont know that a a consensus was required before adding a gadget. Secondly the point of this gadget is that a personn who create an item but the site links is already taken but a description or a label was put. This gadget allows you to delete this data to reuse this item. Thanks for your point of view ^^. I will think to make some consensus next time. --Jitrixis (talk) 15:12, 29 January 2013 (UTC)
Hi! I have some pretty technical questions about the phase 2 (infobox data) of the Wikidata project, I've posted them here in order to allow all members of the community to see answer to these questions.
Is it possible to add statements to property? I see 3 statements that would be nice to have on property pages:
isDepreciated: a boolean that inform the user (and the property selector in the statement creation UI) that the property is depreciated and should not be added to items (this usecase will, I think, of course happen in Wikidata life)
propertyOf: the item related to the property. By example the property ISBN is the propertyOf Q33057. This will help users to get information about the property and make, I believe, Wikibase a little bit more into linked data spirit.
sameAs: URI of the "same" property in an RDF vocabulary. By example, the property ISBN is sameAs http://schema.org/isbn . This will, I hope, help to create an external API that output Wikdata data in some RDF vocabularies (Dublin Core, FOAF, Schema.org...)
Is it technically possible to install, when the phase 2 will be deployed, the Wikibase client to Wikisource and Wikimedia Commons, even if links to these wikis are not supported by Wikidata, in order to allow them to use the #property parser function (and the Lua API) ? This would be very useful, by example, for Creator pages of Commons (example) that contains already the ids of the related Wikidata items.
Is it possible to add a section to item view (or create a special page) to get items linked by a statement to the current item. It would be very useful, I think, for navigation inside of Wikidata. A parser function (or a method in Lua API) that returns such list would be also an amazing thing, in order to don't have to create a query page for a so simple query that, would be, I think, used a lot.
Will InstanceOf and SubclassOf snak types be added to Wikidata statements system at the same time as the property snak type or after?
About statements, how to make an AND relation using current data model? By example I want to add to Wikidata that Bod AND John are the writer of the book. With the current interface (Wikibase trunk of the 25th January), I can create a statement with the author property, select Bob's item, save, create a new statement with the same property, select John's item,and save. But with that, if I have well understand the Data model, I'll have something like a flat OR relation.
About identifier like VIAF and ISBN, I understood from some conversations last year that these identifiers will be maybe added to items using statements (that is, I believe, a good solution, because a lot of books have more than one ISBN, a lot of people have more than one VIAF id, there is one ISNI id for each pseudonym of the same writer...). In that case, It would be nice to have a custom generic DataType that will allow to validate the identifier form a regex and to have in the interface (and in APIs) the URI related to the identifier build from a pattern set in the property page. I would also love to have some custom datatypes for very important identifiers like ISBN that will manage validation of the identifiers with computing of the checksum, normalization to ISBN 13 without spaces and "-"... If a member of the Wikibase team explains me how to add such data types into DataValues extension, I'm volunteer to do it.
It is planned to add claims to properties. Not full-fledged statements (i.e. they won't have references), but we plan for claims.
Yes, we are planning for that. They might be some unexpected things, but in general we aim for that.
We are planning to support that functionality via query pages, but not as a section in the item view.
It is currently not high on our priority list.
It is always supposed to be an AND relationship. "The population of X is 10,000 according to Z and 20,000 according to Y." Always conjunctive.
Yes, this is planned. Rather sooner than later. And let's talk on IRC how you can help us make it even earlier :) --Denny (talk) 17:03, 31 January 2013 (UTC)
Thanks for these answers. The Wikisource community is very interested by Wikidata and will be very happy if the phase 2 features are made available in the Wikisources at the same time as in the Wikipedias, even if links to Wikisource aren't supported at this time. Tpt (talk) 20:49, 31 January 2013 (UTC)
1. All useful but I think the propertyOf name could be misleading. What about WikidataEntity instead?
I think a seeAlso field could also be useful, listing other similar Properties. This would help editors find the property which is the best fit for their use case when there are a number of similar properties.
3. Is this a "what items use this property" tool or have I misunderstood your comment?
6. At present there don't seem to be any Property pages on wikidata (pages with P#### references). Creating the Property page for VIAF or for all the personendata fields would seem to be a good start. When do the devs think this is likely to happen? Filceolaire (talk) 20:33, 26 January 2013 (UTC)
1. I don't think that "wikidataEntity" is a good idea because:
1. in the Wikidata glossary an "entity" if defined as an entry in the Wikidata database (currently an item or a property). So "wikidataItem" would be better.
2. "wikidataEntity" describe the linked thing, a Wikidata entity, and not the relation, that the property is the property entry in the Wikidata database that is the closest to a specific item.
3. No, I want to talk about of a "what items are linked by Property PXXX to the item".
6. This will be done when the phase 2 will be finished and deployed.
I apologize if this message is not in your language. Please help translate it.
Do you have an idea for a project to improve this community or website?
Do you think you could complete your idea if only you had some funding?
Do you want to help other people turn their ideas into project plans or grant proposals?
Please join us in the IdeaLab, an incubator for project ideas and Individual Engagement Grant proposals.
The Wikimedia Foundation is seeking new ideas and proposals for Individual Engagement Grants. These grants fund individuals or small groups to complete projects that help improve this community. If interested, please submit a completed proposal by February 15, 2013. Please visit https://meta.wikimedia.org/wiki/Grants:IEG for more information.
For me the templates links to /01. I already told the botowner to change his bot so it will no autoarchive to /01, /02 etc. --Sk!d (talk) 20:15, 31 January 2013 (UTC)
Done. Any other wishes? --Bene* talk 19:15, 5 January 2013 (UTC)
Oppose A category is not an article. --Spischot (talk) 08:06, 4 January 2013 (UTC)
Please note that there is no consensus to add only articles. We have categories here AFAIK. Hazard-SJ ✈ 01:20, 6 January 2013 (UTC)
Neutral It'd be useful, but as Spischot stated, a cat isn't a page. However, we do need to include the Commons somewhere. --Rsrikanth05 (talk) 10:54, 4 January 2013 (UTC)
Support Wikidata was never meant to be limited to just the interwiki links. The ambition is that it provide a repository of data that can be used in various ways. Links to galleries of pictures associated with an item would certainly fit that model. Let's not close off possibilities unneccessarily. Filceolaire (talk) 09:50, 7 January 2013 (UTC)
I do think that we need to have a discussion with Hebrew and Italian Wikipedia about the interwiki bots issue; I've started one on the English Wikipedia, but that's step 3. --Rschen7754 03:50, 15 January 2013 (UTC)
Question - Are you proposing these as guidlines for the whole of Wikidata, or only for the English part? -- Lavallen (talk) 16:32, 12 January 2013 (UTC)
Support with the following rationale:
