Wikidata:Project chat

From Wikidata
Jump to: navigation, search
Shortcut: WD:PC
Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Requests for deletions and mergers can be made here.

IRC channel: #wikidata connect
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at October.

Move sitelink?[edit]

I have not been working on Wikidata for a while. Before, I could move a sitelink easily from item to item with the 'move' tool (an extra option when editing the sitelinks). In my preferences the option to have this 'tool' is still active. But now all sitelinks have a common edit field and for all sitelinks I can only type a new link or choose remove. Of course there is also the Merge tool but what if I want to only move part of the links? Bever (talk) 03:30, 7 October 2014 (UTC)

The UI changed a few days ago (e.g. you're able to edit multiple sitelinks at once). This broke the Move gadget (see MediaWiki talk:Gadget-Move.js#Doesn't work anymore with new UI), and nobody has fixed it yet or cared too much about it otherwise (e.g. proposing new ways to include it into the new UI). I'm not sure actually whether this would be a minor adjustment to the new layout or if some serious problems would have to be solved to re-activate it. --YMS (talk) 09:07, 7 October 2014 (UTC)
A few days ago? What a coincidence... I noticed the change and have some more troubles with it:
  • when I want to change labels or descriptions for languages in my babel box, now an extra mouse click is needed ('Edit' above the first box).
  • several times when I tried to change several labels and/or descriptions and/or aliases at once, I got an error message ('bewerkingsconflict', probably 'edit conflict' in English), it appeared that one change was effected but another was not. Bever (talk) 01:22, 10 October 2014 (UTC)

Is there a place read by the developers where such problems can be dropped? In the meantime I would prefer to use the old interface. The advantage of the new model would be that you have to click at 'save' only once after making several changes, which would outweigh the extra click on 'edit', but as I said, often it does not work. Bever (talk) 00:52, 14 October 2014 (UTC)

We're reading here ;-) There is also Wikidata:Contact the development team. We're working on improving the interface changes we made at the moment. As for the move gadget: Best check the talk page of the gadget and talk to the person who wrote it. --Lydia Pintscher (WMDE) (talk) 07:07, 14 October 2014 (UTC)
I (the creator of the gadget) thought that moving it into Wikibase itself will be much easier than having to create another hack to inject all the [move] buttons. Therefore I created bugzilla:72019. -- Bene* talk 07:47, 14 October 2014 (UTC)
Thank you both. I would like to point out that the move gadget is not only useful for people who want to move sitelinks. It is also advantageous for people who want to check the changes on the items on their watchlist. The gadget leaves an edit comment with a link to the new item. If sitelinks have been moved 'manually', you don't see why they disappeared on the old items.
Last week, when I wanted to move 2 links, I forgot to press 'save' when deleting the links on the old item. Therefore adding them on the new item resulted in an error. I spent 10-15 minutes in new tries. Bever (talk) 07:23, 21 October 2014 (UTC)
On Bugzilla (where I cannot edit, as I am not registered there), John F. Lewis replied to Bene's proposal with 'In the core as a feature - yeah but likely to be obsoleted by plain merging?' I do not know what 'plain merging' is, but between the 'merge' tool and the 'move' tool there is a big difference. With merge, you move all information (all sitelinks, properties, labels etc.) to another item. With the move tool, you can move 1 sitelink if it is just placed on the wrong item, leaving the rest of the item as it is. Bever (talk) 06:08, 25 October 2014 (UTC)

What to do when British English is used in title or description?[edit]

I'm not sure what the correct way to handle British English versus American English in the title and description areas. In at least two cases I have come across British English in a title or description, but there is a separate area for British English, which would imply that American English should be used in the title and desc areas. I know on en wiki it's sort of "whoever gets there first", but I'm not sure of the policy here.

First case was where I encountered this was the description for 2014 FIFA World Cup (Q79859); it was originally described as a football competition, but I changed it to soccer and moved the football description to the British English area.

This second case, however, is the case of Harry Potter and the Philosopher's Stone (Q43361). It was published in American English as 'Harry Potter and the Sorcerer's Stone'; and this is included in the "also known as" section. As the original title was in fact Sorcerer's Stone, I feel it's improper to change it to the American English version. However, I feel as though including the American English title in the "also known as" section isn't as semantically clear.

I think the most clear way to do this is to have a separate "American English" section in the language section, and that way it is unambiguous. But that doesn't exist yet! Thoughts? Mvolz (talk) 22:51, 18 October 2014 (UTC)

@Mvolz: I don't think that the English label on Wikidata should be understood as US-English, but as international English. I think only Canadians and US-Americans say soccer, versus all other English speaking countries and all the countries that have English as a second language call it football. In case it doesn't exist, we should probably think about a US-English language field for these cases. -Tobias1984 (talk) 15:34, 19 October 2014 (UTC)
We should either support en-US or (more sensibly) drop en-GB & other en-XX variants. There are very few cases where this is actually a net positive. Andrew Gray (talk) 16:27, 19 October 2014 (UTC)
The en-xx are a style that should not be applied in the Q: namespace, though maybe the Property: namespace is okay, though pretty much irrelevant, and in truth a fallacy, especially when there is also en-au, en-nz, etc. and there is no clear divide between then anyway (all wasted space stuff).

What I do find weird, and I left comment elsewhere is with something like birth name (monolingual text) (P1477) where something in English is English, you cannot have the nonsense of variations.  — billinghurst sDrewth 03:54, 20 October 2014 (UTC)

I believe there is a need to distinguish US-english from British-english in some occations to avoid confusion ("football" is a very good example). The same need probably exists for Brazilian vs. Portugese portugese. As a matter of fact we do distinguish between Nynorsk (Q25164) (nn) and Bokmål (Q25167) (nb). /ℇsquilo 12:35, 20 October 2014 (UTC)
No it isn't. In Australia there are five types of football — Australian Rules, Rugby League, Rugby Union, Soccer, Gridiron; and all played by footballers — and depending your state and persuasion will depend on which is your priority football, oh and Rugby Sevens. Then take New Zealand, South Africa, Samoa, Fiji, Papua New Guinea, where else would you like that don't have their own variations of en-xx. False realities. Cover all bases, and make sure that your explanations cover it.  — billinghurst sDrewth 13:13, 20 October 2014 (UTC)
A property to indicate en-US, en-BR, en-CA, en-AU, en-NZ (is there also an en-India?) is valuable, but what name is used for the namespace is unimportant and can be in any flavor of English. If there is a subject that is native to one flavor, that is the one that should be used, but otherwise it is really just arbitrary. 04:52, 21 October 2014 (UTC)
For football, the full name 'association football' could be used to avoid confusion. ('Soccer' would be a bad choice because this word is mostly used in countries where it isn't the favourite sport.) Of course 'en' should apply to all main variants of English. Bever (talk) 07:32, 21 October 2014 (UTC)
If the english speaking world can agree on one acceptable name for association football (Q2736) that is all good and well. However, the need still exists for other words and other languages, particurlarly Brazilian vs. Portugese portugese. Should maritime pilot (Q475604) be named prático or piloto and should aviator (Q2095549) be named piloto or aviador? /ℇsquilo 06:41, 23 October 2014 (UTC)
Once again, the name is not particularly important - what is on the page is what is important, and a clear description. English Wikipedia frankly just lets whoever creates the page first use their flavor of English (and perhaps because there is a 5-8 hour time advantage, a relative majority are in en-BR). If Portuguese also has different variations, pt-PT, pt-BR, pt-somewhere else, it would, just like the flavors of english be useful to have a property that says "in pt-PT", or "in pt-BR" if the name used was in the other of those two variations. Chinese has resolved this issue by having different wikipedias for each, because the character set is different, but English and other languages (most others?) have chosen to avoid that unnecessary duplication, instead noting in each article the en-US, en-BR, en-AU spelling. 19:04, 23 October 2014 (UTC)

Item Left (Q3556716) for disambiguation pages[edit]

What should I do with this 'disamb' page. In my opinion this disamb page is not correct and should be splitted into 12 or so different disamb pages with only identical names. (And p461 should not be on a disamb page). Is that ok? Michiel1972 (talk) 23:14, 20 October 2014 (UTC)

It looks fine to me. A wikipedia page is a concept, and if the concept is the same in a different language, then it does not matter what it is called in that language. It is a little bit odd to have something be the opposite of a disambiguation page, but what they did is choose the disambiguation page that is for the opposite of the subject that is being distinguished. 06:27, 21 October 2014 (UTC)
In my opinion, we should definitely split this item. The linked disam pages do not only deal with the direction but also with music albums called "Left", people with last name "Links" or "Ezkerra" or a wind with name شمال (north) --Pasleim (talk) 07:50, 21 October 2014 (UTC)
Yes, it should be splitted, but there should be a way to present all this similar disambiguation pages (or a link to a list of them), near to the "Languages" list on the sidebars of all this disambiguation pages to the Wikipedia readers. Maybe the Wikidata items should populate a item group for Translations of Left. --Diwas (talk) 11:34, 21 October 2014 (UTC)
Surely you are joking. That is what a "disambiguation" page is. Disambiguation is not just a big word that means "put a squiggly fork template here". It means "this title has more than one use in this language", and the fact that it means different collections of things in different languages is completely irrelevant. 13:50, 21 October 2014 (UTC)
The fork list (of items) should not be putted on the disambiguation pages, but (as one? link) near to the languages list. A (link to a) list of some discrete items, but not a mess on disambiguation pages and not a mess in one item. --Diwas (talk) 23:16, 21 October 2014 (UTC)
IMHO Wikidata:WikiProject Disambiguation pages/guidelines is too strict, but still this is an example of a disambiguation page that should be split. Lymantria (talk) 15:15, 21 October 2014 (UTC)
Speaking of "too strict", why is this a requirement? "The item should only contain links to Wikipedia disambiguation pages with the exact same spelling" How can we dictate what each Wikipedia wants to put on their disambiguation page? Why should we exclude one just because they think it is important to add items that are not spelled exactly the same? 16:31, 21 October 2014 (UTC)
For me, it is too strict too, but the same spelling is not a requirement for each listet element of the disambiguation page, but only for the title of the disambiguation page. But we will never get consensus for each grade of variance, if it should be splittet or not. And (maybe in the future) one language version will contain two disambiguation pages for two different spellings, and then the previous one item will going to be splitted. Then it will be helpful to have a short fork list of this two different but similar items. --Diwas (talk) 23:54, 21 October 2014 (UTC)
I must not be understanding what you are saying. To use the Left page as an example, it is very likely only spelled "Left" in English. There is a br dis page, but it was not Kleiz, but Kleiz (disheñvelout), and that has been corrected. Since many languages are sensitive to variables, the fact that the de page includes both Links and Linke or that the el page uses αριστερά and Αριστεράς disqualifying them from being called a dis page here is absurd, and obviously that guideline needs to be revised, as it is pathetically false that all of the things listed have to be spelled the same as in the title of the disambiguation page. 21:02, 22 October 2014 (UTC)
Yes is necessary to split item --ValterVB (talk) 18:03, 21 October 2014 (UTC) ps brwiki isn't a disambiguation page.
The Wikipedias tend to describe different variants or aspects of the general concept of 'left' (or izquierda, or whatever) in separate articles. Like political left, left-handedness etc. Hence the majority of articles which are mentioned on these disambiguation pages are for different aspects of the same. Is Bretonic the only language to have an article on the general concept at all? There is a good reason to link these pages, such links are helpful for readers interested in other languages.
Although there is a 'guideline' which suggests that this item should be split, why should this guideline be implemented in every case? What is the harm if we leave it as it is, as long as there are no interwiki conflicts? Bever (talk) 01:17, 22 October 2014 (UTC)
Disambiguation pages either can be aggregated by label or by concept. Most of them are by label, but in this case the label is so close to the concept that it might make sense to leave it like that. Some exceptions are needed to make a rule, right? :) --Micru (talk) 08:52, 22 October 2014 (UTC)
Pages like br:Kleiz are a good reason to have an additional way to link similar but different items. We should not mix it with disambiguation pages in the disambiguation pages item, but should give it an own item and link that in an item (one level higher) for pages (lists, disambiguation pages, articles) about the general concept. --Diwas (talk) 12:30, 22 October 2014 (UTC)
br:Kleiz was not a dis page, but was a page that describes left and several other uses of Kleiz. A disambiguation page can not have any content other than a minimal description. Once content is added, it is a page about that content and no longer a disambiguation page. It was removed and placed in the left (position) page, and replaced with the br:Kleiz (disheñvelout) page, which is a dis page. 21:59, 22 October 2014 (UTC)
I would agree with keeping this item unsplit if only the "concept" left gave reason to make the disambiguation. But now both spelling (e.g.: German and Dutch have a browser "Links" among their linked pages) and concept do and that does make it messy. Now we have to make a decision: Merge Links (Q11984152) into Left (Q3556716)? How about Sinister (Q10668323), because of the Latin link, or even Left (Q10316880)? To solve this mess splitting is needed. Lymantria (talk) 17:03, 22 October 2014 (UTC)
I have split the item.--GZWDer (talk) 05:50, 23 October 2014 (UTC)
That was a bit pre-mature, and pretty odd to only have the criteria that everything on the page use the same spelling as the English word "Left". What you ended up with is linking two disambiguation pages that have no pages in common with each other. And a dozen disambiguation pages for left that have no indication that there is an English disambiguation page for left. If you are going to "split" it how about start by removing the only page that you left - the one that has nothing to do with left? Wikidata pages refer to meaning, not spelling. The word gift in Swedish means poison, you can not link it to a disambiguation page for the english word gift, for example, just because it is spelled the same. And you linked the fr entry with en Gauche, even though the two dis pages have no links about the same subject. Ditto for la - you just linked to the English dis word for Sinister because they are spelled the same and the two dis pages have no links in common. It is always only meaning that causes a link, never spelling. I suggest just reverting all of your edits and starting over in a more meaningful manner. I am beginning to see how someone would say that the new wikidata links are useless when people make choices like this in grouping pages. The inherent problem is that the old way only native speakers were dictating where links were going, here someone who knows nothing about the language is deciding. Looking at the table I see none of these that need to be removed. 08:38, 23 October 2014 (UTC)
Language Page Link1 Link2 Link3 Link4 Link5 Link6
ar ‎(يسار (توضيح left (direction) Left-wing politics Suleiman ibn Yasar
br Kleiz (disheñvelout) left (direction) chalk
de Links left and right (directions) left (politics) link(computer hyperlink) Links (web browser) golf course (links) people and companies named link
el Αριστερά left (politics) left (direction)
en Left left (direction) Left (album) left (politics) Left (Marxist)
es Izquierda (desambiguación) many political parties left (direction) left handed left hand rule
eu Ezkerra (argipena) surname left (politics) left (direction) left handed
fa چپ left handed left (politics) political party
fr Gauche left (politics) political party political movement metallurgy (a "left" is a piece that is twisted) clumsy left (direction)
he שמאל left (direction) left handed left (politics) Left Hand of Darkness (book) wind from the left
ja レフト left fielder (baseball) a volleyball term left (politics)
la Sinister German political party Italian political party
lb Lénks left (direction) left (politics) homosexual
nl Links left (direction) left (politics) left handed Links (film) Links (web browser)
ro Stânga left (direction) left (politics) political party left handed copyleft (a PD form of copyright)
zh left (direction) left (politics) surname copyleft

Since there are no interwiki conflicts I would merge de/nl/lb as one item and eu/es/el as another. --Diwas (talk) 23:37, 23 October 2014 (UTC)

My idea and reason is at User talk:YMS#Disambiguation page, and Wikidata:Project_chat/Archive/2013/11#Disambig_page_link.--GZWDer (talk) 10:01, 23 October 2014 (UTC)
That is a ridiculous idea. When we link wikidata pages for pages we link everything that has the same meaning. We do not link en:Gift with sv:Gift, because the words have different meanings. In Swedish Gift means poison. So we link en:Poison with sv:Gift. What we have to do is look at how the word is used on the disambiguation page, and link it to another disambiguation page with the same meaning. For example left, in English is a direction, but that same direction is called Gauche in French, so we link the en:Left dis page to the fr:Gauche page. It is meaningless to link the en:Gauche dis page to the fr:Gauche page, because none of the pages on either dis page are about the same subjects. In English, Gauche has a very different meaning than "left". When the disambiguation page guidelines talk about the same identical spelling, they mean on the wikipedia disambiguation page, so for example by our guideline, which is also absurd, we could not have any link at all to en:Left as per our guideline it is not a disambiguation page, because it includes items that are not spelled "Left", but instead includes "Left-wing politics". That is why that strict requirement is absurd. It does not mean that every item on the wikidata page has to be spelled the same in every language, which is even more absurd, but that is exactly what you have done. 10:37, 23 October 2014 (UTC)
FYI, it is possible from reading the discussion page that adopted that guideline, that is what the guideline says, and it was adopted with near unanimous support, with the comment, "IMO all articles on a one item have to be the same title. E.g. English disambiguation site "Yellow" should be Yellow in other wikis too, not translated name." That of course is ludicrous, as you can not tell someone that their disambiguation page for the color yellow can not be linked to every other disambiguation page for the color yellow, but you have to only link your disambiguation page for the color yellow for disambiguation pages in other languages that use a word that is spelled using the latin characters "Y E L L O W" even if that word has a totally different meaning in that language, such as, "a bath tub stopper". That idiocy has just been done in splitting this page, where "gauche" has been linked from the en word gauche to the fr word gauche, and since the word in English does not mean the same thing in English as it does in French, none of the links on the en page are the same as any of the links on the fr page. Another example is in Swedish "gift" means poison, so if that guideline was followed, a disambiguation page for sv "poison" would be linked to an en "gift" page, once again obviously with no links in common. Another preposterous statement appears in the discussion - "i. e., how can we tell which pages deal with the same item?" Why is that even a question? See the table above. There were some items on the linked pages that I could not identify because they go to red links, but it was not hard to generate the able and see what the links were. Just as a wikidata page for "Yellow Brick Road (song by Eminem)" is only going to have links to other language articles about that same subject, a wikitable page for the disambiguation page for "Yellow Brick Road" is going to have link to other disambiguation pages about the road in the Wizard of Oz, which of course has different translations in different language, as indicated on Yellow brick road (Q3444039), which right now has only 3 entries. And none of the others use the words "yellow brick road". But if there was a disambiguation page for any of them, they should all be linked to the other disambiguation pages. Right now Wikipedia is really only in English and a few other languages, and has not been "built out" into most of the other languages of the world, but when it does, the purpose of wikidata is to link all of the pages that are about the same subject, not pages that use the same spelling, which would be nonsense.
So instead of making hash of things, such as was done for the perfectly good page of "left as a direction or political direction disambiguation page" (fortunately some of the local wikis still use local interwiki links and not the totally useless links that are now provided), and making it into a "page of disambiguation pages on wikis that use a word that is spelled "left" using only latin characters with special characters such as accents or that are pronounced like the English word "left" but use characters that have a similar pronunciation, which is totally useless to anyone, as it is going to for most languages inherently going to be only a wikidata link to itself, totally making the entire wikidata project useless for any wikipedia disambiguation pages, I would suggest putting an immediate hold on implementing that aspect of the guideline, as it is sheer nonsense. 18:31, 23 October 2014 (UTC)
Yellow isn't «a disambiguation page for the color yellow» but a disambiguation page for the word Yellow. In disambiguation page you can found a movie of Cassavetas, a single of Coldplay, a manga of Makoto Tateno and in English also the color yellow. This is the use of disambiguation pages, if you join page with the same meaning you have a list that is another thing. --ValterVB (talk) 19:40, 23 October 2014 (UTC)
That is not useful. We always only have pages that are based on meaning, not on spelling, why would disambiguation be any different? How is it useful to line en:gift with sv:poison just because the word for "poison" is spelled "g-i-f-t" in Swedish? This is sheer stupidity to link disambiguation pages differently than every other type of page. 20:33, 23 October 2014 (UTC)
Disambiguation must be different because are very special pages, They have specific category, specific template and mediawiki software manage they with specific "magic word", there are some SPecial page like Special:DisambiguationPageLinks or Special:DisambiguationPages. They are necessary to guide user to the correct page. If I search Left I want something called Left, not something called Stânga so with disambiguation page I can select the page that I want. --ValterVB (talk) 21:03, 23 October 2014 (UTC)
Fortunately most of the disambiguation pages I have seen do not follow that absurdity, but instead in fact do use the meaning. For example, the disambiguation page for ja:yellow does not use one named "yellow", but instead groups all of the other uses of the color yellow, which in japanese is called "黄色", and by the guideline would not be included on the color yellow disambiguation page but would be on its own page, and be totally useless (a wikidata page is only useful if there is more than one wikipedia link on it). 20:56, 23 October 2014 (UTC)
Wikidata isn't only for Wikipedia projects. For no-latin alphabet, transcription is acceptable if don't exist the same word, but if exist we must link this (ex. A10 (Q228260) the japanese link is A10 in latin alphabet). --ValterVB (talk) 21:19, 23 October 2014 (UTC)
That does not address the issue that translations are important to use, and are much more important to use than either literal spelling (see the example of gift/poison) or transcription. For example, if some other language used a transcription of gift, but the same meaning as in Swedish, poison, instead of something that is given, it is not useful - the principle being that only meanings are important, never spelling. 02:02, 24 October 2014 (UTC)
Your principle that spelling is never important is not widespread in this community, as you can see by the accepted guideline on disambiguation pages. The problem with disambiguation pages and meanings/translations is that, per se, disambiguation pages cover homonyms in a language, of which often it is not clear what the "leading meaning" is. The set of homonyms differs from language to language. Therefore the wikidata-community chose to make spelling important in case of disambiguation pages. And it certainly turns out to be useful. Lymantria (talk) 11:38, 24 October 2014 (UTC)
Yes spelling can be important - but only for proper names. All that avoiding translations does is create Wikidata pages with only one entry, and when there are more than one, such as Left now, those two entries have nothing to do with each other (the Hebrew word for left has now been added, which of course is a violation of the guideline, unless it is pronounced "left"). Ditto for Gauche, which has been linked between fr and en, but since the words have different meanings, there are no pages on either dis page that are in common. Normally when you go to a disambiguation page, you find a list of the subjects that have a corresponding article in every language, which was how everyone created local interwiki links. Now we have en:gift dis linked to no:gift dis, but in Norwegian, "gift" means "poison", so the link is useless. The fact that other Homonyms exist in each language is simply not important. There can only be one Wikidata page for every page, so you just have to choose which page you are going to link it to (in de left is Links, so you can either make a link to a Wikidata page on people named Links, or the direction left, but not both), but you certainly are never going to link en:gauche with fr:gauche, or en:gift with no:gift, because they have different meanings in those languages. When you do look at the Wikidata pages for disambiguation pages, you will see that almost none of them follow the guideline, and instead use the translations to make the links. "Fixing" them, would be a disaster. 01:54, 25 October 2014 (UTC)
I would actually call it a flaw of Wikidata that you can not link to more than one page, because with local links you can, and of course if they are needed, local links can still be used, to avoid that limitation. These are the interwiki links that the German Links disambiguation page used, prior to migrating to Wikidata, and they link to the word in some languages meaning left, venstre, but include a link to the English page Venstre, which of course means neither left nor Links. 02:39, 25 October 2014 (UTC)
Of these I would call the en, es, fr, and it links incorrect, because none of the political parties on those pages are on the de:Links dis page. 02:39, 25 October 2014 (UTC)
FYI the idiocy of linking en:gift with no:gift (poison) predates Wikidata, and was placed on the en page in 2007. I am not particularly surprised that no one noticed the error, though. 02:54, 25 October 2014 (UTC)
I think the criticism of is a good incentive to rethink some concepts on Wikidata and Wikipedia. Although disambiguation pages are primarily a tool for navigation when a user uses the search box, meanings do play a role when grouping links and information on them. The present guideline is too one-sided when ruling out this aspect.
On Wikipedia, I sometimes feel that the idea that disambiguation pages must not give any information (other than links) is in some cases too strict. It seems also that different versions of Wikipedia (and other Wikimedia projects) have different guidelines or practices regarding disambiguation pages, which can cause problems on Wikidata (interwiki conflicts). also points at the reduction of useful interwiki links since the roll-out of Wikidata, which is not always in the interest of the end-user. In my opinion this is caused by some inherent conflicts in Wikidata, but they might be solvable. Bever (talk) 03:54, 25 October 2014 (UTC)

Disambiguation pages are simply lists of "things known as X". As such, they should only be linked to similar lists of things called X on other language projects, not to pages with one arbitrarily chosen translation out of many of "X". These pages are about that particular string of letters (e.g. "l-e-f-t"), not about the meaning(s) behind it. Many, many words have several equally viable translations in other languages, so we're not looking at 1:1 relationships, but in most cases at 1:n or even n:n. Arbitrarily chosing just one translation might be a simple solution, but as it's often the case with simple solutions, this doesn't really work all that well, neither from an encyclopedic nor from a technical standpoint. The current guidelines are much better than what we had before, when interwiki links on disambiguation pages were changed from one translation to the other and back all the time and whole groups of interwiki links were moved between disambig pages because one person preferred one translation from language 1 to language 2 over another, which in turn influenced translations between language 2 and language 3 and so on... -- 10:55, 25 October 2014 (UTC)

You know, many things can have several names, and these names often are some variations of the one one (e.g. synonims, or translations). So a list of "things known as X" easily can be a list of "things known as <translation of X>" in other language. --Infovarius (talk) 13:55, 25 October 2014 (UTC)
I don't really agree. That only really works to some degree if you only consider translations between two languages. Choosing one translation each of "X" from English into German ("Y") and French ("Z") for example, doesn't mean that "Y" and "Z" are also valid translations of each other. So translated interwiki links that might be somewhat valid on one language project could be mostly wrong in other languages. That's what we had in the past and it led to neverending changes of interwiki links because editors in other languages were constantly unhappy with the translations between the languages they knew, which in turn caused problems with the translation between other languages, and so on...
As I said above, those things known as "X" often have several equally valid translations in other languages. And each of those translations might have its own disambiguation page. E.g. en:Sphere (disambiguation): each of the things listed on that page could be translated as de:Kugel (Begriffsklärung) or de:Sphäre (Begriffsklärung). And in some cases (like works of art), the same name is used, so de:Sphere. And de:Kugel (Begriffsklärung) in turn could be translated as en:Sphere (disambiguation) or en:Ball (disambiguation). Or, depending on the context, even en:Kugel (disambiguation) or en:Bullet (disambiguation). And en:Ball (disambiguation) could be translated as either de:Ball (Begriffsklärung) or de:Kugel (Begriffsklärung). And so on... And that's just two languages. But we have to handle dozens of languages. There's simply no way to pick and choose just one translation out of several for each pair of languages and still maintain a matrix of valid translations between each and every language. Not to mention what happens when you have a disambig page title that's already taken from another language, e.g. en:Clair de Lune, en:Mondschein and en:Moonlight (disambiguation). -- 09:54, 26 October 2014 (UTC)
And all pages are simply links to "things known as X", where X uses different character sets and different characters in each language, for whatever the translation of X is in that language. Disambiguation pages are no different, with the exception that they also include items that are spelled that way in that language. But the only time that different language wikis can be linked to each other is if the meaning is the same on each page, not the spelling. Otherwise you inherently have only one or two links for every page, and 200 other pages that have that same meaning that are not linked to each other - but worse, you link words that are spelled the same but have different meanings, like en gauche with the french word for left, and the en word for gift with the no word for poison. Sure there are different thinks called Link, both in en and in de, but the de page is primarily for things meaning "left", not things named Link. We can always only have one wikidata page for each wikipedia page. Where there are more than one things you want to include, the advice is to merge the two wikidata pages, not split them. 02:44, 26 October 2014 (UTC)
You seem to confuse articles and disambiguation pages. Disambiguation pages are _not_ about a single primary meaning of a string of letters, that's what the articles are for. Interwiki links on articles are of course translated as the exact same thing often has different names in different languages. But disambiguation pages are strictly about things known by this specific string of letters, not about things named after the string of letter's primary meaning. So en:Yellow (disambiguation) is a list of things known as "y-e-l-l-o-w", but not necessarily a "list of things named after the color yellow". That's why it's linked to other lists of things known as "y-e-l-l-o-w" in other languages, not to things named after the local translations of the name of the color. Just like you wouldn't link a list of people with the surname Miller on the English Wikipedia to a German list of people with the surname Müller and a French list of people with the surname Meunier just because that's the literal translation of Miller. Interwiki links are for linking pages about the exact same thing on other projects. But a list of things called Gelb is not the same as a list of things called Yellow or Jaune or Amarillo. -- 09:54, 26 October 2014 (UTC)
The only time that different language wiki pages can be linked to each other is if the meaning is the same on each page, but the meaning of a disambiguation page is just the spelling of a simple search term. --Diwas (talk) 10:29, 26 October 2014 (UTC)
They link other items that are spelled the same because they have the same meaning, and because they have the same spelling. The en wiki dis page for Müller would have the same people on it as the fr, and de dis pages, because they are the same, and the pages for Meunier and Miller, although all three could also have a see also section for the other spellings. The different items for left are mostly because of items that have the meaning direction, either physical or political, and hence need to be linked to the other language wiki disambiguation pages with items about the direction left, either physical or political. Since gauche does not mean the same thing in en and fr, and gift does not mean the same thing in en and no, it makes no sense at all to link them. Disambiguation pages can only be linked if the words have the same meaning in each language, and the spelling/word(s) used, is irrelevant. 17:15, 26 October 2014 (UTC)
You suggest to split w:en:Gift (disambiguation) away from w:no:Gift (andre betydninger)"? But it means i. a. the same, the 1883 novel by Alexander Kielland. You suggest to split w:en:Gauche away from w:fr:Gauche? But it means i. a. the same, the Gauche conformation. --Diwas (talk) 19:35, 26 October 2014 (UTC)
The fr:gauche page is mostly about "left", the en:gauche page mostly about things named gauche, only three of which have fr articles, and none of those three are included on the fr gauche dis page. To be meaningful, the link needs to be to dis pages that primarily have links to the same things in each language, as was the case before the Left page was "split". As to gift, as bizarre as it seems, the connection is fine, because while in no, gift means poison and married (how lovely a connection), the pages are connected by the two novels named Gift. 20:38, 26 October 2014 (UTC)
Dear You are right that each Wikidata item is about one concept or a class of associated items.
There are however two exceptions. Wikipedia Category pages get items even though they are usually about the same concept as another Wikidata item. We should probably combine Category wikidata items and the wikidata items covering the same concept.
The other exception is Disambiguation pages. These are about articles with similarly spelled names so Gift (english) shares a wikidata item with gift (german) and Links (english) shares a wikidata item with Links (german). If you want a list of leftist parties then that is an ordinary list, not a disambiguation page.
There is one exception have come across - one type of disambiguation page which may be considered a wikidata 'class'. These are disambiguation pages listing people with the same name. These can be a subclass of name and can be the target of 'Family name' or 'given name' statements. Filceolaire (talk) 22:07, 26 October 2014 (UTC)
A list of leftist parties would only appear on a disambiguation page if they shared a common word. The reason there are many left politics pages on the left dis page is that those particular items share the common word that means left in that language.
I would definitely not combine categories with pages, as they are different name spaces. The point though, about any link is that if you visit the page, it only makes sense it it makes sense to make a local interwiki link. When you look through history, you see that the left meaning disambiguation pages were linked to the other left meaning disambiguation pages, not to the spelled left disambiguation page, with the principle that to be a meaningful link to another language, the items on each page should also be linked, or at least some of them. But the problem of disambiguation pages containing multiple subjects is not unique to disambiguation pages. 23:11, 26 October 2014 (UTC)
The local interlikilinks had much interwiki conflicts, cause there are more than one meanings. – But the problem of disambiguation pages containing multiple subjects is not unique to disambiguation pages. Yes that is really true. --Diwas (talk) 09:35, 27 October 2014 (UTC)
How about requiring that a link to a disambiguation page go to the disambiguation page which has the most common pages, i.e. that are on the disambiguation page and link to each other. 03:37, 28 October 2014 (UTC)
You wrote: How can we dictate what each Wikipedia wants to put on their disambiguation page? that and the high count of languages is why there will be interwiki conflicts. Moreover you would have to check every month if some links in any language are new and the interwikilinks are to remap. The only way to get stable interwikilinks for all disambiguation pages are the title, not the meanings of the linked article pages. If we need connect disambiguation pages which have (or could have) many common pages, we need another way. --Diwas (talk) 11:19, 28 October 2014 (UTC)
There is nothing new about pages being out of date, and much less need to update, and reorganize wikidata items about disambiguation than it is to update wiki articles. I recently updated an article that was current as of 2007, and brought up to date the vi article on the ebola outbreak that was current as of August, but I would not like to force items about disambiguation articles to not include the logical articles. 01:43, 29 October 2014 (UTC)
To update an article, you need only one language and only one reference. To update an item about most-common-links disambiguation you check maybe hundreds of disambiguation pages (many languages and many links common with further disambiguation pages). --Diwas (talk) 09:16, 29 October 2014 (UTC)

Language column[edit]

First, I would like to note that Wikidata pages are very slow to load, I am not sure if that is just because it takes a long time to look up all the data, but is there any reason to display the language column in native language? Often I am looking for say, Slovenian, and have no idea what it is called in Slovenian (or worse, one of the many languages which to me just uses a bunch of squiggly letters - which is no doubt what they think of English). If I know the two letter code I can find it from that, but often I do not know the code. So I would suggest considering translating the language column into the selected language. That of course only needs to be done once, and is the same for every page. I would also though, suggest than when you put your mouse over the language you see the language in the native language. Right now I am making lists from the wikidata pages of what languages a particular article is in, and the language column is useless to me because it is in native language. On the wikipedia's, of course, it is useful to make the language be in native language, but on wikidata it serves no purpose, in my opinion, as everyone is already viewing that page in their own native language. 06:18, 21 October 2014 (UTC)

I can confirm the issue with the value being displayed in English once entering one and filed a bug for this. Thank you for reporting this. We are also aware of the loading time issue and working on it. Aude (talk) 22:12, 22 October 2014 (UTC)
Your bugzilla bug does not address the issue that I brought up. Here is what I am saying. I will use Giuseppe Porta (Q3108131) as an example. This is what it looks like in English:
Language Code Linked page
English enwiki Giuseppe Porta
français frwiki Giuseppe Porta
italiano itwiki Giuseppe Porta

This is what I want it to look like in English

Language Code Linked page
English enwiki Giuseppe Porta
French frwiki Giuseppe Porta
Italian itwiki Giuseppe Porta

and in French

Langue Code Page liée
anglais enwiki Giuseppe Porta
français frwiki Giuseppe Porta
italien itwiki Giuseppe Porta

and in Thai

ภาษา รหัส หน้าลิงค์
ภาษาอังกฤษ (with a mouse over to say English) enwiki Giuseppe Porta
ภาษาฝรั่งเศส (with a mouse over to say français) frwiki Giuseppe Porta
ภาษาอิตาลี (with a mouse over to say italiano) itwiki Giuseppe Porta

and in Chinese

语言 代码 链接的页面
英语 enwiki Giuseppe Porta
法语 frwiki Giuseppe Porta
意大利语 itwiki Giuseppe Porta

The column headings are translated (or should be - Thai is still in English), but the Language column is the one that I want translated. All of them can have a native language mouse over, I only showed the one for Thai. -- 10:19, 23 October 2014 (UTC)

Ah, yes I understand now and filed a new bug for this: Aude (talk) 13:17, 23 October 2014 (UTC)
Thanks. 18:48, 23 October 2014 (UTC)
I see some comments there about translating the "site names" of the wiki, and I am not interested in that but only translating the language that is used on that site. the site name is the enwiki, dawiki, dewiki, frwiki, itwiki column, and that does not need to be translated. It does point out though, that simplewiki is not a separate language, and should be moved to a new project space for "junior encyclopedias", and made available in multiple languages, catering to the grammar school audience. Right now it is largely regarded simply as a failed project. 08:13, 30 October 2014 (UTC)

type of[edit]

steak burger (Q18338265), for example, is not really an "Instance of" something (a sandwich), but a "type of" sandwich. Should we have a "Type of" property, as well as instance of? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:07, 22 October 2014 (UTC)

steak burger (Q18338265) subclass of (P279) something. --Diwas (talk) 19:17, 22 October 2014 (UTC)
Thanks, but does that work instead of instance of? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:10, 22 October 2014 (UTC)
Yes, instead of instance of. There are tons of steak burgers, and there are subclasses of it, like the Burger King Sirloin Steak sandwiches or like all steak burgers you eat ever, but the one you bite maybe tomorrow is an instance of steak burger (Q18338265) and an instance of the subclass of your own steak burgers. --Diwas (talk) 23:12, 22 October 2014 (UTC)
There is a nice tool for browsing subclasses, which can display, for example in this case, subclasses of "food product" as a tree or as a list. So many sausages!
Sometimes I have been confused about whether to call something an instance or a subclass. There's some explanation at Help:Basic membership properties, but I would really like a list of examples, and ideally parallel lists aligned by property, e.g. instances of human versus subclasses of human. --Haplology (talk) 09:29, 23 October 2014 (UTC)

@Diwas: @Haplology: Thanks, both, Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:23, 23 October 2014 (UTC)

@Haplology, Diwas, Pigsonthewing: see also Help:Classification, an essay of mine. TomT0m (talk) 09:30, 28 October 2014 (UTC)

what P31 for "1980 in xxxx" (year list of events) ?[edit]

What instance of (P31) should I use for all those 1980 in France, 1945 in football, items ?

Is chronicle (Q185363) that I've seen on some of those items OK ? or should I just use Q18288183 (Q18288183) - sorry Liste (Q348188) — ? or is there another item ? Thanks for help, since those items are accumulating just now… --Hsarrazin (talk) 15:00, 23 October 2014 (UTC)

1980 in France is not a real chronicle (Q185363), since it is just a title of an overview article created by wikipedians. So I would suggest to make an item Wikimedia year chronicle similar with Wikimedia history article (Q17524420). Michiel1972 (talk) 09:30, 24 October 2014 (UTC)
I created article about events in a specific year or time period (Q18340514). Michiel1972 (talk) 09:39, 24 October 2014 (UTC)
Thank you very much :) --Hsarrazin (talk) 20:01, 25 October 2014 (UTC)
@Hsarrazin, Michiel1972: Hi guys, I'm not sure about that. 1980 is a year, for sure. A wikipedia article about this year is something different. Yet we do not say the item about 1980 is a chronicle. It is an article about that year. I think the got the same for 1980 in France : it is an article about the events that took place in france in 1980, so the topic for the article is events in france in 1980. This is a subclass of events, I would also say, per help:classification that it is an instance of class of events in a year in a country, for example. TomT0m (talk) 09:38, 28 October 2014 (UTC)
TomT0m, I don't like the label either... I agree, "chronicle" is maybe not the best name, even if it matches the global meaning of chronicle, which means a regular narration of events, in chronological order...
the most important thing, to me, is to have a "clear concept" to link to... - its label and descriptions can be discussed - obviously, this item is a success : already 5375 of linked "year articles" - and not all by me ;) --Hsarrazin (talk) 10:33, 28 October 2014 (UTC)
@Hsarrazin: it's also imortant to be consistent project wide. When we say that Barrack Obama is an instance of human in a statement, it is accepted that <human> is a class of real world object, and that Barrack Obama belongs to it. When we write an article linked to this item (Obama's), we are not writing an article about Barrack Obama's biography. But there may be an item labelled <Barrack Obama's biography>. A different one. The Wikipedia article on the <Barrack Obama> may be a biography ! but it's not about Barrack Obama's biography external work ... I think that when we write an article about a year in some place, we face the same problem. The article may be a chronology, a journal of whatever, but the item he is linked to with instance of or subclass of must be about the topic, not referring to the form of the wikipedia article, which may be language dependant. Or we are not consistent in instance of (P31) and subclass of (P279) usage. The raw number of the item usage does not change really this and may really well be the work of only one user with the help of an automated tool. If we don't do that we lose a lot of the usefulness of structuring datas and go back to the old categories with no clear meaning :) TomT0m (talk) 11:38, 28 October 2014 (UTC)
@TomT0m:, whatever the language, these articles are yearly synthesis of a subject (country, sport, entertainment, etc.) - so, what P31 do you suggest to use ? :) --Hsarrazin (talk) 14:36, 28 October 2014 (UTC)

Commons AND Commonscat[edit]

Sorry, I'm not confident with the structure of WD, and I didn't have a look. But I cannot assign a commons page AND a commons category to the same item in WD. Why? Many times there are both a page and a category and the articles in the WPs in different languages follow different strategies to use pages or categories to link to Commons content. It would be helpful to allow the assignment of both a page AND a category in parallel. If the item is assigned to the page, I cannot assign the same item to the corresponding category. Which puts me back to using old interwiki syntax. Or is there already a policy on that topic. Different people obviously do it differently. Feel free to move this discussion to the right place. --Herzi Pinki (talk) 16:25, 23 October 2014 (UTC)

You add Commons category on the WD item about the category, and the Commons page on the WD item about the page. Like this: Category:Paris (Q5626403) (Commons:Category:Paris) and this: Paris (Q90) (Commons:Paris). Hope this will help you. --Harmonia Amanda (talk) 16:53, 23 October 2014 (UTC)
@Herzi Pinki:. It's a known problem. See c:Commons:Structured_data/Short_introduction_to_Wikidata#Commons-Wikidata_sitelinks for some discussion. But yes, at the moment it means that Commons categories are not to be directly sitelinked to article-like Wikidata items.
What we may do soon, though, is to roll out a template to go on Commons categories, to link them to an article-like page on Reasonator (eg this for Paris), that would provide further wikilinks. But the identifier for the article-like item would probably need to be explicitly included as a parameter to the template, because it's not the same as the category-like item the category would naturally be linked to; and in any case most Commons categories don't have any category-like item.
For Commons galleries, we should be able to do something more sophisticated. A very very basic prototype for a Commons gallery header can be seen at d:Template:SimpleCommonsGalleryHeader/test. To implement this requires Phase 2 access to Wikidata to be enabled for Commons; an RfC to request this is now open on Commons. Jheald (talk) 12:57, 24 October 2014 (UTC)

Impending deletion of Persondata template and associated metadata[edit]

English Wikipedians are chomping at the bit to delete the Persondata template from all the biography articles on English Wikipedia (currently included on 1.2 million articles). This is a hidden template (similar to the Personendaten template on German Wikipedia) that holds human-curated metadata about biographical articles. In the past month there has been an RfC and a TfD about deleting the template. Both reached the consensus that the template should be deleted as soon as all the metadata is migrated to Wikidata. This data includes:

  • NAME -> probably doesn't need to be imported
  • ALTERNATIVE NAMES -> Wikidata aliases
  • SHORT DESCRIPTION -> Wikidata description
  • DATE OF BIRTH -> Property:P569
  • PLACE OF BIRTH -> Property:P19
  • DATE OF DEATH -> Property:P570
  • PLACE OF DEATH -> Property:P20

While some of this data has already been imported, much of it has not, especially descriptions and aliases. Are there any bot writers that would like to help import this valuable collection of metadata before it gets deleted? Kaldari (talk) 18:06, 23 October 2014 (UTC)

I am not sure if it's enough to use labels and aliases to replace these templates. We need real name-properties. -- Innocent bystander (talk) 18:16, 23 October 2014 (UTC)
Can you elaborate? Are you referring to importing the NAME as a sortable name? The aliases can probably be imported as is. Kaldari (talk) 18:21, 23 October 2014 (UTC)
I have not been active here the last months, but properties for name, birthname etc should be created as soon as technically possible. And NAME/ALTERNATIVE NAMES should use such properties, to be able to add statements and sources. -- Innocent bystander (talk) 18:28, 23 October 2014 (UTC)
Regarding: "import this valuable collection of metadata before it gets deleted" - as far as I understand the outcome of the RfC in English Wikipedia, there's no danger that metadata will be deleted prematurely. No one wants to lose data, I suppose. The Persondata template in English Wikipedia can/will be deleted when it's really made obsolete by Wikidata, but not before. - Likewise, I think also the data from German Personendaten should be imported here, of course. Gestumblindi (talk) 20:53, 23 October 2014 (UTC)

I've posted a bot request. Kaldari (talk) 18:21, 23 October 2014 (UTC)

Morning, I think it will be make sense to import the data for german Wikipedia, too. So I leave a text at the botrequest --Crazy1880 (talk) 05:31, 24 October 2014 (UTC)
Supplement to the text of Kaldari. The name is usually represented as follows: NAME = Property:P735, Property:P734. --Crazy1880 (talk) 05:43, 24 October 2014 (UTC)

One thing that there is in Personadata is the name in the order it should be sorted in. (Which can be non-trivial). This is something we really ought to have in Wikidata, to be able to easily sort the output of WDQ queries. It would also be useful to have, eg for c:Commons:Structured data, to be able to sort search hits or a category by artist. Can we please import this as a string. This may need the creation of a new property to store it in. Jheald (talk) 09:23, 24 October 2014 (UTC)

Proposal posted; see Wikidata:Property proposal/Generic#Sort_key.
Jheald (talkcontribslogs), Persondata DOES NOT contain sort value for names. The |name= is supposed to be surname, firstname. About 20% of the cases, it is entered wrong, usually firstname, surname. DEFAULSORT contains the sort value in all Biography articles. Sort value does not equal surname, firstname in alot of cases.
Otto von Bismark... DEFAULTSORT:Bismark, Otto persondata |name=von Bismark, Otto.
Francisco da Costa Gomes... DEFAULTSORT:Gomez, Francisco persondata |name=da Costa Gomes, Francisco.
Bgwhite (talk) 00:55, 28 October 2014 (UTC)

If entered properly, the birth and death dates in Persondata follow WP:Manual of Style; the details are contained in WP:Manual of Style/Dates and numbers (MOSNUM) which calls for using the Julian calendar on and before 4 October 1582. After that, the Gregorian calendar is used, if it was in force in the location(s) discussed in the article. If the Julian calendar was in force in the relevant location(s), it is used. MOSNUM is not explicit about what to do if the relevant location used some other calendar, and it is in the period where the Gregorian calendar had not fully supplanted the Julian calendar. Persondata does not have any flag to indicate if the Gregorian or Julian calendar was used. This makes it essentially impossible for a bot to import dates before 1924, the first full year Greece adopted the Gregorian calendar for secular use. I will repeat this comment in the bot request. Jc3s5h (talk) 14:45, 24 October 2014 (UTC)

I've replied there. I suggest we all agree to conduct discussion in one, not two, places. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:37, 24 October 2014 (UTC)
Link? Where is "there"? 17:26, 26 October 2014 (UTC)
Wikidata:Bot_requests#Import_Persondata_from_English_Wikipedia --Pasleim (talk) 17:37, 26 October 2014 (UTC)

Redirects cause bad merges[edit]

A good-faith edit by User:Styko, discussed at User talk:Styko#Q18339801, in which they used the "edit links" feature in the sidebar of a Wikipedia article, caused the merge of two items on related, but different, topics, due to a redirect. How can such problems be avoided? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:21, 23 October 2014 (UTC)

The problem was caused because a link was made to a redirect. Redirects can not have wikidata links, and it has been removed. There used to be an en article about the subject[1] but it was deleted and changed into a redirect. When that was done the wikidata link needed to be removed. 12:17, 25 October 2014 (UTC)
No, you are wrong. Redirects can have wikidata links, but for now adding them is quite non-obvious. This example shows that redirect link in an item is useful, because it helps to get specific information even if it is in the other article now. --Infovarius (talk) 14:10, 25 October 2014 (UTC)
I am going to need a link to something that says that. Redirects have always been prohibited, and for very good reason. 18:02, 25 October 2014 (UTC)
CF Wikidata:Notability "Note that a single Wikimedia page cannot have more than one sitelink in Wikidata and that a sitelink cannot point to a redirect." So you can not link to a redirect, and you can not link to a section of a page, because that would be two sitelinks to the same Wikimedia page. 18:19, 25 October 2014 (UTC)
That's the notability policy, not the linking policy. And could we have this discussion in one place and not, as at present, in at least three? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:13, 25 October 2014 (UTC)
All policies and guidelines inherently are consistent with each other, otherwise they are meaningless. The correct place to discuss this topic is here ("This page documents a Wikidata policy. It is a widely accepted standard that all editors should normally follow. Changes made to it should reflect consensus. When in doubt, discuss your idea on the project chat."). The correct place to discuss someone not following the policy is on their talk page, and the correct place to discuss an item that is repeatedly changed in violation of policy is on the talk page of the item that is being changed. So that is three topics, and three different appropriate places to discuss them. There is a fourth place this is being discussed Wikidata:Requests for comment/A need for a resolution regarding article moves and redirects, but the correct place is here, although this topic could be easily consolidated to the RFC page, to keep it in one place. 03:53, 26 October 2014 (UTC)
Sadly, you have ignored my suggestion that we have this discussion in one place and not in at least three (actually now five; you omitted User:Styko's talk page). I have just replied to a comment near-identical to your first point, which you made on my talk page. If you believe I have breached policy, take the matter to the admin notice board; then you can add another to your list. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 26 October 2014 (UTC)
What for? Breaching policy is not a blockable offence, unless it becomes persistent - newbies do it all the time. We do not take every little thing to the admin notice board, but only things that require the action of an admin. We discuss them on the users talk page. As to where this discussion is held, you are welcome to add "discussion moved to/continued at XXXX" on four of the five. 16:26, 26 October 2014 (UTC)

Wikidata-Templates for Wikipedia[edit]


I tried to find an answer to the following question on several development related pages, but haven't found the answer.

Will it sometime be possible to have some kind of Wikidata templates, i.e. templates that are filled with data here on Wikidata and can be used in the various Wikipedias out there. Use cases I am thinking of might be

- international infoboxes, i.e. an infobox is created once and just has to be translated and/or changed in design on that basis to be included from the local Wikipedias - international templates, e.g. tournament tables - imagine we would only have to fill out the results from any sports tournament once and have it available in all Wikipedias.

Would be nice if you could point me in the right direction, thanks in advance. --Mad melone (talk) 13:53, 24 October 2014 (UTC)

You are absolutely right. Wikidata is made exactly for this purpose. The use of templates that get the informations out of Wikidata is possible allready and it is not so difficult to use ist. Just put {{#invoke:Wikidata|claim|P217}} to get the value of inventory number (P217) in your template or {{#invoke:Wikidata|labelOf}} to get the label of the item in your template. However you need to create all necessary properties and source them. You have to make sure that all information is stored on Wikidata prior to using it in a template.--Giftzwerg 88 (talk) 16:00, 24 October 2014 (UTC)
There is still another issue: There are still some datatypes missing. We are not able to store all kinds of datata now. This is something the programmers are still at work. Lots of properties are not created until now because, the datatypes are missing. Unfortunately I can not find the documentation to all the possibilities of templates using wikidata. There is even a discussion to centralize the templates just as commons does with files. Then it will be possible to write a template once and use it in every wikipedia without having to copy it multiple times for all the wikipedias just by placing the name of the template into the pages. Many communities still debate if they want to use Wikidata at all. There is no activity to encourage users to write templates that use Wikidata, because there are still many issues and bugs to fix. But if you want it, you can use it with some limitations.--Giftzwerg 88 (talk) 16:43, 24 October 2014 (UTC)
Thanks for your swift reply. However, it is more about what you wrote in your second reply: especially things like tournament tables or all kind of sport results mostly have just a name and a result. But if we do this work for each local wikipedia with the respective language template, then we would have to fill out the template as many times as there are wikipedia articles in the different languages. So why not get these data at one template that might be translated, but all uses the same underlying data, e.g. sports results only would have to be updated once. I know that there are discussions on many wikipedias on whether to use wikidata at all, but this question is not about how to use wikidata in templates, but how enter data into templates once for all wikipedias.
In general, I was just curious whether this was on the development map at all or not.--Mad melone (talk) 08:30, 25 October 2014 (UTC)
see 1916–17 Svenska Serien (Q2055556) for a season where I habe tried to enter all the league table info. Filceolaire (talk) 12:15, 26 October 2014 (UTC)
That's more like it, but to visualise what I want to achieve: Please see 2014 Wimbledon Championships Women's Singles Draw and more or less the same Draw used in different languages (see Q16744746 for a list of languages). Instead of filling out the results for every language, there should be a way to include them into Wikidata and then just to include a template that gets its data from Wikidata for each language. We could do this by filling in data in the same format as right now in the templates, but why not have a more visual editor like approach to it, i.e. having the template on wikidata to be filled out not in wikicode but via the wikidata GUI, best case this GUI showing the template to be filled out directly. Is this possible or could this possible within the recent scope of Wikidata?--Mad melone (talk) 13:01, 26 October 2014 (UTC)

@Lydia Pintscher (WMDE): Call for help ;)--Mad melone (talk) 09:16, 28 October 2014 (UTC)

I guess what the original poster is asking for is global templates? I know quite a few people are asking for it. I don't have it on my roadmap. In my opinion it is a nice idea and should be its own project probably. --LydiaPintscher (talk) 15:39, 28 October 2014 (UTC) (posting from my personal account because I am getting strange errors on my work one...)
In my original post I was referring to global templates, that's correct. Thanks for clarifying that this is not on the roadmap, I wasn't sure about that. I have an idea for an workaround and will post it once I have run it through my head once more. Further, I want to have community concensus on this.--Mad melone (talk) 16:32, 28 October 2014 (UTC)

See unter "Tournament draws" below.--Mad melone (talk) 11:05, 29 October 2014 (UTC)

Changing datatype[edit]

Is it possible to change a property's datatype? The property legal citation of this text (P1031) is a string, but for the sake of obsessive completeness, I'd like it to be monolingual text so that Canadian legislation to include the official English reference and official French reference (even though they're almost the same, English's "RSC 1985 c C-46 s 745" is French's "LRC 1985 c C-46 art 745). --Arctic.gnome (talk) 18:39, 24 October 2014 (UTC)

I can not even see any way to create a property, let alone set the datatype. Help:Data type describes the datatype but does not say how to change it. 06:01, 25 October 2014 (UTC)
It's not possible to change a datatype. The only way is to create a new property and delete the old one so you might first start a discussion at WD:PFD. --Pasleim (talk) 12:31, 25 October 2014 (UTC)

Can not edit (is this page protected?)[edit]

I had tried to add anatomical properties at rectum (Q158716). But, to me, there are no 'edit button'. Is this page protected? I want to add A05.7.04.001 to TA98 and 14544 to FMA. Thanks. --Was a bee (talk) 02:21, 25 October 2014 (UTC)

@Was a bee: Checked, it's not protected from what I see. I can't edit it either. --AmaryllisGardener talk 02:23, 25 October 2014 (UTC)
I cannot see what you are trying to add, but none of the Wikidata data pages have an edit tab at the top - I see all the usual edit links, and when I click on them they open as usual. 05:17, 25 October 2014 (UTC)
Thank you @AmaryllisGardener:, @ Now I can see edit links at that page. Hmm... mysterious phenomenon. But anyway, now it's ok. Thanks :D --Was a bee (talk) 07:31, 25 October 2014 (UTC)
Yes, it is a bizarre and unfamiliar user interface, very different from what anyone who is familiar with editing wikipedia is expecting. 12:11, 25 October 2014 (UTC)

LUA test to see if qualifier is used[edit]

Hi everyone, for Wikidata:Coordinates tracking we have some logic to see if coordinate location (P625) is used. If that's the case the article ends up in Category:Coordinates on Wikidata (Q15181105), if not it ends up in Category:Coordinates not on Wikidata (Q15181099) so we can import it. Now we run into an interesting edge case: For some people and companies coordinates are listed. For people this is usually the burial location and for companies the headquarters location. See or example BMW (Q26678). Could someone make a snippet of LUA code to check if a property is used as a qualifier in an item? It should return true in the BMW example. Than we can update the template for the tracking to remove the false positives. Multichill (talk) 11:16, 25 October 2014 (UTC)

Maybe something like:
function checkCoor(property)
 if property and property ~= '' then
  local property =
  local entity = mw.wikibase.getEntityObject()
  if and[property] then
   for i, statement in pairs([property]) do
    if statement.qualifiers and statement.qualifiers[P625] then
     for j, qualifier in pairs(statement.qualifiers[P625]) do
      if qualifier and qualifier.datavalue and qualifier.snaktype == "value" then
       return qualifier.datavalue.value.latitude .. ' ' .. qualifier.datavalue.value.longitude
 return nil
local p = {}
function p.qualifierInUse(frame)
 if checkCoor( ~= nil then
  return true
  return false
return p

Usage: {{#invoke:"Modulename"|checkCoor|property=p##}}, returns "latitude longtitude" or nothing. I'm not programmer so there may be errors. Matěj Suchánek (talk) 12:01, 25 October 2014 (UTC)

That's already a bit more than I needed :-). Probably could have a more general function qualifierInUse(<some property>) than just returns True or False. Multichill (talk) 12:34, 25 October 2014 (UTC)
If you use it in wikitext, you can use {{#if: {{#invoke:}} | }}. I made a change to the code. Matěj Suchánek (talk) 13:01, 25 October 2014 (UTC)

Monolingual text fields and Norwegian names[edit]

I've been running into awkwardness with the official name (P1448) of Norwegian organizations. There are two main written forms of Norwegian, with ISO codes nn=Nynorsk (Q25164) and nb=Bokmål (Q25167). However many Norwegian organizations have a single official name in "Norwegian", not designated specifically as a Nynorsk or Bokmål name. For this it seems like the umbrella code no=Norwegian (Q9043) would be the appropriate qualifier for the monolingual text field. But Wikidata appears to consider this a synonym for nb, and the English rendering of it for text fields is "Norwegian (bokmål)". Is this still the right thing to set for official name (P1448), and just a rendering issue? --Delirium (talk) 22:58, 25 October 2014 (UTC)

The names in those cases are valid for both bokmål (nb) and nynorsk, that is you can use the same name for both bokmål and nynorsk. The language code no is in part a metacode for both nb and nn, and in part a country code. I don't think it is a proper code to use for monolingual text. Jeblad (talk) 15:39, 26 October 2014 (UTC)

can not add reference[edit]

On the page for item Zürich (Q72) (Zürich) I can not add any reference to statements. When trying to save an edit, I always get a error message saying: "An error occurred while saving. Your changes could not be completed. Details Internal Server Error". First I thought it might just be some temporary issue, but this problem now exists for about a week already. Other items I have no problems editing. Any idea what's the cause of this? 2A01:2A8:8401:D701:AD8C:CE9D:E9C3:202C 13:37, 26 October 2014 (UTC)

What is something you wish add? 16:53, 26 October 2014 (UTC)
I tried to add P170 to The servant girl (Q17334200), and the "save" was not a live link - is it looking for something else, other than "Willem van Odekercken"? The save link does becomes live if I put in a Q item. That particular painting though, is actually "attributed to Willem van Odekercken", if the google translation is correct, so is there a property for that? 18:56, 26 October 2014 (UTC)
I can confirm that there is an issue with Zürich (Q72). Reported it to Wikidata:Contact_the_development_team#Q72. The problem with The servant girl (Q17334200) is, that the property creator (P170) has data type "item" but there is no item about "Willem van Odekercken" yet. That means you have first to create an item about Willem before you can add it as a value. --Pasleim (talk) 20:11, 26 October 2014 (UTC)

Prices and price indices[edit]

I wonder how the actual values of prices and price indices shall be encoded.

There is a lot of price indices like w:en:Consumer Price Index, but digging into this reveals a lot more of them than the articles listed in w:en:Category:Price indices. Examples include such things as House price index, Commodity price index for the industrial sector, and Transport and storage, price indices. Some of them relates to standards so they can be compared. One idea is to use a qualifier to say that those values are instances of a price index, thereby minimizing the number of properties to a single price index. If we want we can make specific subproperties for the most common ones, but I think it could be better to stick with a common layout. In addition we must add qualifiers for at least the date (point in time) where the price index was sampled. The price index must also have a qualifier for the area (country) unless it is clear from the context (that is the item) what area is covered. That means we must include country as a qualifier if actual values for price indices are dumped on Consumer price index (Q180687) (no country property) but not if they are placed on a page like United States Consumer Price Index (Q7889660) (there can be added a country property).

To me it seems like this conveys the idea of a specific price index at a specific time and for a specific area. If we get more information about which price indices are used we can implement specific subproperties for those, but until then lets make something simple that works. Or is it something that makes it necessary to create all subproperties now? Jeblad (talk) 14:50, 26 October 2014 (UTC)

Unused items[edit]

I am curious about the policy that items must have at least one link. The item The servant girl (Q17334200) currently has no links, but is certainly a real painting, and a wiki could certainly have an article about it, but evidently none do now. Is there any utility in keeping it? Or any items without any links? Commons has a copy of the painting, which I have now added. 17:58, 26 October 2014 (UTC)

There is no policy that items must have at least one link. According to WD:N, also an item is accpeted if it is about a clearly identifiable conceptual or material entity or if it fulfills some structural need. --Pasleim (talk) 19:15, 26 October 2014 (UTC)
Thanks, I see that now. Not sure how I missed the words "at least one", especially because it is in bold. The item has a link to the commons image already, is that better than the link that was added? 20:50, 26 October 2014 (UTC)
Yes, to link to a commons image we should use the property image (P18). Adding a sitelink to a file is actually not allowed according to WD:N point 1.1 --Pasleim (talk) 10:15, 27 October 2014 (UTC)

Meta RfCs on two new global groups[edit]

Hello all,

There are currently requests for comment open on meta to create two new global groups. The first is a group for members of the OTRS permissions queue, which would not contain any additional user rights. That proposal can be found at m:Requests for comment/Creation of a global OTRS-permissions user group. The second is a group for Wikimedia Commons admins and OTRS agents to view deleted file pages through the 'viewdeletedfile' right on all wikis except those who opt-out. The second proposal can be found at m:Requests for comment/Global file deletion review.

We would like to hear what you think on both proposals. Both are in English; if you wanted to translate them into your native language that would also be appreciated.

It is possible for individual projects to opt-out, so that users in those groups do not have any additional rights on those projects. To do this please start a local discussion, and if there is consensus you can request to opt-out of either or both at m:Stewards' noticeboard.

Thanks and regards, Ajraddatz (talk) 18:04, 26 October 2014 (UTC)

Expedition leaders etc.[edit]

Should "commanding officer" or "leader" be used for the leader of an expedition which may include both civilian and military personnel? Should individuals who are part of an expedition be "members of " that expedition? If they have a specified role (botanist, cartographer) on the expedition, how should that be recorded - as "position held", with both the expedition name and the dates as qualifiers? Thanks. - PKM (talk) 04:09, 27 October 2014 (UTC)

I would say "yes" to all the above questions. /ℇsquilo 06:30, 27 October 2014 (UTC)

erroneous label in farsi (or arab) in en label[edit]


I accidentally found a bunch of items with erroneous english labels but I have no tool to find and correct these accidental erroneous labels… Those I saw all came from a farsi link… but there may be lots of others… 

Is there a way to find them, and possibly a bot could remove them ? - or better, someone who understand them could replace them with correct label in English ;) - thanks :) --Hsarrazin (talk) 20:39, 27 October 2014 (UTC)

It is not useful to remove them without first moving them to where they belong. The ones I checked were all ar categories, they only need to be translated if there is no item for that category already. But it would have been much easier to not create them at all, but instead find the correct item and link it to them, but if you just delete them you prevent them from being added. 17:40, 28 October 2014 (UTC)

combined interwikilink list[edit]

Exists any tool or template (I am not familiar with it) that shows a combined list of interwikilinks of an item and its parts (respectively its instances, subclasses, ...) ?

Like the following (thanks to Diwas (talk) 21:01, 27 October 2014 (UTC)--Diwas (talk) 22:49, 28 October 2014 (UTC)

with links:

has part

-- 18:11, 28 October 2014 (UTC)

As far as I know, there is no tool or gadget that does this. But it would be definitely worth to write such a gadget. --Pasleim (talk) 08:28, 30 October 2014 (UTC)
But it would be better, implement it directly into Mediawiki. --Diwas (talk) 12:24, 30 October 2014 (UTC)
Mediawiki (the software), or wikidata? On Wikipedia articles it is handled by using "See also". In the section below "Different article types in one Wikidata item" there is also a request for a way of linking multiple articles from wikidata, sort of like having two English language reference books about the same subject - right now many of the Ebola outbreak (or is it now an epidemic?) articles are not linked to each other, because some are about Ebola virus, some about the 2014 outbreak, some about the outbreak in specific countries. It is very frustrating trying to find out if a wiki has an article about the subject because they are in two large groups, that are not consolidated. 22:33, 30 October 2014 (UTC)
I think navigation features should be in Mediawiki (the software), a gadget would be second-best solution.--Diwas (talk) 23:34, 30 October 2014 (UTC)

Open Data Awards[edit]

Hi everyone,

Some exciting news here. The Open Data Awards' finalists lists were recently published on their website. Wikidata has been listed as a finalist in two different categories which are the Open Data Innovation Award and the Open Data Publisher Award. Lydia and Magnus will be representing Wikidata at the gala dinner where the winner of each category will be announced live. I will be standing in as a backup should Lydia be unable to attend the award dinner but let's wish Lydia and Magnus a good time and keep our fingers crossed that Wikidata will win at least one of the two categories we've been nominated for. As Lydia would say - the entire community is awesome for working to help build Wikidata to where it is and this is as much as all of our work as it is the development team's for helping build and innovate the way free knowledge is shared within the mission of the Wikimedia Foundation.

On behalf of Lydia, John F. Lewis (talk) 23:52, 27 October 2014 (UTC)

Great news. -Tobias1984 (talk) 10:01, 29 October 2014 (UTC)

Unreachable parts of online databases[edit]

Recently User:Succu has removed a bunch of authority codes because "Non-authenticated user does not have access to it" - edits like this. I'd like to discuss it. Do we want to have full coverage of authority codes or only those which are open to everyone (i.e. "free data")? I have a slightly pro for all links - situation can change and non-free records can become freely accessible as well as in the opposite direction, but we need no to track this. --Infovarius (talk) 13:02, 28 October 2014 (UTC)

Minor clarification: authenticated users also have no access to, as it redirects to main page. The correct EOL ID for Euarchonta is 33305315 (32000033 could be a deleted duplicate entry, similar to Wikidata). --Lockal (talk) 13:21, 28 October 2014 (UTC)
Or 42410181. --Succu (talk) 13:30, 28 October 2014 (UTC)

Honoré de Balzac (Q9711)[edit]

This article has two problems. (1) Balzac had a brother (Henry) but there is no mention of him. How do you add the category "Brother" ? (2) Date of death has two dates : 18 August 1850 and 19 August 1850. In fact, Balzac died at 23:30 on August 18. This is mentioned in every biography. I wonder if the date 19 August could be due to a shift in Time Zone. Anyway, this discrepancy has to be corrected. Codex (talk) 16:12, 28 October 2014 (UTC)

to add a brother, you first need to have (or create) an item for this brother, with as much info as you can... - in any case, you should NOT add a brother (or sister) by just adding a link to a "given name" item, like you did for Laurence - to create a family link, you must use a complete item, describing the person... Name, given name, dates, who s/he is, etc...
then, when the "brother item" (Henry Balzac) is ready, you may add it with property brother (P7) :)
for the death date problem, the second one is now "deprecated", and I added a trusted source for the right one, so it is corrected :) --Hsarrazin (talk) 16:50, 28 October 2014 (UTC)
Thank you Hsarrazin! I understand a bit better how Wikidata works. I won't be able to add the informations before a while, because I don't have my reference books right now. Moreover I don't think those persons deserve an entry in Wikipedia: Laurence died when she was around 20; Henry did not do anything noteworthy. Codex (talk) 20:45, 28 October 2014 (UTC)
@Codex:: You can still make items for them at Wikidata. Just make sure that they are linked from Honoré de Balzac (Q9711). --- Jura 16:59, 29 October 2014 (UTC)

JSON dump has duplicates[edit]

I've been working with the JSON dumps and notice that it has identical duplicate entries. For example, in the latest dump [2], line numbers 921522 and 16155575 are identical dumps of item Turi railway station (Q17100180). There are dozens of these duplicates. Should these be treated in a special way when processing the data dump? Jefft0 (talk) 01:17, 29 October 2014 (UTC)

It looks like another item page [3] redirects to Turi railway station (Q17100180). I don't think the redirect should be in the dump as a duplicate, so seems like a bug. But the redirect probably should be represented somewhere and in some form. Aude (talk) 07:18, 29 October 2014 (UTC)
Thanks for submitting the bug! I'll watch it. Jefft0 (talk) 16:19, 30 October 2014 (UTC)

Tournament draws[edit]

Having started the discussion above in section Wikidata-Templates for Wikipedia, I wanted to start a new section with a more specific proposal that incorporates what I have learned in the previous discussion. I will split the various steps that I think need to be addressed, but please feel free to add further issues you see.

0. Background

In sports, we generally have lots of tournament draws that are part of the local WP articles. Coming from a tennis background, please allow me to use this as an example, but of course the possible use cases are beyond tennis and maybe beyond sports as well.

Such draws generally contain the same data for all local WPs, please see as an example the 2014 Wimbledon Championships Women's Singles draws:

Therefore, I see this as a perfect usecase for central data storage in WD, because at the moment all the various templates have to be filled manually for each country. A most of them are also structured in a similar way, we might find a way to use this data in the local templates.

Could someone run a data query to see how many tournament draws might be affected (starting with tennis) to see the scope/size of the idea?

1. Wikidata (WD) to save data points

Basically, the templates require the following data (I used the English one as the example, but you will find that most of the templates follow this structure):

RD1, RD2,... // Descriptions of the round, e.g. "First Round", "Second Round", "Semifinal", "Final", in my opinion, these still must be changeable in the local templates even though other data may come from Wikidata

RD1-seed01=1 // Seed of Player1

RD1-team01=Template:Flagicon S Williams // Player1 and Flagicon. Can the Flagicon somehow be derived from the player nationality? Further, can the templates generally identify the winner of a match to print them in bold? Or do we need another statement for that?

RD1-score01-1=6 //Score Player1 in first set. Can templates generally make up, who won the set?

RD1-score01-2=6 //Score Player1 in the second set

RD1-score01-3= // Score Player1 in the third set. Please note that Men's Matches or generally other sports may be played Bo5, Bo7 or generally something else than Bo3.

RD1-seed02= //Now the information come for the second player. Please note that the player numbers are counted for all matches, i.e. the second match in this round would be between player 3 and 4

RD1-team02=Template:Flagicon A Tatishvili




I am by no means a data or WD expert, so how can we store these data? I like the structure of <Round>-<Statement>-<Player#>, because that is something which in my head we could be mirroring 1:1 in WD, can we?

Question is, whether we can get the data out in a local WP template as needed? Which P..... would we have to create?

2. Bot to collect data on large scale

If we agreed whether the whole project is feasible, we should have a bot run through the local WPs (most likely the enWP has most of the data) to crawl the templates and enter the respective data into WD. Again, I am no expert, but I see the following challenges:

- I guess that we can derive the Q.... from the link to a player that is used in the local WP, but what if the local WP does not have an article for a player? There needs to be some manual work, but how would that look? - There should be a source for each of the draws in the respective articles, could we have this as the source for every single statement? - I guess a phased approach would be best to get the maximum amount of quality of the data points, so start with little amount of draws, before the bot really goes live. All in all, this should be a one-off task, because expectation is that we fill out the future draws directly in WD. - Most of the draws for larger Grand Slam tournaments are split into up to 8 sections. The bot would have to be able to recognise this and make a continous counting of the position of the match/players in each round, so that for example a field of 128 players split over 8 sections is not numbered form 1 to 16 for 8 times, but correctly numbered from 1 to 128 and then from 1 to 64 in the second round and so forth. Further, the final rounds for Grand Slam tournaments are also in a bespoke draw, so that would have to be taken into consideration as well. Probably best to have bots being able to differentiate between different field sizes. - The more I think about it, that could be the showstopper for the idea, because there are many different tournament draw templates out there, that we would have to take into consideration.

3. Templates to bring draws to local Wikipedias (WP)

With templates, I see the following issues: - Being able to tell a template to start at a specific player number and to go through to a further player number (e.g. the draw for section 2 in the examples shown above should feature players 9 to 16). - Being compatible with various language specifics, e.g. format of player names - Being able to identify the winner of a match to print out in bold letters - Being able to get something like a Flagicon from a Player Q...., probably via nationality?

4. Local WP involvement

Once we have discussed and see whether this is feasible or not, I would reach out to the local WPs to get their input. It is imporant that this is no must to use WD for them, but could be nice, especially if you try to keep a draw of a current tournament updated. Further, if this works out, it should be very easy to bring all these information to smaller WPs by just using a template.

5. Future development

Future developments I can see: - Instead of being entering the players and results manually into WD data base via the current interface, there should be a form looking like the draw template in which you can enter the data and which would give you a much better look and feel b/c you a) would instantly see what the result would look like abd b) you wouldn't get lost in potentially 128 player numbers, but would actually enter the data right into the draw. - Global templates, but Lydia already confirmed that this is currently not on the development map.

I know, it is a long read, but going step-by-step in my opinion is really important in such a potentially large scale project.

Looking for all of your input, because I just came up with the idea, but have no clue on how to make it happen...--Mad melone (talk) 11:03, 29 October 2014 (UTC)

It's a great idea, as currently it's rather time consuming to add the 5 draws of a tennis grand slam to the Dutch wiki only. I can copy/paste most of the scheme, but not all, for example the templates with country flags need to be "translated", and especially on the Russian players there are differences in the spelling of names. This makes it a tedious job, four times a year (for four grand slams). And the same exercise for the French, German, Spanish, Italian, etc wiki's. If this could be consolidated into one schema in WikiData, that would be a true time saver, even if we have to create the WD-schema manually! Edoderoo (talk) 11:35, 29 October 2014 (UTC)
That's a good idea but very difficult to use. I have created thousand of tennis tournaments draws in (you can see it). It's easy to "export" or "import" to or from an edition of wikipedia to another one if everybody used same templates, same conventions, same wikilinks...but if someone uses other parameters it's impossible to export or import. If we create an istance of a tournament in wikidata we must to fill it with thousand of parameters about the tennis players, the "flagicons", the results etc...This work must be done by a bot (or similar) and it isn't so simple. Some results about tennis tournaments are updated just after the end of a match or a set (in some cases). Who can update these results? I repeat, it's a brilliant idea, I hope to see a common global project about tennis results.--Matlab1985 (talk) 22:40, 30 October 2014 (UTC)

Looking at the information we are trying to encode here it looks to me like we need to make two statements for each set - one for each player:

Team icon:icon.jpg
Games won:7
Special note:won by a tiebrake game
Participant :Seles
Games won:4
Games won:3
Ranking:1 (i.e. first place out of the two people in this match = won this round)
Opponent:King (Might be omitted if the template is smart enough to figure this out from the seeding)
and that is just half of one match! 63 more to go.
There is a lot to enter here but not that much more than for the Wikipedia templates and maybe someone smarter than me can figure a better way to do this (but I don't think so).
Hope this helps. Filceolaire (talk) 10:32, 31 October 2014 (UTC)

Different article types in one Wikidata item[edit]

Can we have both "normal" articles and disambiguation pages in one Wikidata item?

I personnaly think it is the purpose of Wikidata to connect articles about the same topic and it shouldn't matter if, for example, in one language "John Smith" were a lengthy article, while in another language they created a disambiguation page, and yet in another language they formatted it as a list. The topic is the same, they all should be linked to each other.

The question rose in connection to these Wikidata items that now contain links both to articles abd disambiguation pages:

  • Q2954529 - 2006 European Artistic Gymnastics Championships
  • Q2954533 - 2012 European Artistic Gymnastics Championships

In this particular case the problem is that the men's and women's championships are separate competitions officially. But in fact, they are often held at the same arena in consecutive weeks, and people don't think about them as separate events. That's why in some languages there are two separate articles and in some there is only one covering both.

I think the topic is absolutely the same and therefore they all must be connected.

But FakirNL thought there should be 2 separate items, one for disambiguation pages and the other for articles. Like this:

2006 European Artistic Gymnastics Championships

  • [4] - "Wikimedia disambiguation page"
  • [5] - "both men's and women's tournament"

2012 European Artistic Gymnastics Championships

  • [6] - "Wikimedia disambiguation page"
  • [7] - "both men's and women's tournament"

I personally think this is inconvenient cause connecting them all is logical and helps both readers (who will be able to browse articles on the same topic in different languages) and editors (who wlll see there are two articles in English and will understand that there are officially two championships and will write better articles).

What do you think? --Moscow Connection (talk) 13:30, 29 October 2014 (UTC)

Personnaly, I would create separate items as soon as there can be any problem with the interpretation, or when a wikipedia has separate articles. Michiel1972 (talk) 13:45, 29 October 2014 (UTC)
In this particular example, I created separate articles on purpose, especially for the purpose of connecting Wikipedias in different languages. Cause I found many unconnected articles about these championships, and I connected them all. I don't think they should be disconnected now simply because they are "technically" different types of articles according to Wikidata conventions (or whatever).
I was the one who created these disambiguation pages:
and I thought my mission was over cause now everything was connected and it was convenient to browse different languages.
--Moscow Connection (talk) 13:56, 29 October 2014 (UTC)
By the way, one more example:
One is titled "Women's AG Championships" and the other "AG Championships - Women's results". Same topic, but formally someone could argue they should be disconnected simply because one article is an article and the other is a list (a results table). --Moscow Connection (talk) 14:03, 29 October 2014 (UTC)
The Portuguese page of the women's results and the English page of women's results should still be linked together because they are both articles with results tables. Neither of them is truly a list and the difference between them is minimal (the biggest difference is that one also details the juniors results while the other does not). The difference between an article page with both men's and women's results and a disambiguation page however is a lot larger and more fundamental, 2012 European Artistic Gymnastics Championships (Q2954533) still claims to be a "Wikimedia disambiguation page" in both the statements and in several language descriptions. If the statement is removed it will probably be added by a stubborn bot who sees the English page is a DP and automatically assumes the rest is as well.
One option could be to change the English, French (and Norwegian) disambiguation pages into real articles, even though they might still be very short with most of the details still in the separate men's and women's articles. As soon as they are not disambiguation pages anymore, they can be linked. Of course, that's just a solution for this case, and in general I still believe a disambiguation page should not be linked to a non-disambiguation page. - FakirNL (talk) 16:09, 29 October 2014 (UTC)
I think it shouldn't matter if an article is an article or a disambiguation page. If they are about the same thing, they should be linked. I'm sure there are many cases like this in Wikidata. I think we shouldn't disconnect pages about the same thing because of a formal criteria.
And as I said, I created some of these disambiguation pages for the championships specially to connect different languages. Cause they were all disconnected and. for example, if someone in the Portuguese Wikipedia wanted to expand the Portuguese article, they wouldn't see the English article. I think everything should be connected as much s possible. --Moscow Connection (talk) 18:51, 29 October 2014 (UTC)

Another example when there are both articles and disambiguation pages linked together:

Q196756 - Certificate

I think the items should not be disconnected. Cause it's just that in some languages it's created like a disambiguation page and in some it's an article explaining the meaning of the word and listing different types of certificates that exist. Like here:


Or some wikis just explain what certificates are in prose:


And even if the article linked seems about some school certificates:


we shouldn't just go and unlink it. Cause if we do, no one will ever find the article. And now, someone who knows what kind of certificates they call "certificates" in Haiti, will correct it sooner of later or link to some other atticle, about some particular type of certificates. The Haitian Creole entry doesn't do any harm. --Moscow Connection (talk) 19:12, 29 October 2014 (UTC)

The Portuguese page of the women's results and the English page of women's results should still be linked together because they are both articles with results tables. Neither of them is truly a list and the difference between them is minimal (the biggest difference is that one also details the juniors results while the other does not). The difference between an article page with both men's and women's results and a disambiguation page however is a lot larger and more fundamental, 2012 European Artistic Gymnastics Championships (Q2954533) still claims to be a "Wikimedia disambiguation page" in both the statements and in several language descriptions. If the statement is removed it will probably be added by a stubborn bot who sees the English page is a DP and automatically assumes the rest is as well.
One option could be to change the English, French (and Norwegian) disambiguation pages into real articles, even though they might still be very short with most of the details still in the separate men's and women's articles. As soon as they are not disambiguation pages anymore, they can be linked. Of course, that's just a solution for this case, and in general I still believe a disambiguation page should not be linked to a non-disambiguation page. - FakirNL (talk) 16:09, 29 October 2014 (UTC)
I thoroughly agree we should link as much as possible, which is why I want to link disambiguation articles based on their meaning instead of their spelling, but not include different types of links. I would not link any articles to disambiguation pages, redirects, categories, or anything but other articles. Ditto for disambiguation pages and categories. Redirects do not have any place on wikidata. If someone wants to make an interwiki link to a redirect, make it on the local wiki page. The example being the de article about Michael Zehaf-Bibeau that wanted to make a link to the en article about the event (local interwiki links have been added and are waiting to be "sighted"). The only time there should ever be a link to a redirect is when an article is moved to a different title and the old article is a redirect, and only until someone notices that, and edits the wikidata item, correcting the error.See the discussion on redirects. 19:16, 29 October 2014 (UTC)
"Disambiguation pages" are just a type of article, just an artificial type of article. When I created these
I thought they were articles, I intended them to be articles (cause both the men's and the women's tournaments were held at the same venue in consecutive weeks, and many sources regard both championships as the same event), but I tagged them with {{disambiguation}} because they also performed the function of a disambiguation page.
Then someone comes and changes the Russian article into a simple, common disambiguation page:
So, what did he change? He removed a good explanation and removed the links to the official site and to the official results. (I didn't revert cause it's not worth it. I have other things to do.)
And what happens now is that because you think they are disambiguation pages you want to disconnect them. But I when I created them they were articles and for me personally the English one still is.
What I want to say that there's no difference, a so-called "disambiguation page" is an artificial, invented article type.
And what are these?
Are they articles or disambiguation pages? I can tag them as {{disambiguation}} pages right now and I will be right. --Moscow Connection (talk) 21:08, 29 October 2014 (UTC)
Actually, the Esperanto one is tagged as a disambiguation page already.
But this one that says basically the same thing as everywhere else in the lead and then elaborates it, is not:

What about, a special page, that shows a cloud about an article, using connections by items and by properties like part of (P361) and using wikilinks from disambiguation pages to articles, to show a structure with all related pages, whatever the forms of the pages are? --Diwas (talk) 21:42, 29 October 2014 (UTC)

Instead of to a normal wikidata item, when you click on the interwiki link at the left (right for some languages) side of the page, you get a super-link that has a list of multiple places to look for each language? By the way, though, disambiguation pages are as different from articles as categories are from articles. They are only a list of links, and each item on the page can have only one link per item, with a short description of the item. The primary uses are listed first, with a short description of what they have in common, followed by the other uses, and finally a see also section if needed for items that are not spelled the same but are similar, with the rules being the same, only one link per item, no redlinks, if there is no article for the item but another article has something about it link to that. I notice that some languages have redlinks on their disambiguation pages, but they are completely useless, and need to immediately be stubbed into an article that can then be linked through a wikidata item (stubs that have nothing but the article title are completely acceptable, and highly useful once they are interlinked to other languages through wikidata). 07:40, 30 October 2014 (UTC)
(Edit conflict) The special page should directly show the links to articles, maybe like a #combined interwikilink list. It should be able to show you all or only your languages. It can show you more than one link per language, what the sitelink not can do. It should serve total previews of disambiguation pages with live links, and previews of the lead section of articles. – Your idea to have dummy articles: The readers will be unhappy be find empty pages. In the future, there should be another way, to find from a redlink to other languages. --Diwas (talk) 12:02, 30 October 2014 (UTC)
For me there is one simple test: Can we make statements which apply to all the pages linked from this Qitem?
For 'John Smith' we should include all pages for which the statement "Subclass of:John (given name)" and "Subclass of:Smith (family name)" apply. A disambiguation page which is about a random collection of things which happen to have the same spelling is just a disambiguation page. A disambiguation page which links to bunch of related things is a wikidata class and can be described by a wikidata "Subclass of" statement.
The wikidata item for the 2006 gymnastics tournament is a "subclass of:Gymnastics tournament" and "Has part:mens 2006 tournament" and "has part:womens tournament" and any page for which these statements apply can be linked to this item.
It is all in the statements. Filceolaire (talk) 11:30, 30 October 2014 (UTC)
According to your interpretation (which is great, but...), all articles presently linked from Q196756 ("Certificate") can stay there. But... only until someone releases a song or shoots a movie or writes a book titled "Certificate". As soon as someone lists "Certificate (album)", the page must be unlinked. :) --Moscow Connection (talk) 17:53, 30 October 2014 (UTC)
This is the point! On disambiguation page you can found a lot of link not connected to each other. Every wiki have personal rules, but for the disambiguation are all the same (at least I haven't found difference for now): are a collection of link with the same spelling, but not connected together. On disambiguation page I can add every things, so we must keep on disambiguation page only disambiguation page. If some wiki have special case, must be managed in local wiki with old interlink. --ValterVB (talk) 19:48, 30 October 2014 (UTC) Addendum: some wiki, like, have red link on disambiguation page, because they can stimulate the creation of new pages. --ValterVB (talk) 19:50, 30 October 2014 (UTC)
Now I get it! It makes sense! (A disambiguation page lists random articles with the same spelling, while the current articles linked from the Wikidata items "Certificate" and "2006 European Artistic Gymnastics Championships" list articles that are connected to each other. So they aren't really disambiguation pages.) --Moscow Connection (talk) 21:08, 30 October 2014 (UTC)

Maybe the following discussion should be a new section named Links and redlinks in disambiguation pages with the intro: (Spin-off from section #Different article types in one Wikidata item)

Redlinks are encouraged in articles, to stimulate creation of articles, but they are prohibited in disambiguation articles because they are useless - instead of "Huckleberry Finn, a character in Tom Sawyer", it needs to be "Huckleberry Finn, a character in Tom Sawyer", and the redlink for Huckleberry Finn needs to be in the Tom Sawyer article. The reason that dummy articles are super useful, is that from them you can find information from articles in 100 other languages about the subject, to either use, as a reader (especially from languages that you either can read or are somewhat similar to your own, or even that you can translate electronically), or use, as a wiki editor, to flush out the article (you learn to click on the major wiki's like en and de instead of the squiggly named ones - unless you are working on an article about a village in a squiggly character language country). They are incredibly useful for me right now, as I am doing translations for images, and I could care less anything about "Sulfur", all I care about is what it is called in 200+ languages, so that I can use it in the periodic table, so an article without even the name of the article in it is just as useful to me as an article with 100,000 bytes about Sulfur. Yes wikipedia has multiple uses, and no one can say that any one is more important than any other use. But if a particular disambiguation wikidata item, or even all of them, is or are being used only to be about the spelling of those words in the title, that needs to be either in a property or in the description. It clearly can not be assumed that that is what a "disambiguation page" item is for. The Left page certainly was not being used for that - until recently - and is still not being used only for that, as "pages about left as a direction" was recently added, perhaps to explain why the he link was there. 22:19, 30 October 2014 (UTC)
Redlinks in disambiguation page are allowed in itwiki and I saw also in other wiki. If I search "Huckleberry Finn" who can say if I search Huckleberry Finn fictional character or Huckleberry Finn the 1920 movie? Huckleberry Finn Disambiguation page help me. --ValterVB (talk) 22:36, 30 October 2014 (UTC)
I would encourage all of the wikis to prohibit redlinks on disambiguation pages, as they are completely useless. I am not saying the item should not be on the disambiguation page, I am saying that if there is not an article, they need to find an appropriate article to link to instead, for the item. If those are the two items on the disambiguation pages, even a link to an article about fictional characters and an article about novels, or fictional characters, is more useful than making the articles that you want created into redlinks on a disambiguation page. It is sufficient that they are not a link for any editor to notice that and create an article about the subject. No one should be assumed to be so lazy that they can not copy and paste the item into the search box which will then create the redlink for you. 23:51, 30 October 2014 (UTC)
But there are some redlinks to subjects, that have no target, no text about it in wikipedia. --Diwas (talk) 23:58, 30 October 2014 (UTC)
Not a problem. Just stub it, even with nothing in it, and wikidata link it to other articles in other languages. If you mean no article in any language, and that is quite common, still stub it, and create a wikidata item for it, or even just leave it without any link. Someone will come along and create or add to the article. But as a redlink on a disambiguation page it is difficult to obtain any context even. That is the purpose of having a live link to for example "novelist" for, say Samuel Clemens. 00:56, 31 October 2014 (UTC)
This discussion wasn't about red links in disambiguation pages, but about the question whether disambiguation pages can be linked to regular articles on Wikidata. Can I conclude there is no consensus yet? - FakirNL (talk) 10:03, 31 October 2014 (UTC)

Heads up: Mass item creation[edit]

I am (through my bot) in the process of creating ~10K items. Many of these will be duplicates, and merged into other items. But there is madness in the method, which I can't reveal at the moment; it will become clear soon-ish. Please bear with me... --Magnus Manske (talk) 14:35, 29 October 2014 (UTC)

See below :-) --Magnus Manske (talk) 18:18, 29 October 2014 (UTC)

Wikidata turns two![edit]

Hey folks :)

Today Wikidata is turning two. It amazes me what we've achieved in just 2 years. We've built an incredible project that is set out to change the world. Thank you everyone who has been a part of this so far. We've put together some notes and opinions. And there are presents as well! Check them out and leave your birthday wishes: Wikidata:Second Birthday

Cheers --Lydia Pintscher (WMDE) (talk) 17:51, 29 October 2014 (UTC)

So fast! It was just one year, anyway, congrats and thanks to the awesome team! --Stryn (talk) 17:57, 29 October 2014 (UTC)

Congratulations!!! I look forward for the day wikidata will be 10, 20, 30 years old :) Xaris333 (talk) 00:59, 30 October 2014 (UTC)

Birthday gift: Missing Wikipedia language links[edit]

As you know, many Googlers are huge fans of Wikipedia. So here’s a little gift for Wikidata’s second birthday.

Some of my smart colleagues at Google have run a few heuristics and algorithms in order to discover Wikipedia articles in different languages about the same topic which are missing language links between the articles. The results contain more than 35,000 missing links with a high confidence according to these algorithms. We estimate a precision of about 92+% (i.e. we assume that less than 8% of those are wrong, based on our evaluation). The dataset covers 60 Wikipedia language editions. The data is published under CC-0.

What can you do with the data? Since it is CC-0, you can do anything you want, obviously, but here are a few suggestions:

  • There’s a small tool on WMF labs that you can use to verify the links (it displays the articles side by side from a language pair you select, and then you can confirm or contradict the merge). The tool does not do the change in Wikidata itself, though (we thought it would be too invasive if we did that). Instead, the results of the human evaluation are saved on WMF labs. You are welcome to take the tool and extend it with the possibility to upload the change directly on Wikidata, if you so wish, or, once the data is verified, to upload the results.
  • Also, Magnus is already busy uploading the data to the Wikidata game, so you can very soon also play the merge game on the data directly. He is also creating the missing items on Wikidata. Thanks Magnus for a very pleasant cooperation!

I want to call out to my colleagues at Google who created the dataset - Jiang Bian and Si Li - and to Yicheng Huang, the intern who developed the tool on labs.

I hope that this small data release can help a little with further improving the quality of Wikidata and Wikipedia! Thank you all, you are awesome! Happy Birthday! --Denny (talk) 18:03, 29 October 2014 (UTC)

Fantastic! Can't wait to play it, I already logged in. But I have a problem! QuickStart banners.png. I suggest that you use the HTML from action=render rather than frames, it will be much faster and reliable. --Nemo 19:21, 29 October 2014 (UTC) P.s.: I'm logged in and hard refresh didn't help, no idea what's going on here. I can't play with this bug. :( I'll wait for Magnus or action=render.
Ouch! Doesn't edit=render though mess up all the CSS? (iirc, when I was trying it out) --Denny (talk) 19:31, 29 October 2014 (UTC)
I think using the mobile version of the website might also do the job. -- Bene* talk 21:12, 29 October 2014 (UTC)
Bene*, the mobile site has banners as well now. Denny, I'm not sure about CSS but the essential content should get through; mw:API:Parsing wikitext is supposed to contain the necessary information. --Nemo 08:40, 30 October 2014 (UTC)
We'll probably won't be working on the code - but anyone feel free to fix it. Or wait until Magnus is finished with loading :) --Denny (talk) 22:24, 29 October 2014 (UTC)
@Denny, Anorange0409: If you want to upload the change, please make "Edit existing pages" applicable to consumer.--GZWDer (talk) 12:25, 30 October 2014 (UTC)
@Denny: Awesome! However, I cannot use the tool with my user name (note á and ě). It shows me an SQL error:

Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' . I have to use my bot's account (MatSuBot) and it works there. Matěj Suchánek (talk) 15:01, 30 October 2014 (UTC)

Birthday gift #2: Cupcake Userbox[edit]

Thanks everybody for making this such a great project: See: Wikidata:Userboxes

Wikidata cupcake II.svg This user is celebrating Wikidata's 2nd birthday.

Tobias1984 (talk) 21:08, 29 October 2014 (UTC)

Wow, I'd forgotten that today was Wikidata's second birthday. I'm not that active here anymore, I guess. Anyway, congrats to everyone who has contributed. --Jakob (talk) 19:15, 30 October 2014 (UTC)

Problem with wikidata in greek[edit]

Hello. There is a problem with wikidata in Greek. In English version we have

Wikipedia pages linked to this item (3 entries) [edit]

In Greek language the sentence is too big and the word καταχωρήσεις (entries) is above [επεξεργασία] (edit). The problem is the same also for wikinews, wikiquote, wikisource, wikivoyage and Pages on other sites linked to this item. Can be solved? Xaris333 (talk) 01:10, 30 October 2014 (UTC)

The problem (I think) is that css class wikibase-toolbar-container has position:absolute (somewhere) and needs to be moved about 180 pixels to the right because long headings are expanding on top of the span. -geraki talk 06:40, 30 October 2014 (UTC)

Can anyone solve the problem? Xaris333 (talk) 12:37, 30 October 2014 (UTC)

Maybe this help you understand the problem... Xaris333 (talk) 00:00, 31 October 2014 (UTC)

Wikidata Greek problem

Yes, someone needs to create a shorter translation than "Σελίδες της Βικιπαίδειας που συνδέονται με αυτό το αντικείμενο" (Wikipedia pages for this item),[8] like "Σελίδες της Βικιπαίδειας". 01:21, 31 October 2014 (UTC)
Ok, where I can do that? Xaris333 (talk) 09:55, 31 October 2014 (UTC)

Little technical problem with Wikipedia:Goings-on (Q5268366)[edit]

I got Wikipedia:Goings-on (Q5268366) in "no-statements" - but I have not link/button to add a claim… do you have the same problem ?

thanks for fixing it, if possible :) --Hsarrazin (talk) 21:58, 30 October 2014 (UTC)

I have it (IE 11). --ValterVB (talk) 22:13, 30 October 2014 (UTC)
I guess, you are an admin, Hsarrazin is not? logs? --Diwas (talk) 23:50, 30 October 2014 (UTC)
Protected (admins only) on 15 January 2014. 00:41, 31 October 2014 (UTC)
You can either use {{Editprotected}} on the talk page or post a request on the admin notice board. 01:31, 31 October 2014 (UTC)

Seeking feedback for planned edits related to my project[edit]

Hi. I have a research project exploring the history of the Esperanto movement. I am digitizing an address book of pioneer Esperantists, which contains information about 21,594 people who learned Esperanto between 1889 a 1909, about 8 % of whom are notable on Esperanto Wikipedia and perhaps other language Wikipedias. In the process, I use links to Wikidata items to uniquely identify old states, regions and places that appear in the address book. Sometimes, the corresponding items do not have geographical coordinates yet, which I need to obtain in order to be able to display all the people on a map. Eventually, I would like to link the notable people to their Wikidata items and store their number in that address book within the item, so that it can later be used in the eo:Ŝablono:Informkesto esperantisto infobox and alike.

Before I proceed to mass edits, I would like to ask someone for feedback on my current idea of how those information that I can give back to Wikidata should be structured. If you think you can help me, please review Q1010812#P625 as an example of how I plan to add geographical coordinates to a historic region (I have written a bot that looks up the capital of that region in Russian Wikipedia's infobox and takes those – and I try to express this in references), and also Q18413#P106 as an example of how I currently note the person's number in the address book (as a reference for the fact of him/her being an Esperantist). Do you think it might be useful if I request creating a new property for the number/ID of the person in that database? The list is closed, but those people on it used to refer to themselves using that number as a kind of unique ID in the past. I can imagine that having that ID in a property of its own would make it easier to access it from within an infobox and pointing Wikidata users to the corresponding line in the digitalized address book (which I plan to post on Wikisource). I will be glad for any suggestions. --Blahma (talk) 11:49, 31 October 2014 (UTC)