Wikidata:Project chat/Archive/2013/08

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

Marine technology

I have a data base of 300 companies in Marine Technology, an economic area I believe will experience rapid growth over the near term. I would like to expand this list by allowing anyone to log in and list their company, education program etc. I do not believe that any such data base currently exists. Can I do this through wikidata? -- Special:Contributions/

I don't believe that this kind of thing is what WikiData is for. I think you might need to create your own website, perhaps a Wikia instead. Best wishes for your ventures, AutomaticStrikeout 02:41, 1 August 2013 (UTC)

Search does not provide results

Search does not provide the data item shown

I am the author of a lot of Egyptian sites at Wikivoyage which were often not described in the Wikipedias in Western languages. A search for the Arabic terms fails even in the case of existing data item descriptions as shown at the screenshot. It seems that the search is executed only in one language, the user's language. --RolandUnger (talk) 05:19, 25 July 2013 (UTC)

Yes. The assumption is that you only search in your own language. If you are using the German interface, why do you search for the Arabic written name? Isn't that like searching for 'gift' on the English interface, and expecting poison (German: Gift) instead of a present (English: gift)?
The other option would be to make the search go on in all languages. Would the community prefer that? It would extremely increase recall, but I am worried about precision. --Denny (talk) 15:57, 26 July 2013 (UTC)
I prefer a simple advanced search option because for example I wont create an item "the little big wikidata in arabian" in english don't exist but maybe in ar.wi this article exist, how I can search it on all wikidata? Rippitippi (talk) 16:10, 26 July 2013 (UTC)
Sorry, Rippitippi, I didn't understand that. If you search for "the little big Wikidata in Arabithe little big Wikidata in Arabianthe little big Wikidata in Arabian", i.e. using a potential English label, the existence of an item connected to arwiki but without an English label would not show up no matter whether we would search over the Arabic labels as well or not. Maybe I am misunderstanding? --Denny (talk) 14:29, 28 July 2013 (UTC)
If I search "وWikidata قليلا كبيرة في العربية" (the little big Wikidata in Arabic) I've not result because my default language is english Rippitippi (talk) 11:09, 1 August 2013 (UTC)

fallback languages in item label & descriptions display

It seems that models like {{Q}} and {{Autodescription}} uses Babel fallback languages, and it can make hard for an item to see whether or not it as a label in our main languages, especially for artwork titles or places name which are maybe not translated. Is it possible to display this information one way on another (I mean the information that it's not our main language that is displayed) ?  – The preceding unsigned comment was added by TomT0m (talk • contribs).

+1 useful also for Wikidata:Labels and descriptions task force --ValterVB (talk) 13:56, 28 July 2013 (UTC)
Basically, everything produced by any fallback chain would benefit from being marked as such. But how? *Asterisk? Littledogboy (talk) 13:47, 29 July 2013 (UTC)
Or postfixed by (en) for example. TomT0m (talk) 13:52, 29 July 2013 (UTC)
This should be an easy task for a user script: Just attach content of the "lang" tag to any span of class "wb-itemlink-label" (if lang does not equal the user language). --YMS (talk) 14:16, 29 July 2013 (UTC)
It's a poor and unfortunate workaround to do that by a userscript, it should work for vocal readers as well, and I'm not sure the {{Q}}, {{Label}} and {{Autodescription}} would work with that. It should be done with with the information, and with a global CSS. (for example this code : <p><a href="/wiki/Q23936" title="Q23936">Bassoon Quintet <small>(Q23936)</small></a> is taken from the HTML generated from User:ValterVBot/Labels_and_descriptions/fr/1 for an item which do not have a label in french. The Bassoon Quintet english label is displayed without any language information neither in the HTML or in the display result. I don't think e can guess that even with a ugly script. TomT0m (talk) 15:58, 29 July 2013 (UTC)
Add lang="xx" to {{Label}} and {{Autodescription}}? (like this <span lang={{int:Lang}}> ??) Littledogboy (talk) 17:50, 1 August 2013 (UTC)

Notification emails with incorrect links


I've set my preferences to receive an email when a page in my watch list is modified. Each time I receive a mail, but the links in it are wrong.

For example, there's in the email: See for all changes since your last visit.

It's a mail for page, but the link doesn't work. --NicoV (talk) 06:51, 30 July 2013 (UTC)

I think you're talking about this: bugzilla:49434. --Tobias1984 (talk) 19:24, 30 July 2013 (UTC)
Yes, thanks. --NicoV (talk) 17:12, 1 August 2013 (UTC)

voy->wiki bug

can't add directly from voy a voice to an existing item on data if the item has only wikipedia link Rippitippi (talk) 10:22, 1 August 2013 (UTC)

Which WV item are you trying to link to? 13:10, 1 August 2013 (UTC)
whatever, you can link item only between lang.Voyage for ex. [1]Rippitippi (talk) 13:56, 1 August 2013 (UTC)

Bot needed for disambiguation pages

Does anyone have a bot that could change every instance of P107 (P107) Q11651459 to instance of (P31) Wikimedia disambiguation page (Q13416711)? Then we can delete Q11651459. Filceolaire (talk) 16:12, 1 August 2013 (UTC)

Not only wikipedia link disambiguation items, voy too, this is not possible Rippitippi (talk) 16:26, 1 August 2013 (UTC)
I have started a discussion on the P107 talk page Filceolaire (talk) 19:12, 1 August 2013 (UTC)

CheckUser policy RfC

Comments are sought at Wikidata:Requests for comment/Defining CheckUser. This RfC seeks to define our local CheckUser policy. Note that this is not a solicitation for CheckUser candidates as there is no current need for local CheckUsers.--Jasper Deng (talk) 22:11, 1 August 2013 (UTC)

WLM and WD (notability question)

I am one of volunteers who organize WLM (it is yearly international contest organized by WMF and chapters). I am dealing with lists of heritage objects in Ukraine. Now these lists a stored in Wikipedia (example here). And I have an idea to store these lists here in WD (each object will have its own item). It is possible to organize if create needed properties. But there is a problem: many of heritage objects have not articles about them and they will not fall under WD:N. How to solve this problem? Is it possible to change WD:N for this?--Ahonc (talk) 23:32, 1 August 2013 (UTC)

See criteria #2 and #3 at WD:N. We should not need to change the policy for this. --Jakob (Scream about the things I've broken) 00:05, 2 August 2013 (UTC)
Creating items for those buildings and memorials seems fine to me. I'm wondering if you can construct statements with existing properties. e.g. part of (P361) = UNESCO World Heritage Site (Q9259)? You can also fill in all the geographic properties. Source should probably be the website of the organization that gives out these IDs that are in the first column of your link. --Tobias1984 (talk) 05:43, 2 August 2013 (UTC)
Few of these possible items are UNESCO's heritage but still all these objects are notable for separate articles (as they are regional or national heritage) but have too little data to be represented separate article way. When phase 3 will be enabled it will became very important for these data to be on wd as we have also main namespace's lists of cultural heritage and its important to make such lists easily transferable crosswiki, easily updateble and readable by bots etc. Perhaps they will also have some use on Wikivoyage later. Another solution could be creating something like wlmwiki, where we will be able to create separate article for each object, with supporting it by wd but then its discussion for metawiki for creating procedure. --Base (talk) 06:43, 2 August 2013 (UTC)

Fallback languages

What happened to fallback languages? Before I saw only English labels if there was not Finnish labels. Now I see Swedish label as a title on Q4387047, when there is also English label... I would like to see English title instead of Swedish. --Stryn (talk) 06:06, 23 July 2013 (UTC)

Well, I guess I need to learn more Swedish language then... --Stryn (talk) 13:20, 26 July 2013 (UTC)
I've noticed some surprising behaviour, too. Something to do with Assistant languages in Special:Preferences#mw-prefsection-editing?? Littledogboy (talk) 13:40, 26 July 2013 (UTC)
I don't think so... I have there only Finnish language. --Stryn (talk) 13:44, 26 July 2013 (UTC)
OK, I'll add details. When I'm switched to Czech, I see pl rather than en, when cs is missing. The default fallback chain for cs should be cs-sk-en full stop. Littledogboy (talk) 13:50, 26 July 2013 (UTC)
Actually it would be nice if each user could define that in their preferences or with the babel template. --Tobias1984 (talk) 14:44, 26 July 2013 (UTC)
+1. Littledogboy (talk) 15:35, 26 July 2013 (UTC)
Liangent, one of our Google Summer of Code students, is working on language fallbacks. I asked her to comment here. --Lydia Pintscher (WMDE) (talk) 18:00, 26 July 2013 (UTC)

For short-term solution, wgBabelCategoryNames (for mw:Extension:Babel) should to be configured on this wiki, so your user pages are categorized into Category:User en-2 instead of just Category:User en, then Babel::getUserLanguages() is able to read it. For longer-term solution, Babel::getUserLanguages() needs to be fixed to remove dependency of categories, and return whatever you put on your user pages no matter whether there are related categories (there's already a TODO there above that function). Liangent (talk) 10:09, 27 July 2013 (UTC)

By the way you can check your fallback chain on Special:MyLanguageFallbackChain. Liangent (talk) 10:15, 27 July 2013 (UTC)
Hi Liangent, great to hear you're doing good work and thanks for the information. I think my babel is set up correctly, yet when switched to cs, I can see label for Campbell's Soup Cans (Q2697937) in pl, not en – I see "Puszki z zupą firmy Campbell". Why might that be? Littledogboy (talk) 10:58, 27 July 2013 (UTC)
More details for you: Also sk and es have priority over en. Bizarrely, for an item that has an en label and description, I am shown pl label with es description in my watchlist. It seems to be upside down. Littledogboy (talk) 11:50, 27 July 2013 (UTC)
The problem is, as I mentioned above, without those categories the Babel extension doesn't understand that "you prefer English more than Slovak and Spanish", and instead, it (thus Wikibase) assumes you're native to all cs, en, es, sk, pl and your current user interface language with no difference at all. In this case a fallback chain in whatever order looks sane to me. Liangent (talk) 12:07, 27 July 2013 (UTC)

A little personal request: can you refer to languages using their codes instead of names? I find it more or less difficult for me to correlate language native names, their names in English, and their codes. Liangent (talk) 12:12, 27 July 2013 (UTC)

(changed into codes)
Oh, ok, now I understand. Thanks for being patient with the less technically gifted! So you are working on fixing this?
(There is one more thing – babel does not reflect the difference between active and passive knowledge of a language. For example, a native sk speaker will understand 99.9% of cs, but will not be able to produce texts in cs – this is called passive knowledge of a language. This is not reflected by babel. I understand this may go beyond the scope of what can be done, though.) Littledogboy (talk) 13:11, 27 July 2013 (UTC)
I'm not working on this NOW but I wonder the reason that wgBabelCategoryNames is not configured here yet. Is it simply because nobody worked on it, or you had some discussion and decided not to use it (Category:User en-2 categories)? Liangent (talk) 13:32, 27 July 2013 (UTC)
No, we didn't have any discussions about that. Maybe we should make a bugzilla request to enable wgBabelCategoryNames here. Maybe this have been built with the same settings than in Meta-wiki, where also are not these categories. --Stryn (talk) 13:38, 27 July 2013 (UTC)
So how many levels need to be considered? For example, enwiki uses level 1 to 5 plus N(ative), while enwikiversity uses level 0 ~ 4 + N. Liangent (talk) 13:47, 27 July 2013 (UTC)
From what I've seen, 0 ~ 5 + N. Look here. Littledogboy (talk) 13:51, 27 July 2013 (UTC)
Where do you see -5? Vogone talk 14:41, 27 July 2013 (UTC)
User:Amire80. Littledogboy (talk) 15:03, 27 July 2013 (UTC)
bugzilla:52145 + bugzilla:52144 (for the underlying Babel bug). Liangent (talk) 13:59, 27 July 2013 (UTC)
The original issue should have been resolved by the configuration change. I'm not sure how heavy Babel is depending on cached data (if there's any left). If something is still going wrong, please null edit your user page first and try again. Liangent (talk) 07:28, 31 July 2013 (UTC)
About that sk / cs issue: are our interface messages for sk users falling back to cs currently? If so, Wikibase does this too (with some exception noted below); if not, how can Wikibase know this info before you told me here ;)
The exception: if that sk user specified another language in Babel, and a label in that language happens to exist, then that label still overrides the cs one. Even with the message fallback info from core, Wikibase is still unaware of how similar they're, and it seems more safe to use another language that the user explicitly states to be able to use. Liangent (talk) 13:59, 27 July 2013 (UTC)
System messages fall back to en. You are right, languages can often be connected to people's feelings, so we should be careful. I'd rather ask in cs and sk communities first. There may be other similar cases, such as ca (falling back to es, rather than en), not sure about da/no/nn...? So this is possible, then? You can change those default fallback setting for system messages, if those communities agree? Littledogboy (talk) 14:21, 27 July 2013 (UTC)

Liangent, I started researching the topic, and I've identified some mutually intelligible pairs, which would be my first candidates for default fallback chain:

  • cs/sk
  • mo/ro
  • ca/oc (->fr?)
  • gl->pt
  • nb/nn(/da/sv/no??)
  • az/tr(fa??)
  • scn->it
  • gsw->de?

Let me know whether you are interested in developing this, as we'd have to ask those communities and open a RfC. I think thic could be beneficial for small languages and would enrich the multilingual aspect of Wikidata. Best, Littledogboy (talk) 16:41, 29 July 2013 (UTC)

mo->ro, gl->pt, scn->it, gsw->de are already included in fallback chains taken from MediaWiki core (which are also used for message and a few other fallbacks). As I can speak none of these languages, I don't think I can make a good decision myself. If you'd like to start some community talk, it could be nice to have fallbacks needed at other places (system messages etc.) discussed together. Liangent (talk) 07:36, 31 July 2013 (UTC)
Wow, we've made some progress! So far only through Babel, and not for system messages, only for entity names in history, but not in item view. But it's a start! – Would you please give me the link to the list of MediaWiki core fallback chains? Littledogboy (talk) 00:03, 1 August 2013 (UTC)
This is odd, I'm not the only one! Seems "cs-N" is handled differently from "cs"? Littledogboy (talk) 15:20, 1 August 2013 (UTC)
Oh, and one more thing – I've tried IE, just in case it was a cache issue (it wasn't).... and IE offered me to switch to British English (en-GB)... and, as you probably know, what followed wasn't pretty. Littledogboy (talk) 18:32, 1 August 2013 (UTC)
I don't know where a full list of fallback chains is, but for example you can go to [2] and see that $fallback = 'de'; there.
btw. xx and xx-N seem to be treated identically in my test? [3] Liangent (talk) 14:32, 2 August 2013 (UTC)
Yeah, that's fine, a blank edit of users home page, and they show up in the category. Perfect! Littledogboy (talk) 17:37, 2 August 2013 (UTC)
I've already mentioned it above at 07:28, 31 July 2013 (UTC). Liangent (talk) 18:13, 2 August 2013 (UTC)
Hmm, everyone's user pages. Looking at the link you provided, en is not a fallback language for en-GB, it seems... Littledogboy (talk) 18:24, 2 August 2013 (UTC)

How do we merge 2 items?

Hi, and pardon my newbish question. Currently we have 2 items on same topic it's Q723931 Material Point and Q1068091 Point Particle. I'm not physicist myself, but articles on different Wikipedias seem to talk about same thing, so I believe it was translation issue, which brought this division. So my question is how do we merge 2 items into one on Wikidata?

Thanks --Xelgen (talk) 21:20, 31 July 2013 (UTC)

They cannot be merged. The two items have different focus: mass point (Q723931) is about the abstraction that the mass of a body is in one dimensionless point, point particle (Q1068091) is more general about considering a body as dimensionless with regards to more physical properties. You can also see that some Wikipedias have articles connected to both items. You can read about how to merge (for items which can be merged) at Help:Merge. Byrial (talk) 22:49, 31 July 2013 (UTC)
Is this (that they cannot be merged) your opinion, or statement of some rules? Your interpretation seems lacking to me, and from what I can see, there is only one wikipedia (cs) that has separate articles representing the two "different foci". But whatever the physics (or any other) interpretation may be, this is a problem. English wiki can call its article on "material point" or "point mass" whatever it wants, but if a link to this article cannot be shown from other language versions, because it's linked from "material point" and not "point particle", then this becomes a problem (one which wasn't there with old interwiki links). So if there is no technical way to somehow merge the two entries without "renaming" one of them, then one should be renaimed! Teak (talk) 10:40, 1 August 2013 (UTC)
It is my opinion about content (based on svwiki and dewiki for mass point (Q723931), and on enwiki and nowiki for point particle (Q1068091)). But it is not possible to merge as long as some Wikipedias have pages connected to both items. Besides cswiki it is also jawiki, ptwiki, zhwiki. You will have to convince those Wikipedias to merge their articles before it will be possible to merge the items at Wikidata. Byrial (talk) 12:49, 1 August 2013 (UTC)
Thanks for pointing those out. This appears to be a lot more messed up than I thought: the two articles on ptwiki are "point mass" and "material point". Unfortunatelly, I can't compare the different articles in jawiki and zhwiki. But apparently there is an issue, to which the needed solution may end up being technical. Do you know why it is not allowed to add a section of an article to a data item. Say adding en:Point_particle#Point_mass to mass point (Q723931), and en:Point_particle#Point_charge to point charge (Q439029), while the article itself remains connected to point particle (Q1068091)? ― Teak (talk) 16:16, 1 August 2013 (UTC)
enwiki has en:Point mass and en:Point charge which are redirects to en:Point particle. It is decided in a RFC that it should be allowed to add such redirects to other ietems like mass point (Q723931) and point charge (Q439029). Now we are waiting for that to be technically possible. Byrial (talk) 16:55, 1 August 2013 (UTC)
Thanks for the explanation. Hope it will be implemented soon. ― Teak (talk) 15:56, 2 August 2013 (UTC)

Editwarring with bots

User:JAnDbot insists on adding a wrong property to informatics (Q4027615) [4] [5]. On JAn's advice I changed the value to "none" instead. Now User:KrBot deleted the property again [6]. I'm quite convinced User:JAnDbot will now add the wrong category back again very soon. Who can I blame for this? —Ruud 10:20, 2 August 2013 (UTC)

JAn properly did not mean the string "none" (which clearly is wrong, and rightly was removed because there is no Commons catagery with that name) but the special value type "novalue" meaning that no value exist for the property. I have added that now. Byrial (talk) 10:56, 2 August 2013 (UTC)
JAnDbot is adding valuses from cs:Kategorie:Commonscat_není_na_Wikidatech. As you can see, A-H is nearly solved - what does not exist (KRbot delete it from wikidata again), I delete template in article, so bot cannot add it again. JAn Dudík (talk) 21:00, 2 August 2013 (UTC)

property index counting bug

It seems, when you're trying to create a property with a label that already exist in the same language, you're getting an error, but the property index counter netherles increases. I had chosen the wrong data type for Property:P752 (someone please delete it) and after that I tried to create a new property with the proper data type. I clicked several times the "create" button and getting an error. Then I changed the label of the wrong property and tried again. It works, but the property has now the 756 (Property:P756). And there is no Property:P753, Property:P754 and Property:P755. So the counter should increase only if the property has successfully created. --Nightwish62 (talk) 15:14, 2 August 2013 (UTC)

Property deleted. John F. Lewis (talk) 16:38, 2 August 2013 (UTC)
Thank you. Could someone confirm the bug and make an entry to bugzilla? --Nightwish62 (talk) 17:04, 2 August 2013 (UTC)
Why do you did consider it a bug? I do not. It is no problem that some numbers are not used. Byrial (talk) 18:10, 2 August 2013 (UTC)
It looks like those were never created, at least I can not find any trace of deletion.--Ymblanter (talk) 19:22, 2 August 2013 (UTC)
Yeah, I know: It's not a bug, it's a feature. Consider this: If someone like he can write a script to exploit this %howeveryoucallit% and increase the property index up to 10'000 or more just in a few minutes. I don't know if there is an API function to create property, but even when not, it's possible by scripting automatically keyboard inputs. Yes, I'm sure someone of the developers is able to set the index to the next free number again, but it's not the goal to fix problems which caused through vulnerability. Even it's not a security vulnerability, we certainly don't want to have unnecessary gaps in the property counting. Therefore it's a bug in my opinion. --Nightwish62 (talk) 20:35, 2 August 2013 (UTC)
Or we could assume that people who have the property creator user right are competent enough to avoid doing this. :-) Mergehappy (talk) 21:42, 2 August 2013 (UTC)
Yes, it is possible to make a bot solely to quickly increase the property index, but I still fail to see why it is a problem that some numbers are missing because of mistakes. Even if what you call a bug is fixed so not created entities do not any longer use an index number, you can still increase the index by making a bot to create a lot of technically valid, but useless entities which have to be deleted again. So as we cannot prevent disruptive editing (except for blocking when it is started), I really don't care if one way more or less to do it exists. Byrial (talk) 21:54, 2 August 2013 (UTC)

Tracking laws

I have proposed creation of a property: Wikidata:Property_proposal/Sister_projects#legislative_enactment_(en) to enable documents to be marked as legislative enactments, of which Wikisource has a growing number (along with tables of enactements) . I have contributed to efforts in compiling these tables and in transcribing an archive table of data concerncing pre 20th enactments.

I am making the above because the current approach is to use lists or tables in articles directly at Wikipedia/Wiksource, and to me it would be more efficient to track the metadata on Wikidata ( such as Short Titles, enactment dates and repeals) so that the tables can be maintained in a single location rather than several.

It is also intended that by creating a sutiable Wikidata model, data from official 'free' sources such as the Library Of Congrees (for the US) or the UK National Archives ( which runs the UK Statute Law Database) could from time to time be imported, making the update process semi automated and thus less tedious for contributors.

This would however require a major effort and hence given my own inexperience with Wikidata, feedback and assistance from the existing Wikidata community would be greatly appreciated on how infromation on legislative enactments can or should be stored.

Sfan00 IMG (talk) 14:45, 2 August 2013 (UTC)

I don't think this needs a new Property. Use 'instance of (P31)' to refer to a 'legislative_enactment' item. Filceolaire (talk) 20:05, 2 August 2013 (UTC)
OK. How do you suggest I put the qualifers in? Sfan00 IMG (talk) 08:13, 3 August 2013 (UTC)
Exactly the same way you would for qualifiers to any other property.
  • Create a new item in Wikidata for this wikisource document.
  • Give it the usual document properties - date published, official name (property pending), author etc.
  • Add the 'instance of' 'legislative enactment' statement.
  • Refer to this item from any other item using the 'stated in' property.
Hmm. Looking at that I'm not sure where you need to use qualifiers. Filceolaire (talk) 13:16, 3 August 2013 (UTC)
OK , But I would like to add, <repealed by>, <amended by> and other tags present in the Wikipedia infobox legislation template, as well as the data pulled from wikisource ( where the Statute table I was contributing to is largely template based)

Lets change 'Project' to 'Wikimedia'

On a number of items 'Project' has been used to say the item refers to both Wikipedia and Wikivoyage pages. eg 'Wikimedia category (Q4167836).

In my opinion Project is the wrong word to use here because there are lots of projects out there which have nothing to do with Wikimedia. For the same reason I would object to using 'wiki' to refer to the Wikimedia projects. There are lots of wikis which are not wikimedia projects.

I think we should use 'Wikimedia' instead; so 'Wikimedia category (Q4167836)' will become 'Wikimedia Category page' and similarly for other non-article classes.

Any comments? Filceolaire (talk) 13:03, 3 August 2013 (UTC)

English label is 'Project', many other languages use 'wikipedia'.--Vyom25 (talk) 13:59, 3 August 2013 (UTC)
Well, You may change the English label in Q4167836 to whatever you like, it does not affect any other languages. -- Lavallen (block) 14:28, 3 August 2013 (UTC)
Done. Filceolaire (talk) 16:13, 3 August 2013 (UTC)

Policies, guidelines, and other-language participation

I've been noticing on RFCs and other proposals that it seems like primarily English-language speakers are making an appearance to talk about the proposals. I have queried a few people and they feel the same way.

Would there be support for a bot, or something to that effect, which would notify the non-English (and even the English) Project Chats about new RFCs and proposals on various pages? --Izno (talk) 01:36, 3 August 2013 (UTC)

That does seem like a good idea. AutomaticStrikeout 01:42, 3 August 2013 (UTC)
  Strong support --Tobias1984 (talk) 07:48, 3 August 2013 (UTC)
  Support, but this is not enough - we also need active translation of RfC sections to major languages.--Jasper Deng (talk) 21:22, 3 August 2013 (UTC)
Well, I do not think the language is the main problem, it's the references to policies on projects I am not active on and a RfC-sheme I am not used to. A large problem with the translations both here and on translatewiki is that the content, culture and the background are completly missing. When you are asked to translate only one sentence or maybe only one or two words, without understanding how it will be used, you are completly lost. To often in Swedish software, I have been asked if I want to Finish? Guess if I was puzzled the first time!!! Often I have to think what the original message in English could have been, and try to see if there could be any other possible translation.
Many I know, who have at least a little understanding of English, prefer to have OS and other softwares installed in English on their computers, to have less problems with machine-translated manuals. Microsoft Excel is useless in the translated version for example. -- Lavallen (block) 10:25, 4 August 2013 (UTC)
Lavallen, perfect point. I couldn't agree more. That is why while translating a policy page I tend to keep the English page open so that I can understand what is the context of the sentence or word. But while translating singular sentence or a word most of guys are clueless about context. For indic languages machine translation is crappy at best so it is better to not use it.--Vyom25 (talk) 13:33, 4 August 2013 (UTC)

Cleaning up Special:UnconnectedPages

In zh-yuewiki, there are over 500 articles not connected to Wikidata items but with interlanguage links. Is there any quick way to link them with Wikidata, instead of linking them manually one-by-one? --Sadodiego (talk) 05:46, 3 August 2013 (UTC)

A bot could connect them but there must be at least one old interwiki link in each article. Matěj Suchánek (talk) 06:13, 3 August 2013 (UTC)
According to Special:UnconnectedPages, about 600 articles have at least one old interwiki link, but where can I find a bot for help?--Sadodiego (talk) 07:43, 3 August 2013 (UTC)
My bot has permission to do that. That's an example: importing sitelink and removing interwiki links. It is a global bot, too, so I'm starting a test run ASAP. --Ricordisamoa 07:46, 3 August 2013 (UTC)
Thank you very much for your help. --Sadodiego (talk) 08:07, 3 August 2013 (UTC)
I saw that most of the pages are user pages. I think user pages are not included in wikidata. --Napoleon.tan (talk) 15:31, 3 August 2013 (UTC)
This is because Ricordi's bot has already done most of his work on article namespace. Still there are over 1,000 non-userpage pages need cleaning up. --Sadodiego (talk) 01:02, 4 August 2013 (UTC)
Yes, user pages are excluded, and the bot will not remove interwikis from them (nor create any new item). I'm going to fix some minor issues and complete the run in few hours. Regards, --Ricordisamoa 07:26, 4 August 2013 (UTC)

Disambiguation pages

At present disambiguation pages have various statements attached. Some have 'P107 (P107) Q11651459'. Since the recent RFC on P107 (P107) it was agreed that P107 (P107) should only be used with GND types so it should not be used with Q11651459. 'instance of (P31)' should be used instead. We have three options for items to use with instance of (P31).

This is the item which has been used with P107 (P107) on lots of existing disambiguation pages.
It has no site links. Filceolaire (talk) 12:50, 3 August 2013 (UTC)
  Comment I suppose we could use this one just for name disambiguation pages. Filceolaire (talk) 13:25, 3 August 2013 (UTC)
This has 84 sitelinks to Wikipedia pages and 7 sitelinks to Wikivoyage pages. It does not seem to have been used for any statements on disambiguation pages. Filceolaire (talk) 12:50, 3 August 2013 (UTC)
  Support I like this one because it has the site links. Filceolaire (talk) 13:04, 3 August 2013 (UTC)
  Support simple & fits; do it.  — Felix Reimann (talk) 13:24, 3 August 2013 (UTC)
  Support--Saehrimnir (talk) 16:32, 4 August 2013 (UTC)
This has been used with 'instance of (P31)' on some disambiguation pages (mostly by me).
It has no site links. Filceolaire (talk) 12:50, 3 August 2013 (UTC)

Meetup, talks/panel and dev camp at Wikimania

Heya folks :)

If you're at Wikimania please come to the Wikidata meetup in the chapters village on Saturday at 1PM. I'd love to meet as many of you as possible. And of course also consider coming to one of the Wikidata talks or panels. There is also the dev camp which will have Wikidata hacking and dev tutorials. Greetings from Taipei. Hope to see many of you next week!

Cheers --Lydia Pintscher (WMDE) (talk) 15:16, 4 August 2013 (UTC)

I think we have a new problem with the property imported from Wikimedia project (P143): from a temporary property it became a widely used property to "source" data from wikipedia without checking if the real sources exist in the wikipedia articles. This leads to a big problem of circular reference: wikipedia articles sources with wikipedia. But since a certain time imported from Wikimedia project (P143) is used to source original work of bots like defining the sex of persons from the first name. See this bot request Wikidata:Bot_requests#Set_sex:male_for_item_list and this kind of data generation is sourced with imported from Wikimedia project (P143):full name (Q1071027) which is a very large interpretation of the original use of imported from Wikimedia project (P143). We definitevely need to define the framework of the use of property imported from Wikimedia project (P143) and the requirements for bots during data imports. We need to define what is the priority of wikidata: have a lot of data but a certain part of unreliability or take the time to build a strong database with reliable data. Snipre (talk) 22:34, 2 August 2013 (UTC)

That's a misuse of imported from, definitely. --Izno (talk) 01:22, 3 August 2013 (UTC)
I am not going to source anything with full name (Q1071027), until this discussion is closed. --Ricordisamoa 07:06, 3 August 2013 (UTC)
You often need to know the nationality to know the sex of a person anyway. My first name is almost always male where I live, but more often female in USA. -- Lavallen (block) 14:35, 3 August 2013 (UTC)
I don't see how Wikidata could be a serious framework for migration of Wikipedias infoboxes if it could not import datas from Wikipedias infoboxes at all, where in my experience almost all Wikidatas infoboxes infos are not sourced, and certainly not statement by statement. TomT0m (talk) 20:45, 4 August 2013 (UTC)
Wikipedia sourced with wikpedia, is it not something stupid especially about an encyclopedia ? And if you have a problem with the sources just go on the different wikipedians and ask if wikipedians will used wikidata data imported from english, german, french, italian,... wikipedia without any source. Sourcing is not a stupid idea of some wikidata contributors it was asked by wikipedians in preliminary discussions. Snipre (talk) 17:45, 5 August 2013 (UTC)
I explained and argued my point of view several times there. I have nothing to add except that the RfC is not closed yet. TomT0m (talk) 18:07, 5 August 2013 (UTC)


As a source for Riograndense Republic (Q162192) I have created História da Grande Revolução (Q14474073) with Alfredo Varela (Q14474103) (author) and Instituto Histórico e Geográfico do Rio Grande do Sul (Q14474184) (publisher).

Did I get it right? Is this how sources should work? Filceolaire (talk) 17:59, 4 August 2013 (UTC)

In principle, yes. But why did you add imported from Wikimedia project (P143) English Wikipedia (Q328) to the source? Either you (!) know that the claim is correct according to História da Grande Revolução (Q14474073) - then, imported from Wikimedia project (P143) English Wikipedia (Q328) should be omitted - or you have not read História da Grande Revolução (Q14474073). Then, you added stated in (P248) História da Grande Revolução (Q14474073) based on speculative assumptions. In the latter case you should remove the source.  — Felix Reimann (talk) 13:00, 5 August 2013 (UTC)
See Help:Sources for more details. Then for a book the pages from where the data is cited have to be mentionned in the item sourced with the book. If you look for a information in a book of 500-1000 pages you will appeciate this small detail. Snipre (talk) 17:38, 5 August 2013 (UTC)

What property

I was looking at Barack Obama (Q76) and it lists the various offices he was elected to, with start and end dates, but it does say which state he was a senator for. Is there a property I can use as a qualifier to say what electoral constituency he represented when he was a senator? (It was Illinois.) Filceolaire (talk) 23:36, 4 August 2013 (UTC)

I do not know if it is the same thing as I have proposed at Wikidata:Property proposal/Person#Electoral district. -- Lavallen (block) 06:07, 5 August 2013 (UTC)
I think 'Electoral district' would be fine. However, I just created P766 (P766). Would this also do it? Which of both properties are better? If 'electoral district' is (still) needed, I'll create it also. --Nightwish62 (talk) 10:27, 5 August 2013 (UTC)
P_talk:P766: "This one is designed to make statements where a event took place." - The electoral district is the base for your membership in the parliament, not where something takes place. -- Lavallen (block) 10:50, 5 August 2013 (UTC)
I missed the discussion on P766 (P766). I would have said it was redundant to located in the administrative territorial entity (P131). "Electoral district" is different however. I have just voted support for this. Filceolaire (talk) 12:30, 5 August 2013 (UTC)
The original description of located in the administrative territorial entity (P131) was: Is in - an upper level administrative subdivision (the one this object: town, prefecture, province etc). So it excludes events. And there is still the "value allowed: administrative areas" on the discussion site. There was also a question back in May (!) why this property can't be used for events, but no ones seems to care. Now we've a separate property for locating events. In my opinion we can delete 766 again, but then we've to change the description and the 'allowed value' of P131. --Nightwish62 (talk) 13:28, 5 August 2013 (UTC)
In the competition between P131 (and some others) and proposed "Electoral district", are there some other problems. P131 can be misunderstood, since somebody can live somewhere else than the district (s)he is representing. It's not unusual that MP-candidates are trying to compete for a seat in several districts, like both Stockholm Municipality and Stockholm County. And some smaller politial parties are competing with the same list of people in all electoral districts. -- Lavallen (block) 14:26, 5 August 2013 (UTC)
Nightwish: In my opinion events are included in "etc." The 'value' (the object of the property; the item the property points to) should be an administrative division but the subject of the property (the page it is used on) can be anything that has a location.
For the second one you're right, my fault. The "allowed value" refers for sure to the objects, the subject can be something else. However, the domain is also "places" and I think this refers to the subject (actual item). And about the 'etc': Sorry, bad that is like I would begin a list 'apple, banana, orange, kiwi, cherry' and you carry on with 'potato'. Take a look at all other examples of the description, those are all administrative units. So I suppose the 'etc.' refers to other administrative units as well. --Nightwish62 (talk) 17:02, 5 August 2013 (UTC)
Lavallen: I agree. "Electoral district" is needed as a separate property but should generally be used as a qualifier to position held (P39) so there is no confusion when somebody represents various districts over his career. Filceolaire (talk) 14:31, 5 August 2013 (UTC)
We also have to agree if we are supposed to use "Member of" of position held (P39). Both works fine for me! -- Lavallen (block) 14:53, 5 August 2013 (UTC)

  Done It seem most here supporting the property proposal of 'electoral district', so I've created it (electoral district (P768) --Nightwish62 (talk) 17:10, 5 August 2013 (UTC)

I also proposed a Seat number-property. Please, tell your opinion! -- Lavallen (block) 17:53, 5 August 2013 (UTC)

Script error

[7] Rippitippi (talk) 11:54, 5 August 2013 (UTC)

Change to 'Q11651459'

I have removed Q11651459 from the recommended values for 'P107 (P107). Here is the diff.
Disambiguation pages should use 'instance of (P31) Wikimedia disambiguation page (Q4167410)'.
Pages which disambiguate names for persons can also use 'instance of (P31) Q11651459'.
There are a lot of disambiguation pages using 'P107 (P107) Q11651459' which need to be changed to 'instance of (P31) Wikimedia disambiguation page (Q4167410)'.
Anyone got a bot which can do this? Filceolaire (talk) 14:20, 5 August 2013 (UTC)

I have requested the deletion of Wikimedia disambiguation page (Q13416711) too since I have changed all the "instance of (P31)" links to this so they link to 'Wikimedia disambiguation page (Q4167410)' instead. Filceolaire (talk) 14:42, 5 August 2013 (UTC)

Ordered lists

Suppose one wants to fill in data for an election that was conducted using closed party-list proportional representation. In these types of elections, voters vote for an ordered list of candidates, and we need to have the data of the contents of the lists available. Typically, with the current capabilities of Wikidata, if we want something ordered we would add "placement" qualifiers with numbers in numerous statements of one item, or distribute the data among numerous items and use either "preceded/succeeded by" and/or order placement qualifiers. Neither of these could really work well for compiling party-list data, as qualifiers only go one level deep. There are also a number of other situations (personal names, for example), where we don't really have a way to store ordered data well.

So, I propose that we request that the developers add an ordered list data type, that would allow the order of a set of items (or otherwise) to be retained in the data. --Yair rand (talk) 14:28, 5 August 2013 (UTC)

I don't understand what the qualifier deepness is. We just need an item for the list and several part-of <this list> statements qualified by preceeded and followed in each of the members. There is a problem with that if we want to insert several times the same element, in which case we also need a number associated with each of these statements. I don't see why we would need deeper qualifier. Otherwise we would need an accessory item to build nested statements.
PS: another discussion on list see the subsequence property proposal and Help:Modeling#Series_and_sequences in which I will add one or two stuffs. TomT0m (talk) 14:44, 5 August 2013 (UTC)
So you're saying that each candidate could have a statement saying that it's part of "Minorparty Foo's party list for the Bar district in the 20XX elections in the Bazistan", which would then in turn have all of its own labels and descriptions, and statements explaining what it is, and the candidates order would be distributed across all the candidate items? That seems like it would be rather hard to use. --Yair rand (talk) 14:58, 5 August 2013 (UTC)
It's a bot job, those lists are public datas, so it's to bots to import them together with the official source. It makes sense to have an item for the list as it is a real world thing. If we really want to say things about that list, then we must have an item for it. Of course if we do not want to include in the datas of the person that he was a candidate in this election, we can just put the list member statements into that item (and we might encounter the unidentified person problem for the member of the list). But of course, as in other problems like the book edition item problem, the nested item edition interface could help. Wikidatas interface has a long way to go, it's difficult to build a good generic and low level interface, that's why there is so many gadget. I think we will also see other domain specific interfaces in the future. TomT0m (talk) 15:12, 5 August 2013 (UTC)
I agree that we can probably manage without this datatype for now. The developers seem to have quite a bit of work still to do to finish the current programme so you might have a long wait to get this datatype if it was agreed. I suggest we manage without for now and see if phase 3 has problems generating ordered lists from 'succeeded by' statements. If they do then we can look again at an ordered list datatype as a way to resolve that problem. Filceolaire (talk) 15:29, 5 August 2013 (UTC)

Towards an automatic description (and labelling?) system through types

Hi, there is a lot of items without label in languages that can (and should) be describes automatically if we know their types. For example I can now see in ValterVB list of undescribed (in french) airports items. I think a bot should do that, and he could do that using properties :

  • if the item is an instance of airports, and if we know its location through proporties, we should label it Airport of <location>.
  • if the item is an instance of album, and if we know the band, we should label it album of <band>.

All we know is a mapping between a class, a language, and a pattern, which could be built collaboratively. What do we think of adding templates on discussion page of class items which would look like {{defdescription|en|album by ${{P|175}} }} ?

Then we would have to concentrate on properties most of the time, which is the most important thing. TomT0m (talk) 12:34, 29 July 2013 (UTC)

I think this is a good way to provide Descriptions in multiple languages (You did mean 'describe' it as "Airport of <location>" and "album of <band>" didn't you?). Watch out for the RyanAir tendency to fly to an airport miles from anywhere and label it as a flight to <city which is miles away from the airport>. Filceolaire (talk) 21:36, 29 July 2013 (UTC)
True, an airport is almost never well described by its location (typically some small town outside a major center) but RyanAir is not the only problem you have to worry about. Once you get past the "album of <band>" example, things are very rarely simple enough to allow for this kind of automatic labeling without human oversight. This is a great recipe for having Barack Obama automatically labeled as "American lawyer"... Even for albums, I can see problems with artists that changed names but are nevertheless represented by a single item: no description is better than a misleading description. A related problem is that vandalizing (or honestly screwing up) one statement would add dozens of incorrect descriptions. It's also important to keep things simple if we ever want to get a large community of editors and not a just a handful of techies who understand what {{defdescription|en|album by ${{P|175}} }} means. 06:10, 30 July 2013 (UTC)
Without bots, there is no Wikidata. I now have a bot who corrects mistakes done by other bots. Non technies would hardly have to understand this label, and for avoiding vandalisation can be done by having some kind of validation for new labels, for example. And the numbers are just enormous, 13 million items in 200 languages, just do the math for the number of descriptions. I think it's better to use the informations we have on an item than to generate a label, or we can wait some time before we get the label of the 30000 municipalities in France in suomi or whatever language. It does not make it harder for people to set or correct a label, and it's not imho the most interesting task to build a community if people are just bored after 3 edits ... TomT0m (talk) 09:13, 30 July 2013 (UTC)
I imagine that once Wikidatadata is used on Wikipedias (generating lists, tables...),then Wikipedians will come very quickly to add/fix labels and descs...? Littledogboy (talk) 11:35, 30 July 2013 (UTC)
In theory, we need 200 labels on 15 million items. In practice, it's not even close to that and I'm sure nobody is impatiently waiting for a Slovenian label on Q8838750. Besides, the solution you propose would realistically cover a tiny fraction of items and doesn't constitute a panacea. I'm not against using bots to do this kind of task: bots can be very successful at creating descriptions and labels but that's because they can do more subtle things than just tacking two bits of text together and they can also cross-check their result with what other description-creating bots do thus reducing the error dramatically. What you're suggesting, on the other hand, is crude and therefore error-prone. Incorrect and misleading labels and descriptions are worse than absent labels and descriptions and they are not simply slightly worse: they are order-of-magnitude worse. @Littledogboy: Wikidata descriptions are not visible on Wikipedia so that's not going to help. Moreover, we have to stop expecting Wikipedians to solve Wikidata's failures and we have to stop assuming that Wikipedias will necessarily use Wikidata on a large scale in the future. This will only happen if Wikidata is able to show that it can provided added value so we need to be careful about quality control on Wikidata. Wikipedias have created and maintained lists without Wikidata's help for years and you're not going to convince them to use Wikidata by saying "if you use Wikidata on Wikipedia, you will make it easier for Wikipedians to spot what Wikidata screwed up". That's not added value: that's added hassle. 16:36, 30 July 2013 (UTC)
If you've ever tried translating a list of countries by... for a small Wikipedia, you will know how much tedious work would building a query save you. If you've translated two, you will know you'd better correct half of the labels on Wikidata once, than having to translate the whole list again. As for descriptions – let's not rule that out, they could come in handy at Wikipedias, too. Littledogboy (talk) 17:45, 30 July 2013 (UTC)
Don't get me wrong: I do believe in the promise of Wikidata but I also believe in doing things right rather than doing them quickly. 19:55, 30 July 2013 (UTC)
If you want to build a community with things that are useful for Wikipedians, you should realize that the maturity of the database is indeed important so they can (or not) use the datas present there. I find a utility for descriptions : some items for local policy reasons do not have a proper aricle because of the Bonny and Clide problem. It those cases maybe a description of the involved item when the user is about to click on the item could help to have a better idea on where he is going, or things like that (currently not possible to implement without javascript), or when the item has no article at all, for example a samll town of a foreign country in a history article. Or else Wikidata will be something abstract for a lot of Wikipedians. TomT0m (talk) 09:17, 31 July 2013 (UTC)
@TomT0m. You just miss something:"the maturity of the database is indeed important so they can (or not) use the datas present there", OK, but this is true only if your data are reliable. Wrong data in a database are worst than few data in a database. We have to work with bots but from reliable sources. So the job of contributors in Wikidata is not the manual addition of data in the DB but the selection and the preaparation of data to be imported through bots in the DB. Snipre (talk) 11:47, 31 July 2013 (UTC)
Maybe (or not), but it's quite independant from generating labels by a bot from alrady imported data :). We can even imagine quite easily that the bot updates the labels if the data changes (and labeling in different languages maximise the chances to find a mistake in the datas as there is more way to access itc). TomT0m (talk) 11:51, 31 July 2013 (UTC)
Could bots do that, then, and perhaps leave "B" at the end of desc. to indicate it is bot-generated? Littledogboy (talk) 16:17, 1 August 2013 (UTC)
I don't think it's a good idea as they will be used outside and it mixes label and meta informations that might be used out of context and not make sense, but maybe we should have some clean way to mark unreviewed by human statements or bots work ... TomT0m (talk) 10:48, 6 August 2013 (UTC)

Many-to-one pygmy elephant

Once again, people need to set some many-to-one page links (or one-to-many), where many pages all link the same "one" page, until it is split to better reflect each of the many n-way incoming page-links. A key example is enwiki article "en:Pygmy elephant" which could not connect to the en:Kiswahili (sw) language (common in central Africa), because article "sw:Ndovu" (aka "Tembo") is connected to enwiki "Elephant" and the redirect is restricted as same name. Consequently, I added an in-page interwiki link as "sw:Tembo" with note of limit in Wikidata. So, again the (pygmy) "elephant in the room" is the unfortunate reality that Wikidata must be redesigned (soon enough) to allow the rare (but real) many-to-one relationships, or one-to-many (in reverse). Meanwhile, the old in-page interwiki links (also in "en:Asian elephant") can be used to overcome the limitations of Wikidata links until redesigned to better handle the n-way, real-world connections between topics. However, hear the distant drums, for the natives are restless (sorry for the puns), and the elephant in the room of frustrated users cannot be ignored much longer. Perhaps also discuss at en:Wikimania 2013, where verbal talks can be faster, with many more examples of the many-to-one page-link problems. -Wikid77 (talk) 15:01, 5 August 2013 (UTC)

So en:Pygmy elephant links to sw:Tembo and is forwarded to sw:Ndovu which links back to en:Elephant. Right? Filceolaire (talk) 22:49, 5 August 2013 (UTC)
Same for "en:Asian elephant" which is described in Swahili language as a section of page "sw:Ndovu" as compared to "en:Forest elephant". If we could get more editors to write Swahili articles, then "Asian elephant" could have a direct one-to-one link with a separate Swahili page (not a section). This year, many English elephant articles need to link to the one swwiki page "Ndovu" (or redirect "Tembo"). - 01:48, 6 August 2013 (UTC)

Important misfunction since 2 weeks/Grava misfunkcio ek de du semajnoj

Since 2 weeks as long as I am logged in I cannot add any new interwiki link in wikidata, but all other modifications are workin. As soon as I am logged out the adding is possible without any problem! This is really a very strange bug! With best regards/Ek de du semajnoj mi, kiam mi estas ensalutinta, ne povas aldoni ligilon al nove kreita artikolo en alia lingvo. Simple kiam oni selektas "aldoni" aperas kampo por la lingvo sed ne kampo por la aldonajxo. Se mi elsalutas kaj anonime faras la redakton, tio tamen tute bone funkcias. Tio estas absoluta strangajxo. Cxiuj aliaj modifoj cetere eblas tute senprobleme. Sxajnas, ke aperis iu tre stranga eraro en la softvaro! DidiWeidmann (talk) 19:03, 5 August 2013 (UTC)

You might want to post this to WD:DEV. --Yair rand (talk) 19:15, 5 August 2013 (UTC)
Thanks - I did now so! Hope they find a solution.DidiWeidmann (talk) 20:26, 5 August 2013 (UTC)
I had the same problem. Do you use any custom javascript? If so, disable it. In addition, restore the default preferences settings. This worked for me.--Kompakt (talk) 14:53, 6 August 2013 (UTC)

Proposed 'Key Event' property

The proposed 'Key Event' Property has been archived without being created. I think it should have been created.

Anyone else have an opinion? Filceolaire (talk) 20:36, 5 August 2013 (UTC)

In my opinion it would be best to open a new request. Try to make the wording clearer and sum up the previous discussion. People really don't want to read page long discussions that took place months ago. The discussion includes a link to an RfC, so the outcome of that should be summarized too. If a proposal is clearly worded and has a few good examples then votes will come in very quickly. --Tobias1984 (talk) 21:40, 5 August 2013 (UTC)
  Oppose. Just because the conclusion doesn't suit your opinion, it's no reason to reopen it. --Nightwish62 (talk) 10:02, 6 August 2013 (UTC)
If I recall well, last time I see you commenting about coming back on a decision taken before (about property proposal), the dialog was something like somebody - "it does not work" - You (or Tobias, I don't remember) - "It's not a reason to change anything", so if I might this sets the standards for changing anything pretty high around here, if I may ;). TomT0m (talk) 10:20, 6 August 2013 (UTC)
I don't understand. --Nightwish62 (talk) 10:43, 6 August 2013 (UTC) PS: You maybe refers to this Wikidata:Project_chat#property_index_counting_bug, but I'm not sure. And even so, I still don't understand. --Nightwish62 (talk) 10:50, 6 August 2013 (UTC)
@TomTom: as a non-native speaker I also have some trouble understanding what your are saying. But just to comment a little further: The current tabula-rasa policy on the property proposal pages will lead to some controversial creation and some controversial archiving of proposals. There are a number of reasons this is good. The most obvious one for creation is that we need to allow for a certain amount of trial and error in order to progress. The most obvious one for sending proposals to the archive is that after a certain length of discussion a lot of people will be discouraged to read up. A lot of times a certain amount of uncertainties are already removed in that discussion and it makes perfect sense to archive the discussion and start fresh with a summation of what was already decided. The pages are now also much shorter which has already had a positive impact on voting frequency in my opinion. So nobody should feel insulted about this turnover, but try to see it as a kind of natural selection which will hopefully lead to increased fitness of properties :) --Tobias1984 (talk) 11:35, 6 August 2013 (UTC)
No new proposal and no new RfC for the moment: I think that kind of proposition need a very good preparation before any debate. We already had Wikidata:Requests for comment/Time DataType Properties which was closed without any useful outputs. We can't have different ways to manage time data: this means that a new system should be applicable to the differents fields (plane, building, persons, cities, inventions, discoveries, historical events,....). And as different discussions hapened we need to take account of all comments before starting any nwe discussion. My advice is just to start to collect the differents cases which appeared during the discussions and to build a new system with a lot of examples in the Wikidata:Infoboxes task force before any new discussion. Snipre (talk) 11:43, 6 August 2013 (UTC)
Sometimes I really think about to take time out for some months and coming back when the way we'll collect data and modeling structure is agreed by the community. --Nightwish62 (talk) 13:30, 6 August 2013 (UTC)
It's the hard part, but it's the way community chose. It's that or we open all doors and let people create their properties and the corresponding infoboxes and then modify the structure. But this would imply that the infoboxes would have to be maintained in all the languages at the same time. TomT0m (talk) 13:36, 6 August 2013 (UTC)

New RfC about Wikidata Workflow

Hi, in the spirit of the discussion about the property proposal length and following ideas that I and others had approved at the time, I launched a RfC on the topic of changing the Workflow of Wikidata. Please read and comment, it's (in my opinion) an important topic with a lot of potential impacts (documentation of Wikidata, efficiency, ...). Please see Wikidata:Requests_for_comment/Property_proposal_organisation_reform_to_a_more_Model_(or_infobox)_oriented_process. TomT0m (talk) 11:43, 6 August 2013 (UTC)


[8] : group of aquatic, flightless birds and my mom!, passed the filter it seems, what is activated, how to signal these vandalism to add it to the database ? TomT0m (talk) 16:34, 6 August 2013 (UTC)

[9] very old vandalism. --LadyInGrey (talk) 16:53, 6 August 2013 (UTC)

Wikidata <-> Wikipedia communication

Hi, Wikidata is an important project for Pedias, yet I'm not sure that we have a good bidirectional communication between projects. It would be mutually beneficial to be better at that because there is probably a lot more Wikipedians than Wikidatians so this could benefit the project, but Wikidata does not seem really easy to understand the project and its goal for everybody as it's more technical. Any ideas on this subject here ? TomT0m (talk) 12:07, 6 August 2013 (UTC)

I agree that Wikidata probably needs to be easier to understand for Wikipedians, but we would need to know what exactly the average Wikipedian is having trouble understanding about this project. Did you have something in particular you were talking about? TCN7JM 12:12, 6 August 2013 (UTC)
No, nothing in particular, except a discussion with someone on the french chat that needed to have informations about how to import datas and did not find it easily (lack of documentation and estabished procedure), but the fact that we no few things about what a Wikipedia user have trouble to understand or more simply need from Wikidata is a problem by itself, we do not really seem to be often questions from WIkipedians here, and I don't think it's because we are so perfect that they do not need anything. We need better ways of telling them what it is going on and what question they have. TomT0m (talk) 12:18, 6 August 2013 (UTC)
THat is where documentation helps and users who are regular contributors of both the project can come in handy. They can point particular areas.--Vyom25 (talk) 12:25, 6 August 2013 (UTC)
I think that every Project (or task force) should elect a few people that keep the corresponding WikiProjects (in as many languages as possible) informed in regular intervals. Those people should also try to direct new users to a projects. Most people have questions about the specific area they edit in so the Projects are a good place to start looking for help. I myself have watchlisted a couple of WikiProjects and scan the chat for Wikidata related questions. --Tobias1984 (talk) 12:30, 6 August 2013 (UTC)
We can also create a system of announces which are transfered in english to the wikiprojects by a bot, it would need less manual work, we just for a start would need to map task forces to corresponding Wikiprojects. Then somebody in the WIkiprojects could translate in the local language (we cannot do that for eery language.) TomT0m (talk) 12:39, 6 August 2013 (UTC)
My experience from talks about Wikidata on Wikipedia: That you have to enable javascript in your browser and that not all browsers support every function is one of the most confusing things for the average Wikipedians as far as I can see. The use of interwiki through Wikidata has been more and more accepted and the problems with lost interwiki when a page is moved have I seen less complaints about in recent time. The problem that you sometimes loose cookies when changing project has been a more frequent complaint.
The use of Wikipedia as source is giving Wikidata a lot of Badwill, we really have to work on that part. -- Lavallen (block) 13:03, 6 August 2013 (UTC)
Well, that actually is not the case. Without javascript any user could use Special:SetSiteLink to add an sitelink, Special:SetDescription for descriptions, Special:SetLabel for labels and finally Special:SetAliases for aliases.--Snaevar (talk) 20:19, 6 August 2013 (UTC)
Would you say it's because of problem on the principle itself of because it's more technical and people are afraid to face a new tool, or they don't understand how it will work and seem a computer scientist complicated project  ? TomT0m (talk) 13:39, 6 August 2013 (UTC)
The wp-community as I know it, is non-technical and conservative. The technical persons in the community are busy IRL... With every change in the interface and functionality, there is always a larger group of users who asks how they will be able to turn it of (VisualEditor is the latest example). Even myself is conservative, and still use monobook. -- Lavallen (block) 15:15, 6 August 2013 (UTC)
You're speaking of those who make the more noise :) Anyway users who are non technical at all don't often touch the infoboxes so they are not really concerned. For them we should insists that in the end there will be very few changes in their habits. TomT0m (talk) 15:25, 6 August 2013 (UTC)

(block) 15:15, 6 August 2013 (UTC)

Telling people not to care about Wikidata might not be the best way to get people contribute to Wikidata. Ljubinka (discussion) 16:30, 6 August 2013 (UTC)
Of course, but we should prior to them telling people who might gladly experiment with it (there is some, I could see, but the software was not really ready for them to do useful things). TomT0m (talk) 16:36, 6 August 2013 (UTC)
Tu as raison, mais le fond du problème ressemble davantage à ce que tu évoquais dans ton premier message. Ce n'est même pas (principalement) une question de technique. L'information est tellement proche de zéro que les contributeurs ne savent pas ce qu'est au juste Wikidata, donc ne savent pas à quoi ça sert, donc ne savent pas comment ça fonctionne, donc ne savent pas comment ils pourraient aider. On parle de bénévoles dont le temps est limité ; il n'y a pas de raison logique à le consacrer à un projet dont ils ne connaissent rien (ou presque). Moi je suis prête à créer des pages d'aide et à répondre aux questions, mais même les bonnes volontés ne sont pas vraiment encouragées. Ljubinka (discussion) 07:19, 7 August 2013 (UTC)
I think the problem is to see the benefits of Wikidata for non-technical persons. As we have no showcases, saying: hey, move your widely used infobox to Wikidata is thus difficult. To show the benefits of WD we should a) rebuild infoboxes which are of wide use in Wikipedia with Javascript and feed them solely with WD inputs and b) the developers should assure that the basic Wikidata information (and sources and qualifiers of claims are an important part) should be readable even without Javascript with plain HTML.  — Felix Reimann (talk) 09:07, 7 August 2013 (UTC)

Another example of why main types are not enough

list of state leaders in 597 (Q24104) is a Wikipedia list. The statement states that it is a list of person, which is true, it does not state that it's a head of state list, whereas the class of all head of states should exists. TomT0m (talk) 14:31, 6 August 2013 (UTC)

I don't think there is anyone left who claims that 'Main types' 'are enough'. Now they just claim they are one tool which can be useful in some circumstances. Filceolaire (talk) 22:36, 6 August 2013 (UTC)

new datatypes on testwiki?

How is it possible that has datatypes like number (unit?), monolingual and multilingual, but not URL? I thought URL datatype would be the next one (initially scheduled for at the latest of tomorrow, because the Hong Kong stuff) and the ones listed above should be released months later. --Nightwish62 (talk) 17:16, 6 August 2013 (UTC)

I felt a little bit disappointed at moment and therefore I made a post on the Contact the development site --Nightwish62 (talk) 17:48, 6 August 2013 (UTC)
As you can see these datatypes don't actually work yet. They've been started quite some time ago and are there. URL is being worked on but with summer travel and Wikimania things are moving slowly atm. --Lydia Pintscher (WMDE) (talk) 09:17, 7 August 2013 (UTC)

Guidelines for property proposals

I have put forward a simple set of guidelines for property proposals at Wikidata talk:Property proposal. Please comment there. Mushroom (talk) 09:07, 7 August 2013 (UTC)

My database reports (statistics and various lists including merge lists) are updated

Hi, I will just let you know that I have updated most of my database reports with data from the new 2013-08-05 database dump. Some of the generator programs are updated a bit:

  • The numbermerge pages now also includes an interval merge section which suggest merging of items with links which contain two numbers separated by a some kind of dash, hyphen, minus sign, colon or space, which most often is an interval.
  • I have worked on improving how country names are recognized in the countrymerge pages. It is not bad, but it may be even better with more work.

I am always open to your ideas if you think something can be better, or if you miss something. Byrial (talk) 16:26, 7 August 2013 (UTC)

Descriptions too long

Byrial has made an excellent list of too long descriptions. The general idea of a Wikidata description is simply to disambiguate from similar labels. It shouldn't act like a Wikipedia lead section. Long descriptions are not useful when trying to decide which item to pick as you can't read the entire thing anyway. It seems from the list that there are many Russian descriptions that are way too long. It would be good if a Russian speaker could go through this list to fix the descriptions. Cheers. Delsion23 (talk) 16:58, 4 August 2013 (UTC)

I thought the goal of description was to describe ... TomT0m (talk) 20:46, 4 August 2013 (UTC)
Hmm, not really. As mentioned in Help:Description: The description on a Wikidata entry is a short phrase designed to disambiguate the page in question from other pages with the same or similar labels [...] Descriptions should be long enough to allow people to easily grasp what the entry's label refers to, and no longer than that.. --Nightwish62 (talk) 22:11, 4 August 2013 (UTC)
As Nightwish states, the description should only be long enough to disambiguate. We are Wikidata, not Wikipedia. It is why Q84 (London) is "capital city of England and the United Kingdom". Not "London is the capital city of the United Kingdom with a population of 8 million, it is home to the government of the UK, it is in the southeast of the country". We display this kind of data in the statements anyway, so there is no reason to double it in the description. We try to keep the description succinct. Delsion23 (talk) 23:12, 4 August 2013 (UTC)
I imagined other uses for description, for example to describe shortly an item which does not have a Wikipedia entry for itself because of local Wikipedia policies, which sometimes leads to odd redirects which could be clearer if a description of the item was displayed before the click. Don't forget that there will be other uses of descriptions. TomT0m (talk) 09:03, 5 August 2013 (UTC)
While the main purpose of descriptions is to disambiguate—and for this purpose a description should be kept as short as possible, as otherwise it cannot be displayed properly in the search box—it has, as some other people point out, other important purposes as well:
  1. A description should properly describe an item that does not have a Wikipedia page on a Wikipedia in the same language as the description.
  2. A description should be accurate enough the prevent editors from attaching pages that may seem to be superficially similar by name, by have a very specific meaning or subtly distinct meaning in different languages.
  3. A description should be extensive enough to give enough guarantees one is dealing with the proper item when seeing it displayed in the search box. For example, if descriptions are purely used for "local" disambiguation then it would not be necessary to add descriptions to items that have a unique name of Wikidata. However, when linking a person from another item through the search box, one would want the description to give at least the nationality, occupation, year of birth and, if applicable, year of death in order for one to be assured that one is dealing with the correct item.
For items represent concrete objects such as a person (Q215627) on can often give a short description that satisfies all four purposes, for more abstract concepts such as a term (Q1969448) this can be difficult or impossible. Finally, I would like to add a fifth requirement for descriptions:
  1. A description should be correct.
I have, unfortunately seen some people "summarizing" a long description which is short, but also incorrect.
Ruud 13:35, 5 August 2013 (UTC)
Add one more: The description shouldn't be long enough to break the page. :) Regardless of our reasoning or desire for how descriptions should be handled, pages which break because the description is too long should have their descriptions shortened. Period. --Izno (talk) 21:53, 5 August 2013 (UTC)
How exactly does a long description break a page? This sound more like a bug with the software than with the description. —Ruud 22:38, 5 August 2013 (UTC)
The page lists both items and properties. For properties, I think longer descriptions can are helpful. There is no article that explains it in detail. --  Docu  at 06:42, 5 August 2013 (UTC)
The talk page of a property should contain a lot of detail about how it should be used. In my opinion, the descriptions still don't need to be too long. However, I can accept long property descriptions more than long item descriptions. Delsion23 (talk) 17:48, 5 August 2013 (UTC)
Actually, I think it's preferable to provide a detailed description on the property itself. I'm not sure why it would be an issue. --  Docu  at 16:59, 8 August 2013 (UTC)

Coordinate Datatype misused

Hi, I have found unwanted (as I believe) differences between some instances of coordinate location (P625)'s claim. As you can clearly see ([10] and [ [11]) this claim has globe member, which, as I believe, should contain the URI to particular globe item page (as in the first link), but in some situation globe member of claim has value set to english name of globe (in the second link it will be earth). What should we do with that? cheers. --Magul (talk) 21:09, 5 August 2013 (UTC)

I wonder what the 'globe' parameter is set to on the Olympus Mons (Q520) item? Is there any way we can check or edit this through the user interface? Filceolaire (talk) 23:02, 5 August 2013 (UTC)
I haven't found it using user interface, so i don't know if it's possible, but just only by API [12] you can find that there is Mars (Q111) so I guess it's correct value. --Magul (talk) 06:16, 6 August 2013 (UTC)
There are 79 coordinate values in the new 2013-08-05 database dump which use the string "earth" instead of an item as globe. That can be seen at my updated globe page. There are also coordinates with latitude greater than 90° N or S or longitude greater than 180° E or W. User:Steenth told me that such values exist, and they are now also listed at the globe page. Byrial (talk) 00:26, 7 August 2013 (UTC)
It's great to know, we have such a tool. Is there any list with this items? I guess we should correct them with globe Earth (Q2) and notify person, who add the wrong one. --Magul (talk) 06:38, 7 August 2013 (UTC)
The positions of 'Fixed' stars can be specified relative to a celestial sphere (Q12134). Can this be used as a globe? We don't seem to have imported the positions of stars from their infoboxes. Filceolaire (talk) 11:50, 8 August 2013 (UTC)
@Magul: I added a list of items and coordinates values where globe is given as a string to User:Byrial/Globes. Byrial (talk) 14:40, 8 August 2013 (UTC)
@Filceolaire: I think any item can be used as globe, but by using the bot API. Byrial (talk) 14:40, 8 August 2013 (UTC)

a little thing for Denny

Just in reference for the model the world blogpost of Denny : a cat seems to be a mayor in Talkeetna, Alaska : [13]. Or it's just a joke, needs to be second checked :). TomT0m (talk) 16:28, 6 August 2013 (UTC)

For me this vision of Denny does not help the project, and opens the door to vandals and tons of mistakes, even now we can see that often are inserted the wrong proprietys values. There must be a middle line between freedom and total rigidity. Rippitippi (talk) 21:42, 6 August 2013 (UTC)
Denny's post is basically an argument for using the open world assumption on Wikidata. This idea is counterintuitive to most people with a traditional programming background, because conventional databases operate under the closed world assumption. There are appropriate use cases for both, but I think unfortunately the Wikidata community is mostly unaware of OWA and tends to over-apply the more familiar CWA. This video describes the differences between the two approaches, as does this presentation from people in the know. Emw (talk) 04:51, 7 August 2013 (UTC)
It's an incomplete position, there is a big hole for modeling in Wikidata, the software handle nothing (when I asked about beeing able to use statements on properties I was answered We think it's counter productive to model the whole world which seems to me in the same family of idea, or vision. That's why you have so much to advocate for using web semantic standards. (personal message, please comment the new RfC :) when you got time) TomT0m (talk) 09:12, 7 August 2013 (UTC)
This is the big problem we need urgently fix that the software handle statament and propriety otherwise we will have a lot of work getting bigger. For example if I use statament must only choose between statament and if I choose "Country" must only choose between 204 country in the world, not the Middle-earth of tolkien, otherwise it will be increasingly difficult to maintain and will soon become unusable.Rippitippi (talk) 12:35, 7 August 2013 (UTC)
Well I think I understood the initial vision was to rule information overload throught a smart suggestion system in various areas (such as property suggestions for the model level) but things are not ready yet so it's kind of hard to see if it will be enough to be usable. That's why I think we should see specialized interface for a domain and Wikidata mainly use as a triple store and query backend, and not mainly as an interface. TomT0m (talk) 12:46, 7 August 2013 (UTC)
for "become unusable" I refer to all the data of wikidata, they will be just a bunch of confusing information Rippitippi (talk) 12:56, 7 August 2013 (UTC)
But isn't the country for Q308657 - Minas Tirith - not Q213586 - Gondor? And what about the Talkeetnan cat? Should such statements be forbidden?
I think that the flexible software together with the constraint-checking bots is a formidable solution that has emerged. Furthermore, indeed, I am surprised that there are not any special interfaces there yet for entering specific subsets of the data. But I will continue to argue against constricting the world too much. Nilesh, the GSoC student working on the recommender, is moving forward swiftly, and let us see how his implementation will work for the smarter suggest. --Denny (talk) 14:03, 8 August 2013 (UTC)
And thanks for the catty mayor, TomT0m! :) --Denny (talk) 14:04, 8 August 2013 (UTC)

New Job for wikidata

There is many of Redirect pages in all wikipedia languages versions, Add to this that if any one enter another wiki language and want to Search for article, What makes it very difficult to find. Here's what I propose; Make Redirect pages special inclosed for wikidata (under Also known as:), What makes the ability to search for articles on any Wikipedia is easy, Even if searched under the title of another language as long as there is an article in this version.Emara (talk) 06:12, 8 August 2013 (UTC)

That has in many cases already been done, and has therefor introduced many strange aliases to Wikidata, since many articles on WP has been redirected instead of deleted. So be very careful when/if you try do something like that. -- Lavallentalk(block) 10:02, 8 August 2013 (UTC)

Asking administrators for proof for their claims

reviewing and marking for translation

I have made some edits to Help:Statements. Can anyone who is interested check this.

I'm not sure how to do the marking for translation of the various paragraphs I have added. Can someone check that please. Filceolaire (talk) 20:16, 8 August 2013 (UTC)

  Done Translation is now set up. The Anonymouse (talk) 06:02, 9 August 2013 (UTC)

Links from Commons category pages

See discussion commons:Commons:Village pump#On Wikidata. --ŠJů (talk) 00:01, 9 August 2013 (UTC)

Why doesn't Q1197 show up there? Is it related to bug 43238? Regards, --Nirakka (talk) 06:09, 9 August 2013 (UTC)

It works for me (third in results 1 - 500 of 2,056 for Niedersachsen).
Maybe your search preferences exclude it, see Special:Preferences#mw-prefsection-searchoptions.
Once in a while search fails entirely (no result for any request).
Frequently searching one of the Wikipedias and then switching to Wikidata works better. --  Docu  at 06:15, 9 August 2013 (UTC)
All right, it appeared right now. Got knows why. Thanks for your support! --Nirakka (talk) 06:19, 9 August 2013 (UTC)

Make error messages more helpful

This kind of issue is making it very difficult for people on Wikipedia and Wikivoyage to know what to do on Wikidata when faced with error messages. It would be great if the error message were to provide a few links to useful pages such as Project chat, Wikidata:Deletion policy and Help:Merge. I propose that the message "Site link X already used by item Q######" have the additional: "Perhaps the item should be merged and/or deleted? Feel free to ask at Project chat if you are unsure." I have no idea how to change the message, but hope that someone knows how. I think this would really help people unfamiliar with Wikidata. Delsion23 (talk) 23:49, 7 August 2013 (UTC)

MediaWiki:Wikibase-error-sitelink-already-used. But what about translations? πr2 (tc) 02:06, 8 August 2013 (UTC)
Can we mark it for translation by translation administrators or does it not work that way? It would be great if it could at least be in major languages. I have changed the error message in English to provide links to instructions on how to merge and delete. Delsion23 (talk) 21:58, 8 August 2013 (UTC)
Only administrators can change any interface messages, but translations can be provided for any language. For example, I created MediaWiki:Wikibase-error-sitelink-already-used/es for Spanish (español). The Anonymouse (talk) 06:27, 9 August 2013 (UTC)
I've put in a request at Wikidata:Translators'_noticeboard#Error_message_more_useful, noting that only admins can edit, but doesn't stop people from translating it and putting the translation in that section for an admin to do the edit for them. Thanks for translating the Spanish version! Delsion23 (talk) 08:32, 9 August 2013 (UTC)

personnel of studio album

I never saw any statements which musicians played on an studio album (guitar, drums, etc.). Even albums like Yellow Submarine (Q206097) or Thriller (Q44320) didn't have this information. There are a few items like Nevermind (Q17444) which claim which band (as a whole) has produced the album, but not listing the musicians in particular. I really like to add statements, but I know which property to use:

  1. collaborator: person or organization that contributed in the creation of a creative work
  2. performer/musical artist: musician, music group, or other performer associated with the item
  3. creator: maker of a creative work or other object (where no more specific property exists)
  4. participant: person, group of people or organization that actively takes/took part in the event
  5. or to create a new property like personnel?

I think 'creator' and 'participant' aren't suitable and a new property shouldn't be created. But 'collaborator' and 'performer/musical artist' sounds both good for me.

So what property should we use for making a statement...

  • which band (as a whole) has produced an album
  • which musicians have played on the album a specific instrument

--Nightwish62 (talk) 19:26, 8 August 2013 (UTC)

I have seen albums where each track has a list of the people who performed on that track and what they did (instrument/vocals/backing vocals/producer etc.). Sometimes not all members of the band are on every track. Sometimes people use one instrument on one track and a different instrument (or instruments) on another track. This property needs to be able to take a qualifier (contribution?) to give this info. Note that you will need a separate wikidata item for each track in order to capture all this info.

For me "creator" is for the composer or arranger and "performer" is for the the name of the band/singer on the record front cover/concert poster. I think "collaborator" or "participant" are suitable properties for the other people on the record. My recommendation would be to use "participant". Filceolaire (talk) 20:53, 8 August 2013 (UTC)

Qualified with field of work it's flexible and expressive enough to express any kind of participation. TomT0m (talk) 21:05, 8 August 2013 (UTC)
You're absolutely right. The musicians should be listed under the individual songs, what means we need for every song his own item (which we need anyway for further information like song duration, if the song was played life or in studio or links to 'is a cover of this song...' or 'has been coverd by this song...'). Could you give me one example of such an album which has linked to each track? But back to the main question, which property to use. You (Filceolaire) say 'performer' and that's the one I also prefer. However, 'collaborator' sound quite similar and I fear some user will use 'performer' while others will use 'collaborator' which make it impossible to query through all songs for a specific musician.
Did I understand you right TomTom, to use 'field of work' to make statements which instrument someone is playing? I don't 'field of work' is suitable for that. --Nightwish62 (talk) 05:29, 9 August 2013 (UTC)
I meant qualified with. There could be any kind of collaboration possible, it's for the case we do not have a suitable property what describes what the person did (and I can't imagine we really can imagine every cases :)),. In that case, for example we say that collaborator <X> qualified by <criticized> if he listened to the song before they was realised and tolled his fealings about it for example. For the queries, it's a general question. If we add a generic way of expressing things for cases we did not imagined together with a specialized solution, people may indeed use it instead of a specialized one. I don't think it's a goo reason to get read of the generic solution, for two reasons : the world is open and we can't imagine anything, and it's not that difficult to catch. There exists a query similar to the specialized one : query for every collaborator whose field of work was <guitar> (or more generally a subclass of <musical instrument>, versus querying every guitatist on the album, make a report for it as we do for items violating their constraints. Or make a single query just a bit more complex which take both cases into account. It does not seem to be a real problem (an once again a problem of documentation and guidelines : how do we help the user doing the right thing.). A more radical solution would b to get reed of the specialized property but I'm not sure I should event talk about it ;). TomT0m (talk) 08:40, 9 August 2013 (UTC)

Approximate birth and death dates

For many historical figures exact dates of birth and death are unknown. Sources often uses various kinds of qualifications to express this. How should these be handled on Wikidata? Some issues that may be encountered:

  1. Date of birth/date of death is only known approximately. Sources use a circa (c.) qualifier. Do we need such a qualifier (in the Wikidata sense) as well? It wouldn't have an associated value with it, though.
  2. The date of birth is one of two possible dates. (This is different from two sources giving two conflicting dates.)
  3. Some sources give both a timespan during which the personal was alive (Lebensdaten) and during which he or she was active (Wirkungsdaten; e.g. writing books or doing scientific research). We probably need properties for the latter as well. Or should they be a single property differentiated by a qualifier? This might make querying easier in some cases.
  4. In many cases we know very little about the life of the person other than the period during which he or she "flourished" (fl.; floruit (Q36424)). This is another qualifier like "circa", however in this case it generally is a single year. Perhaps we should set both of the start and the end of the Wirkungsdaten to the same year?
  5. In some cases we know a person must have been born/died before or after a specific date. Should these also become Wikidata qualifiers without associated values or perhaps part of the Time datatype?

Any thoughts? —Ruud 12:13, 8 August 2013 (UTC)

There is already a possibility in the date-datatype to add a span of time. You cannot see it in the user-interface yet, but it's availible for robots to write and read.
(edit conflict) If you have 2 or more possible dates, you can add them all together with a source for each. -- Lavallentalk(block) 12:18, 8 August 2013 (UTC)
The time datatypes allow some kind of uncertainty expression, with a precision like year, centuries (just try to click on some buttons to see those options when entering or modifying a date) ... this is enough for many applications. When there is several sources, I remember having set a date with a 10 year precision for someone (don't have the example yet, sorry). But in Wikidata spirit the options can also be entered annotated with the source each. TomT0m (talk) 12:19, 8 August 2013 (UTC)
Okay, Al-Khwarizmi (Q9038) is a very good example. I've added several birth and death dates, and several sources. For now I've (ab)used the P387 (P387) qualifier to specify how the sources qualified the dates (circa, before and after). I guess the most elegant way in this case would be to create a new qualifier which can be one of circa (Q5727902), "before" or "after". —Ruud 12:47, 8 August 2013 (UTC)
No need for a extra property. As someone said above: The time datatype already has a precision (here you can say: year: 820 precision: decade) and a uncertainty interval after and before (about 830 +5years -7years). See [14]. Only the web interface does not support this yet.  — Felix Reimann (talk) 15:06, 8 August 2013 (UTC)
If the sources don't give an uncertainty interval, I'm not going to "make one up" and then claim in was stated in the source as such... —Ruud 20:45, 8 August 2013 (UTC)
However, if the Time datatype supports separate upper and lower-bounds for the confidence interval, we could establish the convention that"before x" is represented as x +0 -∞, "after x" as x +∞ -0, and "circa x" as x +∞ -∞. —Ruud 21:06, 8 August 2013 (UTC)
This is definitively an option for before and after. However, I believe we should not try to cover all corner cases natural language provides. This means, instead of creating a qualifier for circa, you as the reader of the text should decide if circa in the context of this specific birth date means +- 1 year, +- 1 decade, or +- 100 mio years as in case of the Big Bang. I think when you read it, the context gives you in most cases enough information to transfer such inprecise information. Be bold ;)  — Felix Reimann (talk) 20:46, 9 August 2013 (UTC)

Infoboxes at small Wikipedias

I've checked oc:Modèl:Infobox identificacions autoritats:

Frédéric Mistral (Q42596), ISNI (P213): 0000 0001 2100 755X
oc:Frederic Mistral, ISNI: 0001 2100 755X 0000 0001 2100 755X

Any idea why the numbers don't match? --Martssnail (talk) 19:49, 9 August 2013 (UTC)

Because parser brakes off external links at the first space character, and makes description out of the rest. Template problem. Littledogboy (talk) 20:04, 9 August 2013 (UTC)

Echo and Wikidata

I have been told that, if we desire, we can have Echo enabled sometime in the future here at Wikidata. Therefore, I'd like to see if there is consensus for the implementation of the Echo notificacion system here. I personally consider that Echo has many benefits over our current talk-page-only method of notification, and could improve the way we communicate. Thoughts? — ΛΧΣ21 02:44, 10 August 2013 (UTC)

  • In the last discussion about this topic no consensus was provided, mostly because of the lack of localisation to some languages. Anyway, how would Echo improve the way we communicate? As far as I see the only new features are the thank feature and the ping feature which I personally both dislike pretty much. Vogone talk 02:59, 10 August 2013 (UTC)
    • Those are not the only new features. Echo lets you be aware of how the items you create behave, or are used, and also lets you know if someone used the rollback tool to revert your edit, etc cetera. I find Echo pretty useful for many reasons, since it lets you be more connected with the wiki, to some extent. — ΛΧΣ21 03:22, 10 August 2013 (UTC)
      • It is now live on meta, if that makes a difference. --Rschen7754 04:08, 10 August 2013 (UTC)
        • If it's live on Meta, that means that it probably has been localized (at least enough for basic multilingual deployment, it seems). The Anonymouse (talk) 04:22, 10 August 2013 (UTC)
          • It wasn't the meta community which wanted echo. The Foundation just deployed it, because it was in their time schedule. This says absolutely nothing about the state of localisation as the Foundation does not employ translators for their extensions, anyway. It is up to the volunteers to get that done. Vogone talk 04:51, 10 August 2013 (UTC)

Multilingual Picture dictionary on Wikidata?

I created a proof of concept for a Multilingual Picture dictionary on Wikidata:Multilingual_Picture_dictionary. Try it out by changing the language with the Universal Language Selector (just before the Username). The template {{Label}} is used to make it multilingual. HenkvD (talk) 09:36, 7 August 2013 (UTC)

That would be a nice addition to Wiktionary :) --Tobias1984 (talk) 10:24, 7 August 2013 (UTC)
Nice sample page. --Nightwish62 (talk) 10:57, 7 August 2013 (UTC)
Nice! One thing that looks obvious is that point 14 in the picture is singular, but it is labeling four objects... -- Lavallentalk(block) 11:50, 7 August 2013 (UTC)
Singular or plural all depends on the description of the label. Convention on Wikipedia is to have all Article names in singular. Labels on Wikidata are therfore singular too. HenkvD (talk) 21:55, 7 August 2013 (UTC)
It would be relativly easy to implement this functionality directly in SVGs on commons, SVG also have built in i18n functionality - that would be the perfect solution to get rid of the language mess on commons! - Well, we can dream... --FischX (talk) 18:13, 8 August 2013 (UTC)
As far as I know SVG is not really supported on commons. They are converted to PNG instead. So I guess the built in functionality of I18n in SVG does not work on commons. HenkvD (talk) 11:38, 10 August 2013 (UTC)

data to parents

How to integrate information like this in Item? Thank you, Conny (talk) 08:11, 10 August 2013 (UTC).

Three possibilities (one of it is wrong)
  • If the parents are notable enough, they can have their own item where the information can be put on
  • If not, the information shouldn't claim at all
  • (Make a normal statement to name the mother and father, then using a qualifier to claim where they are born)

But since the qualifier did only refer to the subject (the mother or father) and not the the item (Blake Griffin) and the statement, it would be a wrong usage of qualifier and removed again. --Nightwish62 (talk) 09:15, 10 August 2013 (UTC)

And most important: don't add this information into description of the item. --ValterVB (talk) 09:23, 10 August 2013 (UTC)
That's right, see here --Nightwish62 (talk) 09:33, 10 August 2013 (UTC)

Date of death, property

Hello, I see that there is an option to add a property in Property:P570 (Date of death), however, there must be a list of allowed values somewhere, since it does not accept anything I write. I think some values like "circa", "about" would be suitable. If anyone knows which are the allowed values, please let me know. --FocalPoint (talk) 15:56, 10 August 2013 (UTC)

Currently only exact dates are possible. See also the discussion above. The data model works with a span of time, but it is not yet possible to add this via the user-interface yet. There won't be a list of possible text like circa, about, before, after etcetera. HenkvD (talk) 17:11, 10 August 2013 (UTC)

constraint violation

Where to check the list of words, not allowed for descriptions? Thank you, Conny (talk) 12:48, 10 August 2013 (UTC).

Constraint violations do not affect descriptions. However, you can check the property's talk page for the requirements. For example, sex or gender (P21) has its requirements listed on its talk page (one of, item, and single value). The Anonymouse (talk) 18:16, 10 August 2013 (UTC)

In concrete: by adding "eine öffentliche Auseinandersetzung über den Umgang der Partei Bündnis 90/Die Grünen in ihrer Frühphase mit nahestehenden Personen, Mitgliedern und Gruppierungen, die Pädophilie praktizierten, propagierten und über die Grünen zu legalisieren versuchten" in the german description of pedophilia debate (Bündnis 90/Die Grünen) (Q14547589) I get:

Beim Speichern ist ein Fehler aufgetreten. Die Änderungen konnten daher nicht vollständig durchgeführt werden.
Es wurde eine Längenbeschränkung für den Sprachcode „de“ ausgelöst. 
Es gibt eine Beschränkungsverletzung für die Beschreibung „eine öffentliche Auseinander…“ für den Sprachcode „de“.

Greetings, Conny (talk) 19:14, 10 August 2013 (UTC).

You are having problems with the length constraints on descriptions. Please try to keep descriptions as short as possible (see Help:Descriptions). I am not exactly sure what the actual maximum length is, though. The Anonymouse (talk) 20:09, 10 August 2013 (UTC)
Ah, reading is good :) . I focused last sentence: "Beschränkungsverletzung" - Längenbeschränkung is better :) . Thank you Anonymouse :) , greetings, Conny (talk) 06:15, 11 August 2013 (UTC).

Excluding links to category redirects

See Wikidata talk:Notability#Exclusion of category redirects for a proposal to systematically remove links to category redirects (which are redirects in function but fool bots because they are technically treated as ordinary categories). Mergehappy (talk) 20:39, 10 August 2013 (UTC)


Is it only me or the site's logo (on the upper left) has been changed? Ayack (talk) 09:08, 8 August 2013 (UTC)

Looks like it's Wikidata HK (Hongkong) logo right now... --Stryn (talk) 09:19, 8 August 2013 (UTC)
Sorry, but what's Wikidata Hongkong? Do you know where this change has been debated by the community and why? Ayack (talk) 09:25, 8 August 2013 (UTC)
I think some of the development team has changed the logo, because Wikimania is in Hongkong right now. --Stryn (talk) 09:51, 8 August 2013 (UTC)
I guess this change is temporary. The Hong Kong logo has the morse code of "WMHK" hidden in it. --Wylve (talk) 10:52, 8 August 2013 (UTC)
Anyway isn't better announce that in the news of Wikidata? At least to inform other users. - Sarilho1 (talk) 15:25, 8 August 2013 (UTC)
It isn't that big a deal. The news is mainly for stuff like milestones and new development phases. Besides, I'm almost certain this is only temporary. TCN7JM 17:17, 8 August 2013 (UTC)

<3 Legoktm (talk) 01:56, 9 August 2013 (UTC)

<3 — ΛΧΣ21 02:40, 10 August 2013 (UTC)

I really hate the new logo. Change it back to the old one please. Rreagan007 (talk) 18:10, 9 August 2013 (UTC)

People please ;-) It's of course only temporarily. I thought we were a project where we could have a little fun and celebrate some occasions? --Lydia Pintscher (WMDE) (talk) 00:47, 10 August 2013 (UTC)
+1! Emw (talk) 00:53, 10 August 2013 (UTC)

Oh, now I understand, why my pagefeeling of Wikidata on tablet was a new one :) . Conny (talk) 08:13, 10 August 2013 (UTC).

Now back to old logo. --ReviDiscussSUL Info 03:09, 12 August 2013 (UTC)

Also known as

It is a bit ill-conceived that "also known as" additions to the label are possible only to the English label and not to labels in other languages. --ŠJů (talk) 09:08, 10 August 2013 (UTC)

This is not true. You can add aliases to any language supported by MediaWiki. Vogone talk 09:14, 10 August 2013 (UTC)
BTW You can see the number of aliases for each language in my language statistics for items. Byrial (talk) 09:34, 10 August 2013 (UTC)
Calm down, boys. I think he was trying to say that in the secondary languages shown after adding Babel to your user page, you only see label and description for other languages than the interface language. Littledogboy (talk) 10:27, 10 August 2013 (UTC)
I agree with ŠJů - the interface should allow to edit aliases in all languages. --Tobias1984 (talk) 10:59, 10 August 2013 (UTC)
It's possible using labellister gadget (can be found from the settings). --Stryn (talk) 11:07, 10 August 2013 (UTC)
No, I meant in the regular interface. The gadget is very useful but the regular interface should also allow this. Allowing it for just one language is a little counter-intuitive. --Tobias1984 (talk) 11:10, 10 August 2013 (UTC)
+1   Support. I really don't understand why the regular interface does not show ALL info. HenkvD (talk) 11:22, 10 August 2013 (UTC)
* The default setting should be meaningful and usable without additional gadgets.
* Regrettably, I have the labellister activated but nevertheless I can see not ALL languages but only those from my babel and I can see only labels and descriptions, but not aliases. You are right, I can 10× or 286× switch over my main language to see successively all aliases, but it is a bit uncomfortable and absurd. --ŠJů (talk) 12:28, 10 August 2013 (UTC)
In case you don't know: the Labels list is an extra tab between Read and View history. With Labels list you can edit labels, descriptions and aliases on all languages, but it has a complete different user interface. HenkvD (talk) 17:18, 10 August 2013 (UTC)
Thank You, You are right, I really didn't find such unexpected distribution of edit possibilities. It seems very impractical and illogical for me, incessantly switch from one tab to second one and from one language to second one instead of find and manage all together. --ŠJů (talk) 22:33, 11 August 2013 (UTC)

A Q about geographic inheritance

I am frequently in my work here troubled with the problems connected to Geographic inheritance. i.e. That something (X) is located in someting else (Y) and that is located in (Z) would imply that X is located in Z. Therefor it is not necessary to tell that X is located in Z, since it is understood since Y is located in Z.


Reality is not that simple. For example: Lloydminster (Q985674) is located in both Alabama and Saskatchewan. The enwp-article tells that Colby Armstrong lives or have lived in Lloydminster. If I here on Wikidata add a claim that Colby Armstrong lived in Lloydminster between A and B, that would imply that he had lived both in Alabama and Saskatchewan, but that is most likely not true.

An even more absurd example is that Princess Estelle, Duchess of Östergötland (Q214025) was born in Stockholm. But Stockholm is located in 12 Municipalities and 2 Provinces. But Estelle was only born in one single Municipality and one single Province. I can write that she was born in KI instead, since KI is located only in one Municipality and one Province, but since KI is a part of Stockholm, you still will come to the problem with inheritance of 12 Municipalities and 2 Provinces.

We all prefer when everything is as simple as in Texarkana (Q79438). Texarkana is comfortly two cities, with two objects. I can choose if NN lived in Texarkana, Texas or Texarkana, Arkansas. But in most my examples, I cannot find or even create such objects. Strömsund Municipality (Q514770) for example is located in 3 Provinces. I can find out in which Province most localities in Strömsund are located, but there are also localities who I do not know the extension of, and I cannot define if they are located in the Lappland-part or in the Ångermanland-part or in both. A powerplant is located in the point where all of these three Provinces meet. -- Lavallentalk(block) 06:22, 11 August 2013 (UTC)

FYI, Alabama != Alberta. πr2 (tc) 14:45, 11 August 2013 (UTC)
My remark at Wikidata talk:Country subdivision task force#Assemblability of administrative units seems to be related with this problem. Btw., Is Stockholm really located in 12 Municipalities and 2 Provinces? Aren't rather those 12 municipalities located in Stockholm? --ŠJů (talk) 22:24, 11 August 2013 (UTC)
I think you mixed Stockholm County (Q104231) (the province) and Stockholm (Q1754) (the city). Thus, this example should not be too complicated in fact. For your first example, a more detailed look could probably make modeling easier. E.g., there are also seperate area codes for the eastern and western side. This immediately allows to specify the claim birth place: Lloydminster exactly by adding for example qualifiers postal code: 780-205 and province: Alberta. In fact, as the city has been split in the past, it is likely that there are still quarters which reflect this. They allow then an even more exact specification. However, if you do not have exact sources it is simply not possible in this case to specify the correct province. Thus, nothing speaks against the general implication that if A was born in Lloydminster, A was born in Alberta or Saskatchewan. Absolutely correct.  — Felix Reimann (talk) 07:59, 12 August 2013 (UTC)
Stockholm County (Q104231) is a county, while Södermanland (Q626062) and Uppland (Q203509) are the two Provinces. The definition of Stockholm (Q1754) is very vague, it is not a well defined area, it depends on who you ask, but it is always located in 2 Provinces. But the urban area of Stockholm: Stockholm urban area (Q94385), is well-defined. It is located in parts of 12 Municipalities. In these 12 municipalities are located also other urban areas and also rural areas. Geber (Q10503520) is for example also located in Stockholm Municipality (Municipality=City in Sweden, but I prefer Municipality, since City is a pre-1970-term). One Problem here is that if I tell that Stockholm County is located in Uppland Province, then Uppland is partly located in Uppsala County and Uppsala County is partly located Västermanland Province and Västermanland is partly located in Örebro County, who is partly located in Värmland Province. If we are not carefull, I would imply that Stockholm is located in Oslo. This is not a problem for a Homo Sapiens, but for a Template, or a robot... -- Lavallentalk(block) 08:30, 12 August 2013 (UTC)

Big list of merge candidates

Any Wikidatans that specialise in merging items should take a look at User:Byrial/Items with link only to simplewiki, particularly the categories lower down in the page. Many of them just need merging with the equivalent page in en.wikipedia. I'm working on it slowly but it is more than a one-user job! Delsion23 (talk) 23:34, 11 August 2013 (UTC)

Language Links for Wikipedia Articles / Sprachen-Verweise für Wikipedia-Artikel

The Wikipedia articles

  • English: Marine clay


  • German: Klei

mean the same subject. I tried to add a language link, but with no success; I received the error message:

  • Site link Klei is already used by item Q1503599. Perhaps the items should be merged and one of them deleted? Feel free to ask at Project chat if you are unsure.

Who can help?


Die Wikipedia-Artikel

  • deutsch: Klei


  • englisch: Marine clay

bedeuten denselben Begriff; ich habe versucht, für beide Artikel Sprachen-Querschaltung einzufügen; das ist mir aber nicht gelungen – ich erhielt die Fehlermeldung

  • Site link Klei is already used by item Q1503599. Perhaps the items should be merged and one of them deleted? Feel free to ask at Project chat if you are unsure.

Den Sinn dieser Meldung habe ich leider nicht verstanden. Wer kann helfen?


Ein Wikipedia-Artikel kann immer nur bei einem Wikidata-Item verlinkt sein. de:Klei hat ein eigenes Item, Q1503599, deshalb kann es nicht ohne Weiteres zu Item Q2121110 mit en:Marine clay und den anderen hinzugefügt werden. Soll das doch gemacht werden, findest du die notwendigen Schritte und Möglichkeiten dafür unter Help:Merge/de beschrieben. (Kurzfassung: Zuerst den Sitelink Klei aus Item Q1503599 entfernen, ihn dann zu Q2121110 hinzufügen, dann Q1503599 löschen lassen.) --YMS (talk) 08:00, 12 August 2013 (UTC) PS: Hilfe in deutscher Sprache gibt's (auch) unter Project:Forum. --YMS (talk) 08:00, 12 August 2013 (UTC)

connecting pages — Preceding unsigned comment added by (talk)

Both articles have (different) German and Netherland interwikis, so they cannot be merged. --Michgrig (talk) 14:57, 13 August 2013 (UTC)
They are also both about different things so should not be merged. ·addshore· talk to me! 09:02, 14 August 2013 (UTC)


Some items don't have meaning on their own because they are extensions of a main item. They are usually connected in Wikipedia using Template:Main (Q6797933). I was wondering if it would make sense to reproduce this kind of relationship in Wikidata like William Shakespeare (Q692) <has subitem/subitem of> Shakespeare's life (Q8018307), or Finland (Q33) <has subitem/subitem of> history of Finland (Q202808). What do you think? --Micru (talk) 22:20, 13 August 2013 (UTC)

Interesting idea, but it should be discussed at the Property Proposal page. --Jakob (Scream about the things I've broken) 23:09, 13 August 2013 (UTC)
Ok, I have started the proposal for the pair "has subitem / subitem of".--Micru (talk) 23:22, 13 August 2013 (UTC)

Tool to check if there are any articles in a category without connections on Wikidata or with local interwikilinks

Is there a tool for use on Wikipedia/Wikivoyage to check if there are any articles in a specific category without connections on Wikidata or with local interwikilinks? Romaine (talk) 02:48, 14 August 2013 (UTC) does this. However, among its several limitations are missing support for Wikivoyage and for subcategories. --YMS (talk) 05:51, 14 August 2013 (UTC)
I just saw that Wikivoyage actually is there. Please ignore and forgive my comment about this being a limitation. --YMS (talk) 12:21, 14 August 2013 (UTC)
Thanks. Nice tool. The data might be at least 4 months old, but, as it hadn't changed much since, it worked fine. --  Docu  at 12:42, 14 August 2013 (UTC)
.. it starts updating. Great! --  Docu  at 12:51, 14 August 2013 (UTC)


Hi. Could somebody help User:JAn Dudík? User:JAnDbot and User:KrBot seem to be on an edit war. See revision history of nitratine (Q2622967, User talk:JAn Dudík#JAnDbot) and Adolf Medzihradský (Q10709408, User talk:JAn Dudík#Check if commons cat exists before adding p373). Regards --Chris.urs-o (talk) 10:04, 14 August 2013 (UTC)

This task - importing commonscat from is now finished. All non-existing links which will be removed now according to Wikidata:Database reports/Constraint violations/P373 will be in maintenace category on for manual check. But before there were thousands of articles, so checking every one was not possible. JAn Dudík (talk) 10:10, 14 August 2013 (UTC)

Displaying links from/to sources in Wikipedia

I have started a new conversation about how to display links to/from sources in Wikipedia. It might be useful to collect some ideas on the topic to be ready when that might happen.--Micru (talk) 13:25, 14 August 2013 (UTC)

Incapacidad permanente/Incapacité permanente/Incapacitat permanent

Hi, I can't link Incapacitat permanent in catalan and Incapacité permanente in french with : Incapacitad permanente in spanish (it's about the same subject) : the problem occurs here. I don't see where the problem is. Thanks for your help. --Franz53sda (talk) 16:35, 12 August 2013 (UTC)

The problem is that you have the wrong Spanish spelling: it's es:Incapacidad permanente. But it's not clear that the items should be merged since the article is about this concept in the labor laws in Spain whereas the one on is about the concept in French labor law. Mergehappy (talk) 16:49, 12 August 2013 (UTC)
Thanks for your answer. So in this way, shouldn't the catalan article which is global and neutral, be unlinked from the french article that concerns a specifically french labor law ? Sorry for all this questions, I just want to be sure to understand. Best regards. --Franz53sda (talk) 18:34, 12 August 2013 (UTC)
You can consider the French and Spanish articles to be incomplete and suffering from localism and link them, and the catalan page to a wikidata page dealing with the concept globally.
Alternatively you can have separate wikidata pages for the articles about the french and the spanish laws and for en:Incapacity Benefit (which deals with the English law) and en:Ontario Disability Support Program all 'part of (P361)' the Wikidata page for the concept (with a sitelink to the catalan page). Filceolaire (talk) 02:57, 15 August 2013 (UTC)

Qualifiers of property pairs

I was going to add some start time (P580) to the members of Opeth (Q18557), but it is not clear to which item I should add them, to the band, to the members, or to both? Ideally it should be displayed in both, but it seems redundant to add it manually...--Micru (talk) 06:12, 13 August 2013 (UTC)

It didn't answer your question, but I think some other properties are wrong. E.g. "country" for a band. Or "has parts" for the musicians. For the last I think performer (P175) would be better. It's confusing anyway, since we have cast member (P161), member of sports team (P54) and member of political party (P102), a "member of band" (or similar) would by logical. Or even better a general "member" for all of them (except "cast member" perhaps). --Nightwish62 (talk) 06:46, 13 August 2013 (UTC)
Following your suggestion I have started the PP for "has member" which could be combined with "as" too. performer (P175) is not appropriate because it refers to interprets of songs, not to members of bands. What about the original question?--Micru (talk) 22:00, 13 August 2013 (UTC)

start time (P580) refers to the date the band was started. For the dates the various band members joined use start time (P580) as a qualifier to the 'has member' properties for the band or the 'member of (P463)' property of the musicians. Filceolaire (talk) 03:07, 15 August 2013 (UTC)

How to link one page to two pages in language link?

Sometimes we need to link one page to two pages (or even more pages) in language link (in the bottom left-hand corner of the Wikipedia). For example, the English word "cousin", we need to link to two Chinese pages, i.e. 堂親/堂亲 (paternal cousin) and for 表親/表亲 (maternal cousin). There is no such thing as "cousin"(without paternal or maternal) in Chinese. Relatives have different calling between paternal and maternal. Relatives also have different calling between masculine and feminine. There is no such thing as "neutral" calling for relatives. But there is neutral calling in English, so I need to link them to two or more different pages, but it is not allowed in Wikidata. What should I do? --Yejianfei (talk) 18:02, 10 August 2013 (UTC)

As you say, this cannot be done with Wikidata. However, you can still do it with traditional interwiki linking. Both pages on the Chinese Wikipedia can link to the English article ([[en:cousin]]), but the English article cannot link to both (this has never been possible). The English article will have to link to one or the other. As far as Wikidata goes, I think the Chinese articles should have separate items they are different than the English article. Basically, "cousin", "paternal cousin", and "maternal cousin" should all be different items on Wikidata, but interwiki linking can help link the Chinese articles to the English one, and vice versa (partially). The Anonymouse (talk) 18:13, 10 August 2013 (UTC)
The previous local system on interwiki links allows several ways how to try to treat such cases (but not all interwiki bots were able to handle them correctly). Generally,
  • the more special article in one language can link to the more general article in other language through anchor link (Article#Caption) if the target article has a correcpondent section (however such link is on-way, the target article doesn't link backwards, and in addition, Wikidata don't allow and don't support such links). Identic interwiki links from two Chinese articles to one English articles is not so pure solution and can be confusing for bots and for people.
  • some cases can be solved through utilitarian or real dissambiguation page or redirect page (but Wikidata don't allow and don't support such solution). However, some solution could be to create a small Chinese mini-article (about the English meaning) which can be linked from both from the Wikidata item and from the two Chinese articles. But such miniarticles need a support from the local Wikipedia community to be not deleted or changed to redirect pages.
  • prospectively, some types of Wikidata properties could be usable to treat similar "quasiinterwikis" (to display interwiki to the closest higher item if the item itself have not its own article in some language etc.). However, Wikidata Team wrestle with more simple and basal problems for now and I doubt such very sofisticated solution for relatively rare cases would be achievable for them.
--ŠJů (talk) 13:04, 11 August 2013 (UTC)

There are a number of ways of dealing with this:

  • You could persuade the chinese wikipedia to deal with both of these concepts on the same page, just as 'Left' and 'Right' are combined on the same page on many wikipedias. There should be still be two wikidata pages (for 堂親/堂亲 (paternal cousin) and 表親/表亲 (maternal cousin)) each marked as 'part of' the page for first cousin (Q76666).
  • You could manually add links to all the "cousin" pages in other languages to both the Chinese cousin pages, overriding the wikidata links.
  • You could hope that bug 52564 is fixed so links to redirect pages can be added to wikidata. This will mean that for those wikipedias which have redirect pages for 'maternal cousin' and for 'paternal cousin' to 'cousin' can be added to the wikidata pages for 'maternal cousin' and 'paternal cousin' and be automatically added to chinese wikipedia. It doesn't help in the other direction.

Hope this helps. Filceolaire (talk) 02:42, 15 August 2013 (UTC)

  • Comment: "paternal cousin" is not a 'part of' the "cousin" but a 'subclass of'. Infovarius (talk) 08:25, 15 August 2013 (UTC)


This tool in my opinion must be active by default and option delete merged page and use lower Q too, because there are tons of merged page not deleted or who have lost labels and descriptions,should be changed also the merge help page telling to use the tool. It also be improved because if there is a edit conflict on RFD returns an error and don't put the merged item on RFD page Rippitippi (talk) 16:33, 14 August 2013 (UTC)

This is useful in the short term. As wikidata gets busier we will get even more edit conflicts on the 'page delete' page so longer term, once 'wikidata redirect' has been created, this template should automatically redirect pages instead of requesting delete. As it will be easier to undo a redirect than to undo a page deletion, therefore page redirect won't have to be limited to authorised users, like the page deletion has to be. Redirecting pages, rather than deleting them, will be important as wikidata is used by others, to keep urls alive. Filceolaire (talk) 03:28, 15 August 2013 (UTC)
A redirect in data is completly useless in my opinion, and only creates problems in order to use and mantain the data Rippitippi (talk) 16:49, 15 August 2013 (UTC)


Is there an upper limit on the number of statements that any one item should have? In specific, should the contains the administrative territorial entity (P150) info at Lycoming County (Q495633) be removed (note: there are 42 more p150 statements to add to that specific item)? --Jakob (Scream about the things I've broken) 19:20, 14 August 2013 (UTC)

No hard coded limit. Province of Turin (Q16287) have more of 300 properties --ValterVB (talk) 20:24, 14 August 2013 (UTC)
Contains administrative division needs to be deleted for precisely this reason. See WD:PFD. --Izno (talk) 22:00, 14 August 2013 (UTC)
Provided each subdividision has 'is in administrative division' to link it to 'Lycoming County' then I wouldn't waste my time adding the reverse property to Lycoming County. The "what links here" tool can provide this info. Your time could, in my opinion, much more usefully be spent adding "type of administrative division" information to each of the subdivisions. Filceolaire (talk) 03:35, 15 August 2013 (UTC)
+1. Reverse property will lead to unconsistency put the value only once and follow a bottom approach. Snipre (talk) 12:31, 15 August 2013 (UTC)

Commonscats in wikidata?

Hello, I have made correspondence lists between code INSEE and commonscatname for the municipalities of France, by groups of appr 6 departments: Commons:User:Havang(nl)/INSEE 01-06 , 07-12, 13-18 etc, see my subpages [15]. Checking a few at wikidata, I wondered: why aren't the commons categories active links? --Havang(nl) (talk) 12:04, 15 August 2013 (UTC)

You might need to activate "AuthorityControl" on Special:Preferences#mw-prefsection-gadgets. --  Docu  at 12:20, 15 August 2013 (UTC)
Ah, that's good to know. Never would have guessed that (though of course, reading the description would at least have shown that it's probably useful for some other properties besides Commons category). And like most Wikidata-specific gadgets, I don't see why they are not activated by default. --YMS (talk) 12:51, 15 August 2013 (UTC)
The description probably dates from when it was first added. It can be updated at MediaWiki:Gadget-AuthorityControl. From the preference page, it appears that it is activated by default now. Maybe this doesn't apply to older accounts. --  Docu  at 13:48, 15 August 2013 (UTC)
For a list of items with INSEE municipality code (P374), but not Commons category (P373), see[%22P374%22%2C%22!P373%22]
Cheers. --  Docu  at 15:22, 15 August 2013 (UTC)

Wikivoyage getting data access (aka phase 2) soon

Heya folks :)

Just a quick note that I just notified the Wikivoyage communities about this: We're planning to enable data access for Wikivoyage on 26th of August. Please let me know if you have any questions.

Cheers --Lydia Pintscher (WMDE) (talk) 14:15, 15 August 2013 (UTC)

Museum - organization vs. structure

I have a question and has not been able to find an answer in the archive...

For a museum like Musée du Louvre, I find it naturally to find main type (GND) organization, as we are taking about the entity that hords pieces of art.

Then I get confused when a find a claim that structure type is palace?

In my understanding, the organization Musée du Louvre might have a reference to a geograpical feature like the Louvre Castle and the Louvre Castle should have the structure type claim?

--VicVal (talk) 05:27, 15 August 2013 (UTC)

There are different items: Louvre Palace (Q1075988) and Louvre Museum (Q19675). Don't mix subjects. Snipre (talk) 08:18, 15 August 2013 (UTC)
Problem is that in many cases there is only one item for both institution and building and linked articles contain content about both of them. So even if you create new item and add appropriate properties, you cannot link the article (with content about both) to both of them. --Jklamo (talk) 09:49, 15 August 2013 (UTC)
Indeed. I tend to add them to "geographical feature", as we do with buildings. --  Docu  at 10:01, 15 August 2013 (UTC)
@Snipre - Agree, that's the reason why I don't understand the structure type on the museum item and the missing link from the museum to the castle.
@Jklamo - my problem, exactly!
@Docu - I don't understand, can you elaborate?
--VicVal (talk) 12:13, 15 August 2013 (UTC)
Just add {{P|107)) = geographical feature (Q618123). --  Docu  at 12:30, 15 August 2013 (UTC)
Here I disagree! If the item is describing a museum, i.e. an organization, the structure type has nothing to do in here, as the item will become disambigous. If I find a finder tag on this item, is the then the founder of the palace or the founder of the museum within the castle? --VicVal (talk) 12:39, 15 August 2013 (UTC)
This might be possible by considering it is a compound item and by playing with applies to part (P518). But this still need one item for the building, one for the organization, + one for the composition. TomT0m (talk) 12:56, 15 August 2013 (UTC)
Maybe you want to differentiate further between the collection as such and the institution/organization holding it. --  Docu  at 13:42, 15 August 2013 (UTC)
Agree! --VicVal (talk) 14:42, 15 August 2013 (UTC)

As a side note, I'm quite unhappy that this discussion is about the GND main type classification as the main type is deducable from the class type of the item, but the converse is not true. We're doubling the work by reasoning by GND first. TomT0m (talk) 12:56, 15 August 2013 (UTC)

Well, as I try to get my feet wet, I've been looking for default claims to add and in lieu of a proper standard, I've resoned that the GND is on so many things, so I've been working from there. If the is instance of is a better place to start, I'll do that.
I'm not sure though what you mean by "doubling the effort"? --VicVal (talk) 14:42, 15 August 2013 (UTC)
You're doing a classification task with GND. It's good, except GND main type is not a very powerful classification system : only seven types, and no subclasses. So the classification work will have to be done again using 'instance of' and 'subclass of' which are a lot more powerful, there exists a museum class which gets a lot more information than the geographical feature main type class. I think focusing on GND main type is harmful because it diverts from the really interesting classifying work. TomT0m (talk) 14:52, 15 August 2013 (UTC)
I agree with TomT0m that 'instance of' 'museum' is more useful than the GND type.
Look at the discussion above on Wikidata:Project_chat#Subitems. I think the proposed "Has subitem/subitem of" properties would be the right ones to link the Louvre museum to the Louvre Palace. You can comment on this proposal. Filceolaire (talk) 17:27, 15 August 2013 (UTC)
I don't think it's a good idea, the relation between the palace and the museum can be precised by a more meaningful property like is located in, whereas if I understand the idea of subitem of it's some kind of meaningless property ... TomT0m (talk) 18:20, 15 August 2013 (UTC)
I think the GND is an easy to grasp concept for newbies like me. The documentation on P107 (P107) gets you going. Is there an easy reference to deduct the class hierachy for me to identify museum and to understand if there are meaningfull subclasses like artmuseum or historical museum? --VicVal (talk) 12:49, 16 August 2013 (UTC)
I would not say easy at the time I write this message, tools have to be developped and made more user friendly for that, but I created in a few seconds a query to get all (direct) subclasses of the museum class : here using (one of, I already saw one with a more usable user interface) the external wikidata query tool. When the third Wikidata phase will be launched things will get easier. TomT0m (talk) 13:02, 16 August 2013 (UTC)

New merge list: Different items with identical links to Wikipedia and Wikivoyage for same language

Hi, I made User:Byrial/projectmerge which lists different items with identical links to Wikipedia and Wikivoyage for same language. Many of these can be merged.

  • Warning 1: The list is huge (14810 merge candidates, 451021 bytes). It takes a while to load, and you may want to avoid it if you have a slow or small computer. Hopefully the next version will much smaller.
  • Warning 2: Don't just merge without checking that the items are identical. You will find cases where the items link to different places with the same name, and cases where one item links to a disambiguation pages and the other does not.

Byrial (talk) 18:43, 15 August 2013 (UTC)

  • Will merged items be removed from the list by a bot or should that be done manually? AutomaticStrikeout 18:52, 15 August 2013 (UTC)
The list is made from the lastest Wikidata database dump. I will remake the list when the next dump is available (in less than a week I hope), and then all merged items will disappear from the list, so there is no need to manually remove them. False positives can be moved to my global merge exclusion list at User:Byrial/merge exclusion, then they will also disappear at the next update of the list. Byrial (talk) 19:03, 15 August 2013 (UTC)
Great! can you split the list for language? Rippitippi (talk) 19:50, 15 August 2013 (UTC)
I can, but I hope to avoid the extra work as I foresee that the page soon will reach a manageable size. It ready contains many red links that will disappear after next update. Byrial (talk) 06:31, 16 August 2013 (UTC)

Why Lojban?

Why, when you want to add a language beginning with L, does Lojban always appear at the head of the list -- and stick there even when you type "la"? What's so important about Lojban? Andrew Dalby (talk) 12:20, 13 August 2013 (UTC)

You typed "lo" instead of "la" .. ?
"la" works for me. --  Docu  at 13:22, 13 August 2013 (UTC)
If the language you are trying to add is already there, "Lojban" might persist. --  Docu  at 12:43, 14 August 2013 (UTC)
Thank you for both suggestions, but no, those are not the answers. The list that comes up when I type L nearly always has "Lojban" at the top. If the server is responding really quickly, "Lojban" disappears when I type "la". But, bad luck, that doesn't always happen. So, today for example, I have added about 30 links to Latina, and at least 5 times I have been stalled by finding that I was adding a nonexistent link to Lojban. Well, I know Latina isn't that important to everybody, but Lojban isn't either! I'm just wondering why it has to be there at the top. Lojban is also among the 12/13 "common languages" listed in the prompt when I temporarily select a different language (top of the screen). Let's face it, Lojban is not a common language! Someone who designs Wikidata, it seems to me, must really love it. I can live with this little problem, but I'm just curious ... Andrew Dalby (talk) 19:37, 15 August 2013 (UTC)
It's pretty simple really. The list of results is sorted by language code. This is jbo for Lojban. All the other matches start with a l or upwards in the alphabet. --Lydia Pintscher (WMDE) (talk) 16:28, 16 August 2013 (UTC)
Not very convenient for me when I typing "ru" to get some "Runa Sumi" and "Rumansch" before "Russian". Can it be changed somehow? Infovarius (talk) 19:20, 16 August 2013 (UTC)
Bugzilla:51560. --Stryn (talk) 01:17, 17 August 2013 (UTC)

Using "Category items" as an automated way of adding statements

I have been thinking that category items could be used as a way of adding statements to the items they contain in Wikipedia. For instance Category:Compositions by Frédéric Chopin (Q7132896) could contain a mechanism to add "composer:Chopin", "GND:creative work", "instance of:musical composition" to all items that each category in each language contains, like Tarantelle in A-flat major, Op. 43 (Q6149758). About how would be the best way to do it, I don't know. Maybe as a template in the talk page? Or as qualifiers of a "Sandbox:category maintenance" property? Of course not all categories would be suitable to do this, and it would be necessary to have a bot running to keep new items up-to-date. Feasible? Worth the trouble? --Micru (talk) 22:31, 15 August 2013 (UTC)

As far as I know there are already several bots which are inserting statements based on Wikipedia categories. You're right, there are very much information which can be retrieved out of the categories and I'm also interested in that matter. But I also think we should look forward to replace categories with Wikidata at all. --Nightwish62 (talk) 13:17, 16 August 2013 (UTC)
Part of the Wikidata categories replacement can be the subclass/instance categorization system. This statement adding bot is similar to my autolabelling by class proposition : once we know the class of the item, we should know which properties we should add to all the instances of that class. Or more generally which models applies to that type. That's why I push toward a model based approach as the base of the community workflow. TomT0m (talk) 13:22, 16 August 2013 (UTC)
@Nightwish62: Yes I know about bots doing that, the problem it that it requires a lot of manual effort, and there are not enough bot operators to handle the volume, by using a "lower-tech" approach, like the one suggested, the barrier would be lowered and we could get more statements in less time.
@TomT0m: even then we could have two automatic systems, one attached to category items that add statements depending on the wikipedia category and another one that attaches classes to wikidata items used as "instance of/subclass of". --Micru (talk) 15:59, 16 August 2013 (UTC)

There is now a user friendly interface for editing infoboxes in Wikipedia. Can I suggest that once we have all the wikidata datatypes available then the next task should be to integrate the infobox editing in Wikipedia with editing the wikidata behind that infobox, complete with templates which suggest which properties should be used.
This should also be used whenever a new infobox is created so that the data is added to wikidata as it is added to the infobox. Filceolaire (talk) 19:07, 16 August 2013 (UTC)

Yes, that it is the plan for infoboxes, and they could even add some specific properties to the item they are connected to. Still that doesn't solve the problem of items without infoboxes like the one mentioned above (Tarantelle in A-flat major, Op. 43 (Q6149758)).--Micru (talk) 20:46, 16 August 2013 (UTC)

Merge or not to merge

I'd be tempted to merge Q3916099 and Q14325158 as they are both about the same Wikimedia philosophy, essentially: "Be confident and edit". However, what would the English label be, as they are both different. Delsion23 (talk) 23:46, 16 August 2013 (UTC)

I agree that they should be merged, but I wouldn't know what to call it either. Texugo (talk) 00:03, 17 August 2013 (UTC)
Be bold and plunge forward? :P --Micru (talk) 00:21, 17 August 2013 (UTC)
I appreciate the subtle irony of even discussing this topic, Micru :P Delsion23 (talk) 00:58, 17 August 2013 (UTC)
Just remember that anyone who is bold and/or plunge forward to merge them not only have the English label to consider but also 10 other labels for other languages where the title of the Wikipedia and Wikivoyage pages differ. And it is not just here this problem is; it can happen for all items which have both Wikipedia and Wikivoyage links. I think that generally the Wikipedia titles should be preferred as labels because that project is more general whereas Wikivoyage is more specialized. Byrial (talk) 01:07, 17 August 2013 (UTC)
I see that they are merged now with the Wikivoyage labels for languages which have Wikivoyages except for English. That is in my opinion a bad solution. The Wikipedia/Wikivoyage prefix should either be removed or changed to project:. Byrial (talk) 01:14, 17 August 2013 (UTC)
I was bold and changed it to just "Be bold". Also added Project:. As well, added the "Plunge ahead" as an alias, which seems natural. --Izno (talk) 01:44, 17 August 2013 (UTC)

Modelling intersected categories

Hi everyone, a bit triggered by the previous post. I wanted to post this earlier, but didn't got around it yet. How to model intersected categories? Let's first define intersected categories: An intersected category is a category that combines two or more atomic topics into one category. So for example Grote Kerk (Q1545193) is in Category:Churches in Haarlem (Q8369481). This intersects the topic church building (Q16970) with the location Haarlem (Q9920). Especially Commons has loads of these kind of categories mostly intersecting topics by location and by year.

We could add a new property "category intersects topic" which for Category:Churches in Haarlem (Q8369481) would contain church building (Q16970) and Haarlem (Q9920). This combined with category's main topic (P301) will be a really powerful source of information to improve our search engine and with that the find-ability of articles and media. Ideas? Multichill (talk) 14:58, 16 August 2013 (UTC)

I would rather see dynamic-categories on all projects. A lot of categories just work their way up in the administrative regions. That could all be queried from Wikidata. A dynamic map could be displayed at the top of the page that would have a button for "switch to parent administrative region". Switching to another administrative region or selecting a smaller division could be done by clicking on the map. --Tobias1984 (talk) 15:12, 16 August 2013 (UTC)
@Multichill: Could that information be inferred from "main topic of category" of parent categories, or would it have to be entered manually?--Micru (talk) 16:03, 16 August 2013 (UTC)
@Tobias1984: Of course, killing categories is the longer term goal. But before we can run, we first need to learn to crawl and than walk. If we do this the structured data becomes available so people can start building prototypes for this for example on toollabs.
@Micru: I think this can be done by a bot for a lot of categories. I did this in the past on Commons categories. Example logic: Take a name of a category ("churches in Haarlem"), split it on "in" ("churches", "Haarlem"). Look at the upper categories. A lot is possible here and it shouldn't be too difficult to keep track of progress. In the end every category has either category's main topic (P301) when it's atomic or the new property when it's some sort of intersection. Multichill (talk) 16:11, 16 August 2013 (UTC)
While interesting to classify category items, it still doesn't act on the real problem, which is poorly tagged items. Continuing with your example if we had all the items in the category "churches in Haarlem" tagged automatically with statements "instance of:church" and "is in the administrative unit:Haarlem", then as soon as queries are available we could have define the property "category is equivalent to query item:instances of churches in haarlem" and add it to the category item with similar results.
OTOH, if we had "category intersects topic", what would be the use of it?--Micru (talk) 17:25, 16 August 2013 (UTC)
Category intersects topic is just an intermediate step. Over time all article items should have the same information and more. It's the most useful for Wikimedia Commons. It will ease the transition to a different systemen. For example it becomes quite an easy query to get all the images of churches. You'll have <file> -> <category> -> <atomic category>. That's only 3 levels, that's very doable to index that. Multichill (talk) 17:58, 16 August 2013 (UTC)
It is doable, but the file in Commons will have a page like Wikidata, so that leaves us again with the same situation:
  • Using "category intersects topic": it doesn't add any information to the items and it has to be calculated every time. It is also unclear to me if the intersected topic can be correlated properly (for instance, topic is not the same as location)
  • With "automated statements": the statements are added to each item in the category and these statements can be in its turn used to generate a query items that would generate at least the same amount of results in the category.
As an example the Commons category Category:Churches in Catania would have its own category item in Commons and that item can contain a set of statements that will be applied to all media files in the category, like "is in the administrative unit:Catania" and "depicts:church".--Micru (talk) 00:32, 17 August 2013 (UTC)
This is here Manchester Syntax or similar stuff are interesting. This is not noted in this RfC as I planned it as an introduction, but classes in this syntax can be defined equally as a class on which we add manually all of it instances and as a kind of query (my technical term would have been predicate but it's not important), which express exactly what you proposed, the class images of Churches in Catania can be defined as an equivalent of is in the administrative unit <Catania> and depicts <church>. This is where modeling in the semantic web with classes is exactly what commons category seems to need. TomT0m (talk) 10:50, 17 August 2013 (UTC)

A Wikidata for Commons files

Reading the discussion above on intersecting categories reminds me of something I thought of which I have been meaning to propose here.

Lets move all the Commons file information onto Wikidata.

  • each commons file would have a page on wikidata
  • These would be in a new 'F' namespace
  • Each Fspace page would have a file name (including filetype extension) as well as a multilingual Label and a multilingual Description and Aliases.
  • Labels could be used as captions and ALT text.
  • All info on Commons file description pages would be moved by bots (with assistance from humans as required) to wikidata.
  • Wikimedia Commons Main namespace would become a user interface to the backend data on Wikidata.
  • Links from Wikidata Qspace to commons files would be replaced by links to the file description pages in Wikidata Fspace.
  • Links from Qspace to CommonsCategories would be replaced by 'image depicts' links on Fspace pages pointing to Qspace items
  • Commons categories would be replaced by wikidata queries in the wikidata Fspace.
  • Audio and Video files would.... hmm. Needs more thought.

What do you think? Filceolaire (talk) 20:07, 16 August 2013 (UTC)

That is already more or less planned: Wikidata for media info. It would be a separate repository in Commons, but in many ways connected to Wikidata.--Micru (talk) 20:41, 16 August 2013 (UTC)
Interesting. Any idea where can I see this proposal? Filceolaire (talk) 21:22, 16 August 2013 (UTC)
It is »this page«. In the talk page there is more info.--Micru (talk) 22:21, 16 August 2013 (UTC)
Thanks. I also just saw this discussion thread on the wikidata mail list. Filceolaire (talk) 22:42, 16 August 2013 (UTC)
The previous proposal and my post to the mailing list are just steps in that direction so we can slowly can start adding more metadata and gain experience on good (and bad) approaches. Multichill (talk) 06:57, 17 August 2013 (UTC)

of wikidata & article undeletions...

re-posting this from here:

i am not clear if this problem has been discussed before, but a cursory search showed me nothing on the subject.

whate-ever the case, fixing this issue should probably be consudered as a top-level priority; for the reasons as laid out below.

  • reposted from wp/en*


i'm posting this here, as a follow-up to an uncompleted conversation that i had in an undeletion request, some time ago.

i did a little digging, & unless something has changed in the intervening timespan, i have definitely found that

WIKIDATA inter-wiki links ARE NOT restored, when a deleted article is undeleted.

see here, for an example:


as you can see, once the article is red-linked @ wp/en, a bot @ wikidata goes through & erases the listing there. it might not be exactly "instantaneous", but it is a routine & automatic procedure.

what this means is that the inter-wiki links (if any) for a restored article NEED TO BE REPLACED MANUALLY, at least until someone develops a tool for it.

the real problem is with finding the correct wiki-data entry to re-link it to...

as far as i can tell, there is no trace left on the restored article page (or in history, at least from the time the item was added to wiki-data), to back-trace it. there might be something somewhere in the mediawiki database, that holds a record of the "connection", but it doesn't seem to be anywhere in userland.

& this is going to be important, i think. it may seem like a limited/small problem now, but if it's not fixed, it's going to grow into a HUGE pain-in-the-ass, & cost us many man-hours of wasted extra work; if we have to do this EVERY TIME an article is restored...

that, or we just accept a "lower-standard" of inter-wiki linking; which is exactly the OPPOSITE of what wikidata is supposed to achieve.

i'm going to cc a copy of this message over @ wikidata & seewhat they have to say; i'll cross-link that with here.

Lx 121 (talk) 05:40, 17 August 2013 (UTC)

  • end*

Lx 121 (talk) 05:40, 17 August 2013 (UTC)

Yes, that is a problem. It is correct to remove links to deleted wiki pages from Wikidata items so pages in other languages don't have bad language links, so what to do? The link removing bot could set item's label for the language of the removed link if it is missing as in the example above. That would make researching for the item after undeletion easier. The bots could also maintain a public log list of all links they remove. Byrial (talk) 07:37, 17 August 2013 (UTC)
Another problem is if the interwiki link was the only one in a given item, the item will also be deleted, which makes it even more complicated. However, a public log of interwiki removals would partially solve this. The Anonymouse (talk) 07:51, 17 August 2013 (UTC)
Yes, I first thought that it would be no problem because there will be no language links to restore in an undeleted page, so it could just get an new item. But if the deleted item had statements, they would have to be recreated. I guess it would be best if possible to find the old item in a link removal log and restore it. Byrial (talk) 11:01, 17 August 2013 (UTC)

Accessing date via Lua

The code[0].mainsnak.datavalue.value['time'] gives me the rather messy time stamp +00000001879-03-14T00:00:00Z for Albert Einstein. Is there a way to access the date like it is displayed at the item page, or do I have to convert it myself? --Njardarlogar (talk) 08:32, 17 August 2013 (UTC)

You got the data like it is stored so you have to convert it. Snipre (talk) 15:47, 17 August 2013 (UTC)

Who wants to help me make an article about Fist Puncher?

Hello. I'm Jesse Long and I have noticed that there is a new beat-em-up/brawler game for the PC and Xbox 360 that is called Fist Puncher. It is made by two companies that are called Team 2-Bit and Adult Swim Games. If anyone can help contribute to this article and/or have played this game, then please let me know some information about it, okay? Thank you for helping me on this article. Special:Contributions/2602:61:7450:E300:ADFA:DCBC:92DB:8C04

You are in the wrong place for Wikipedia articles. You should ask at en:Wikipedia:WikiProject_Video_games. Also, the item you created Q14613428, will be deleted soon if no article or statement is attached to it. --Tobias1984 (talk) 17:38, 17 August 2013 (UTC)

Wikivoyage: A lot of unconnected pages

Phase2 is soon to be enabled for Wikivoyage (see previous topic), but a lot of pages in Wikivoyage are still disconnected! See for example voy:en:Special:UnconnectedPages. I see that we have User:WYImporterBot so all the easy ones are probably already done. Is someone already putting effort in trying to get the remaining items connected? Multichill (talk) 17:28, 15 August 2013 (UTC)

I dropped a note in the traveller's page on en: and hopefully we can get those last 1551 articles hooked up. There are a little over a hundred on voy:pt that I will take care of myself. You might consider notifying the other versions of the existence of that special page. I didn't know about it until I saw it here just now... Texugo (talk) 18:33, 15 August 2013 (UTC)
I just realized the pattern for a lot of the missing links. It's the different disambiguation styles we have: w:Benson, Arizona vs voy:Benson (Arizona). I bet the bot didn't take that into account! Multichill (talk) 18:58, 15 August 2013 (UTC)
  • I have done most of the items starting by "A", the remaining either don't have an equivalent in any Wikipedia or they are just data files. I also noticed that the links to the Wikivoyage incubator are not working well, maybe you want to verify that too.--Micru (talk) 19:14, 15 August 2013 (UTC)
On ru.voy we managed to manually handle all of these cases in Russian. The majority of those are regional divisions which do not have natural analogs on Wikipedia and not (yet) were created in other languages.--Ymblanter (talk) 20:46, 17 August 2013 (UTC)

Key event property

The significant event (P793) property needs to be clarified in order to develop a homogeneous use of the property and an easy data extraction later in wikipedia. Please comment in the talk page Snipre (talk) 10:31, 18 August 2013 (UTC)

RfC for RfC

I think we should improve our RfC process: right there is no possibility to follow the progress of a RfC if you don't participate from the begining. So I propose the following procedure:

  1. A request for comment is composed of 2 parts: a discussion part and a decision part. The discussion part is used to define the questions, the framework and the conditions of the topic which is proposed in the RfC.
  2. The discussion part lasts at least two weeks and the decision part at least four weeks. If one part needs more time an extension can be decided. The deadline of each part has to be mentioned in the main page of the request.
  3. When a part starts (discussion or decision) an announcement has to be made in the Community portal in English. Announcement in the different project chats is strongly recommended.
  4. During the discussion chat the main page of the request should be keep blank of any comments or discussions. Only the results of the discussion should be displayed. The discussions have to their place in the talk page. The main page is used for the final decision part only. So each person opening the request page can see the current summary of the discussions.

Any comments ? Snipre (talk) 15:12, 18 August 2013 (UTC)

  Support I support this, but we should start an RfC for this, so that decision making is moved away from the English project chat. So I should say: I support starting an RfC about this. --Tobias1984 (talk) 15:44, 18 August 2013 (UTC)
OK Wikidata:Requests for comment/Guidelines for RfC process Snipre (talk) 16:12, 18 August 2013 (UTC)

Making WD entry titles more project-neutral

Since WD now incorporates Wikivoyage as well as Wikipedia (and will presumably include more projects in the future), it seems odd to name WD entries that contain links to maintenance pages common to both projects "Wikipedia:xyz". Take, for example, Q3938. Since WMF projects have a Project: namespace shortcut (e.g. w:ru:Project:Песочница; voy:fr:Project:Bac à sable), I suggest it would make sense to adopt the more neutral title of "Project:Sandbox" for Q3938, and mutatis mutandis for other such entries. It Is Me Here t / c 13:43, 18 August 2013 (UTC)

While we are at it, I suggest to review the descriptions guidelines to be sure they are not just a variant of the Wikipedia disambiguation pages guidelines. TomT0m (talk) 13:52, 18 August 2013 (UTC)

Soufflet à bouche, Blowpipe

An Item was created for "Soufflet à bouche" ( but it's strongly connected to Blowpipe (tool)

I don'tknow how to procede to delete Q3491508 What do you think of it Oimabe (talk) 14:45, 18 August 2013 (UTC)

Looks like a good merge to me - I've deleted the first item there. In future, you can request deletion at WD:RFD. Ajraddatz (Talk) 15:44, 18 August 2013 (UTC)

Help needed to improve Help:Qualifiers

Hi, since it is sometimes not very clear how to use qualifiers, I have started Help:Qualifiers so we can put there some examples and maybe a list of the properties that are used as such. I think that might be useful on the long term. Please, feel free to improve the page and then we'll add the translation templates.--Micru (talk) 18:06, 18 August 2013 (UTC)

It would be clearer if we add a better modeling system which could define which property applies to which type and which qualifier applies to each property and the meaning we give to that. Using Manchester syntax can be a start for that (see the RfC about type/instance relationship) TomT0m (talk) 18:12, 18 August 2013 (UTC)

Looking for help from a Catalan- and English-speaking user

Could someone please have a look at ca:Heró (escriptor bizantí) and determine whether it is en:Hero of Byzantium, en:Hero the Younger or someone else? Thanks! It Is Me Here t / c 14:00, 18 August 2013 (UTC)

According to the French Wikipedia en:Hero of Byzantium and en:Hero the Younger are the same person. According to the source cited by the Catalan Wikipedia, there is another person named Heron who wrote on agriculture. We now that there are different people because the works of the former still exist, while the works of the second were mostly lost.--Micru (talk) 16:34, 18 August 2013 (UTC)
OK, interesting; but what do you suggest the implications are for cataloguing the articles on Wikidata? My suggestion would be to list ca:Heró (escriptor bizantí) as a translation of en:Hero of Byzantium / fr:Héron de Byzance / etc., and then possibly start a deletion discussion at en: regarding en:Hero the Younger. It Is Me Here t / c 19:32, 18 August 2013 (UTC)
I have linked the corresponding article, w:ca:Heró de Bizanci, with en:Hero of Byzantium. As you said, en:Hero the Younger must be merged into en:Hero of Byzantium. However, ca:Heró (escriptor bizantí) must be left alone. In the Catalan Wikipedia there are more articles about ancient people named w:ca:Heró than in other Wikipedias, and that is fine.--Micru (talk) 23:35, 18 August 2013 (UTC)

Project Gutenberg references

I'm afraid I don't understand how the authority control properties work. There seem to be loads of them.
One authority control property we don't have is a property to link books to their en:Project Gutenberg edition.
Project Gutenberg has a number for each of their works. They are approaching 50000 at the moment.
As well as Project Gutenberg itself, based in the USA, there are also affiliates in Australia, Canada, Germany, Norway each of whom seem to have separate lists.

  • Does anyone else know anything about how Gutenberg organises stuff?
  • Do you guys think a property to link to this could be useful and worth doing?

If you think it's worth doing I will do some research into how the different indexes relate to each other and try to come up with a proposal. Filceolaire (talk) 21:23, 18 August 2013 (UTC)

The problem of PG is that, plainly speaking, it's a metadata hell. They don't record from which edition the text comes from, and that without speaking about other quirkiness... So if you want to link to them, then it is better to do that, just use a URL link, or alternatively link to the version stored in Internet Archive using Internet Archive ID (P724). --Micru (talk) 21:53, 18 August 2013 (UTC)
OK. I've added a link to the internet archive for Pride and Prejudice (Q170583), the second most downloaded Gutenberg text. Filceolaire (talk) 22:36, 18 August 2013 (UTC)

Problem with the table template in the property proposal pages

There seems to be something strange in the templates for tables at the top of the property proposal pages. I'm not that great on tables but it looks like the template for the headers doesn't match the template for rows.

I tried to do a table and couldn't make it work. User:Crissov has tried too for color properties but the info in his wikitext doesn't seem to match the rendered info.

Can anyone see what is happening here. Filceolaire (talk) 22:21, 18 August 2013 (UTC)

Commons recording

I have just added a link to a recording on commons to La Danza (Q1232797). I used image (P18) as I couldn't find a better property.

  • Is there a better property?
  • Any other suggestions as to how to link to audio and video recordings on Commons?
  • What about recordings on YouTube? Filceolaire (talk) 10:26, 19 August 2013 (UTC)
Use audio (P51) - audio and video (P10) - video. Byrial (talk) 11:01, 19 August 2013 (UTC)
PS, I found them by going to the property statistics page, sort by datatype and look for the commonsMedia properties. Byrial (talk) 11:05, 19 August 2013 (UTC)


In the Australian project 'Perth' as a sole word is the result of an ongoing edit war over years as to 'primacy'

  • Perth
  • Perth, Western Australia

are the two choices made to date.

In wikidata entry for Perth,( Western Australia) - with the qualifiers of 'Australia' and 'Western Australia' in other projects is it appropriate to corect issues in other projects or not?

Perth, Australia - is wrong and incorrect - Perth, Tasmania exists as well....

Any suggestions as to the Perth entry, and projects which get it wrong? thans for any help or advice sats (talk) 14:24, 19 August 2013 (UTC)

Fortunately at wikidata it is possible to have 2 (or more) items with same label and distinguish them by description, so there is no need for qualifier in label (and endless edit wars). --Jklamo (talk) 15:05, 19 August 2013 (UTC)
As an example, see Perth, Perth, Perth, Perth, Perth, Perth and last but not least Perth. Delsion23 (talk) 15:08, 19 August 2013 (UTC)

Hello community, I recently (just) closed a Requests for comment about the main type GND property. The consensus of this is that the property should be deleted. It is possible for this to be re-added in the future if a new RfC concludes in that it should be, for now it is not. Proposals may be made at PP for a new sorting property though exact duplicates of the existing system will not be accepted. John F. Lewis (talk) 17:17, 17 August 2013 (UTC)

Glad to hear 'main type' will be deleted. However, I've two questions I asked already several times, but no ones seems to be able to answer:
  • If a property gets deleted, are statements using the property still existing in the backend, but not visible in the frontend? Or with other words: If a property was deleted and undeleted, are the previous made statements also restored?
  • Is there any bot or any API command (in future) to move the values of one property to another? If we now delete 'main type' we loose very much information. So I hope there is a way to move the values to the property "is instance of". --Nightwish62 (talk) 18:34, 17 August 2013 (UTC)
+1 to moving P107 (P107) to instance of (P31).--Micru (talk) 18:43, 17 August 2013 (UTC)
We have to be careful with the migration. Some claims will be trivial to move, such as P107 = person on a page which also has sex or gender (P21). Others will not be, per all of the reasons that the property is "bad". I think we could probably move all cases where P107 = term without losing information, for example, because of how bad term is. We might need to put together a page (WD:Migration away from GND main type?) to see if there are correlations for this sort of thing, as well as things we can do to improve the current classifications. For example, at the same time that we're botting this, we should consider putting together an item which distinguishes person from human person (the latter being a subclass of the former), as GND is not too good with that distinction. Not every person is (or was) human! --Izno (talk) 18:59, 17 August 2013 (UTC)
  1. They exist and are visible in both places. This means that P107 will probably be deleted over a long period of time.
  2. See comment to Micru. We definitely need to migrate things! --Izno (talk) 19:01, 17 August 2013 (UTC)
(edit conflict) Much care is indeed needed. Nothing is trivial. Items with P107 = person and a sex statement are not all persons. Some (like Q172713 and others) are gods. Byrial (talk) 20:02, 17 August 2013 (UTC)
  CommentYou're right, but the point is, that the statement Q172713 -> main type:person was already wrong before. Moving 'person' to 'instance of' is sure also wrong, but cleaning this up is another task and shouldn't stop us from moving the statements out of 'main type'. --Nightwish62 (talk) 22:21, 17 August 2013 (UTC)
Byrial: Definitely! As I said, we should start the red linked item I have above. (It might help if we were to use the Wikipedia category scheme.)
Nightwish: I'm not sure I agree, but we should definitely coordinate so we can start asking these kinds of questions. --Izno (talk) 23:10, 17 August 2013 (UTC)
  Oppose for deleting P107 (P107). There is no consensus for deletion in Wikidata:Requests for comment/Primary sorting property discussion. — Ivan A. Krestinin (talk) 19:58, 17 August 2013 (UTC)
This is not a support/oppose thread. Your opinion was voiced in the RfC and my reasons for closing as it was were there as well. The property will be migrated soon hopefully. John F. Lewis (talk) 20:05, 17 August 2013 (UTC)
Your closing is not based on analysis of discussion and arguments. You ignore part of voices and arguments when write conclusion. This is bad way to reach consensus. — Ivan A. Krestinin (talk) 20:17, 17 August 2013 (UTC)
Sometimes it need a uncomfortable decision to make a progress at all. --Nightwish62 (talk) 21:34, 17 August 2013 (UTC)
Uncomfortable is not problem. Not based on consensus is problem. — Ivan A. Krestinin (talk) 06:58, 18 August 2013 (UTC)
You keep saying that as if you're the one who should make the judgement. You are not. Two separate uninvolved administrators (JohnLewis and Hahc) came to the same conclusion: GND main type needs to go. I suspect that TCN7JM below also came to that conclusion, and he's a third uninvolved administrator. --Izno (talk) 13:13, 18 August 2013 (UTC)

  Take note: A have enabled an abuse filter (#28) which will disallow new additions of P107. This can be seen a part of the migration as it is now preventing new additions and prevents re-adding removed ones by bots. John F. Lewis (talk) 21:12, 17 August 2013 (UTC)

Errrr no. I've disabled it. Just because something is deprecated doesn't mean you stop everyone from using it. Once we have a migration plan ready, start migrating all the uses, and then once it's all gone, delete the property. Legoktm (talk) 06:59, 18 August 2013 (UTC)
Dear John, I appreciate your effort but your conclusion is not backed by the rfc and your actions (like the abusefilter) are inappropriate.
Please stop going into this direction and first get real community support. Multichill (talk) 09:01, 18 August 2013 (UTC)
There was obvious consensus to deprecate P107. There were nine for keeping P107, and 24 against in both of the other sections. Therefore, there was "real community support" to delete the property. I've restored the version of the property that portrays this, and it is to remain at that revision. John's abuse filter may not have been the most appropriate, but his action to deprecate the property was most definitely backed by the RfC. TCN7JM 12:32, 18 August 2013 (UTC)
My 2 cents:
  1. it's August and some people could be on holiday. It's not the right period to make changes so much big.
  2. as I (tried to) explained in other discussions, I would like to discuss not only of theory, but also of practice: P107 (P107) is used in millions of items and it is also used in Constraint violations. So, we should discuss and find alternatives before to delete it, or we will generate only confusion!

--Paperoastro (talk) 12:53, 18 August 2013 (UTC)

Yes, we are going to migrate all uses of the property before it is really deleted. Right now, the point is to not add any more uses of it. TCN7JM 13:08, 18 August 2013 (UTC)
(edit conflict) I started two RfC which aims to be a start for those discussions : the first one about the class / instance relationship, which could be a base of future constraint violation system, and the second about how we discuss property proposals to move it to a more high level discussion about types definition and not only property definitions as it is now. TomT0m (talk) 13:10, 18 August 2013 (UTC)
  1. The discussion has been open for 7 weeks. No-one is on "holiday" for so long. Even in Europe, where it's common to have long vacations.
  2. That's true. I keep saying that and it seems no-one is listening. Let's start a new page (like the one I linked above, WD:Migrating away from GND main type, so we can talk about it!
--Izno (talk) 13:13, 18 August 2013 (UTC)

I agree with the decision to no longer use the GND's classification system as Wikidata's main type. But I also think there could be some use in having the GND type added to items that alreadyd include the GND identifier. The DNB uses a different classification system then the LoC, as do various other national libraries and authority control systems. So for example, some ships are classified as "corporate" by the LoC ([16]) and as "Sachbegriff"/"Term" by the DNB ([17]). It could be useful to add such external classifications to items as separate properties. But of course only to those items that already include corresponding GND IDs or LCCN properties, so we can use bots to simply import the information from external databases. Not as a choice for users to try to somehow fit items into those classification system even if there are no corresponding authority records. --Kam Solusar (talk) 19:08, 19 August 2013 (UTC)

Adding instance of (P31)

(edit conflict)I have started the discussion on the property Wikidata maintenance, which could be used to perform automated jobs based on categorized items, like for instance adding instance of (P31)=>person (Q215627) to articles that are in the "living people" category. This method can be used no matter if P107 (P107) is deleted or kept.--Micru (talk) 20:10, 17 August 2013 (UTC)

I think that's premature. Let's start the red linked page I suggested above so we can talk about how best to go about doing this. (In short though, I don't see the need for that property.) --Izno (talk) 23:12, 17 August 2013 (UTC)

Retain as qualifier

Why not retain P107 (P107) as a qualifier for GND ID (P227)? This more exact then this. --Succu (talk) 21:22, 17 August 2013 (UTC)

That seems reasonable as long as it is optional and not mandatory as before.--Micru (talk) 21:29, 17 August 2013 (UTC)
An example. --Succu (talk) 21:39, 17 August 2013 (UTC)
People will start using this as property again, whatever it should only be used as qualifier. Since we didn't have a 'real time' constraint check, which avoid entering invalid statements at the moment they are made, this will just lead to much constraint violations. Moreover: It would be a very bad usage for a qualifier. A real qualifier refers always to the relation between the item, the property and the value. Example:
item: New York city
 property: head of government
  value: Rudy Giuliani
   qualifier: start date
    value: January 1 1994

The qualifiers refers to all three parts (item, property and value) and state in which way they are linked together / under which condition the statement becomes true or not (as Giuliani was not always the head of government of NYC). But adding P107 (P107) as qualifier GND ID (P227) do not, it just refers to the item itself. There is no reference to the statement on which the qualifiers is added. I saw many wrong usage of qualifiers already and your idea will further promote wrong usage of qualifiers. --Nightwish62 (talk) 22:12, 17 August 2013 (UTC)

people will start using this as a property again: I think that that is a good thought for all of those that are now trying to delete main-types based on a RfC where about 40 people voted. Our community has 9000 members of which many don't frequent the English project chat and the English-only RfC system. I think deleting our most popular property should involve more than just 0.44 % of our community. In my opinion before we do anything else we need an all-language RfC with a prominent message on the header of the page. Otherwise deletion will start and hundreds of people are going to complain that they didn't even hear about the RfC. --Tobias1984 (talk) 08:53, 18 August 2013 (UTC)
It is absurd to call P107 (P107) the most popular property. It is the second most used property (after imported from Wikimedia project (P143)), but it is not popular. Byrial (talk) 09:16, 18 August 2013 (UTC)
The popularity/usage of P107 (P107) is not the point I was trying to make with my message. Again: Our RfC system itself has been questioned before for being language-biased. And for an important decision like this it would have been nice to have at least 2 % of the community. --Tobias1984 (talk) 09:37, 18 August 2013 (UTC)
Your point that ""people will start using this as a property again" is true, but not because it is the most popular. It is simply the most used, and for the most part, is is only the most used because it was a) the first and b) added by the bots, and not because it was organic or that it makes sense to use it, as argued in the RFC.
"Our community has 9000 members of which many don't frequent the English project chat and the English-only RfC system." The latter is not true. The RFC system, as can be seen by multiple editors' involvement, is certainly multilingual. As for those 9k members, I hate using that phrase. There are 9k editors, not all of whom are active participants in the backend.
"Otherwise deletion will start and hundreds of people are going to complain that they didn't even hear about the RfC." That seems to be the grief we're already getting, and all of you have heard about it, which suggests to me that this isn't about the RFC or how many people were involved. But, assuming you mean that in good intentions, let's start WD:Migrating away from GND main type so people will get on board with the conclusion of the RFC! --Izno (talk) 13:13, 18 August 2013 (UTC)
@Izno: I guess you missed that the first sentence of my comment is a quote. And my comment was a mere criticism of our current RfC system and its turnout. As for this discussion: I think the most important thing is that we draft a message about the deletion of p107 and then deliver it to all languages of the project chat. --Tobias1984 (talk) 13:28, 18 August 2013 (UTC)
"@Izno: I guess you missed that the first sentence of my comment is a quote." That is not apparent. In English, we use quotation marks for quotations. :)
"And my comment was a mere criticism of our current RfC system and its turnout." Sure, you might levy that criticism. I'm not sure I agree; for example, the main RFC page doesn't have multiple languages associated with it. You might take that to mean it is English-centric; I would personally take that to mean that there is one, and only one, place to go for centralized RFCs. There might be a good case to be made that anything major must have an RFC, rather than just a project chat, so that other languages have one place to watch... Just a thought.
"As for this discussion: I think the most important thing is that we draft a message about the deletion of p107 and then deliver it to all languages of the project chat." Absolutely. Go add that to the migration page. :) --Izno (talk) 14:47, 18 August 2013 (UTC)
If you want to know my opinion, it's very difficult to understand what's going on in Wikidata. Things are not well explain (like qualifiers, I just realize now how they really work. If I knew that before, I would never do this.), discussions are mainly in English that becomes hard to follow and discourage the giving of opinion from less fluent users (like me) and, because things in Wikidata change discretely and quickly, most users don't have the opportunity to agree or disagree the proposes that an small elite here do. - Sarilho1 (talk) 15:14, 18 August 2013 (UTC)
Sarilho1: Yes, now you got it. This was a wrong usage, therefore I removed it. For those who are interested how the item was before: [18]. I really would write a site which explain when using qualifiers and when not, but my English is too bad. Is someone there who would translate it to English when I'm writing it in German? Give me a message to my talk site. --Nightwish62 (talk) 15:59, 18 August 2013 (UTC)
Lot of comments about my phrase that people will start using the property again. But that was just one of two arguments and the second one (wrong usage), is even more worse for me. --Nightwish62 (talk) 15:54, 18 August 2013 (UTC)
On a second thought, I agree with Nightwish62 about that one wrong usage might lead to other wrong usages. I have started Help:Qualifiers, so we can define there what are the acceptable uses of qualifiers.--Micru (talk) 18:03, 18 August 2013 (UTC)
Please don't retain as qualifier. Filceolaire (talk) 10:44, 19 August 2013 (UTC)
Just a funny thought which came to me about this: It's quite similar to the situation of some incompetent high-ranking employees (e.g. managers). You can't really use them, but they can't be fired because they have allies/supporters? Just give them a new position ;) --Nightwish62 (talk) 17:13, 19 August 2013 (UTC)
Some say that Swedish Governors get their job that way! :) -- Lavallentalk(block) 17:20, 19 August 2013 (UTC)

Deleting the most-used property without a proper request and discussion at Wikidata:Properties for deletion?

Wikidata admin User:John F. Lewis has stated that the most-used wikidata property that has already survived two deletion debates shall be deleted, but I do not find this RfC page linked at the proper place, that is Wikidata:Properties for deletion. In my view, more users would have voiced their opinion if there had been a proper deletion debate, at least linked from Wikidata:Properties for deletion. Is it a valid procedure to decide on the deletion of properties without at least notifying Wikidata:Properties for deletion? --UV (talk) 21:43, 17 August 2013 (UTC)

Properties for deletion is a place for noncontroversial deletions. P107 was brought there twice and there was a much heated debate about it. Therefore, a broader request for comment was held, which gets way more input than your common PfD. And, as a side note, we don't need to "notify" Properties for deletion. It is neither an entity nor a group that needs to be notified. — ΛΧΣ21 21:50, 17 August 2013 (UTC)
+1 to your above hahc21. ·addshore· talk to me! 08:11, 18 August 2013 (UTC)


Stop starting discusions everywhere. On the topic of wikidata classification we have already 2 pages:

Please merge these 2 pages into a new RfC: RfC is the normal process to discuss topic at community level. Snipre (talk) 15:42, 18 August 2013 (UTC)

High level classification was started awhile ago, but it's not really pertinent now. I asked people to start the first page, because having the discussion here about how to perform the migration is quite frankly silly and will also blow up this page. --Izno (talk) 16:33, 18 August 2013 (UTC)
But before any migration we need to define the new classification and once we will finish the migration, we need a help page to describe how the classification system works in wikidata. So better to start with a RfC, which is now a wellknown process for discussion and once we finish the discussion we can start the help page. Snipre (talk) 18:09, 18 August 2013 (UTC)

merge Q1334579 and Q6758988

Aloha, just tried to add en:Mares (scuba gear company) to Q1334579 but received an error due to the existence of Q6758988 - I am not sure how this merging stuff is working so maybe this can be done by someone who knows how to do it. thx in advance --Lofor (talk) 19:39, 18 August 2013 (UTC)

Done! If you even encounter this in the future, you can remove the link from one, add it to the other, then request deletion of the one without links at WD:RFD. Thanks :) Ajraddatz (Talk) 20:13, 18 August 2013 (UTC)
Is important merge label an desctiption or alias too Rippitippi (talk) 22:09, 18 August 2013 (UTC)
Thanks, will keep that in mind :) --Lofor (talk) 19:12, 19 August 2013 (UTC)

Create property or not?

Can someone review Wikidata:Property_proposal/References#date_retrieved and decide if this property can be created or not? There was a lively discussion but it seems to have died down now. As nominator I think the consensus is for creation but others may have a different opinion. Filceolaire (talk) 23:12, 19 August 2013 (UTC)

I've created the property at Property:P813, and given my rational for doing so on the property proposal page. Ajraddatz (Talk) 14:58, 20 August 2013 (UTC)

Translation help

I am doing some work on Help pages but I am not familiar with how the translation tagging system works and I don't want to mess it up. Is there a help page for this on Wikidata or on one of the other projects? Is there a tool I should be using? Filceolaire (talk) 01:27, 20 August 2013 (UTC)

Are you editing help pages that already have the translation tags? If so, you don't need to add/change/remove any of them, since a translation administrator will use the Translate extension to do this automatically. Also, the full documentation is available at this page. The Anonymouse (talk) 04:14, 20 August 2013 (UTC)

The pages do have tags, thank you. Filceolaire (talk) 07:43, 20 August 2013 (UTC)

Reusing new items

When I know for sure an article exists in another language, I assume there is a Wikidata item out there for it. The search is problematic, so sometimes I don't find it until I have already created a new item and receive an error when I add the interwiki. I generally have some other articles without items that I can then use to fill the item number I just created. This happened to me today with Q14623807. My question is, is it OK to do this, or should I always request deletion of the mistakenly created new item? Jane023 (talk) 10:25, 20 August 2013 (UTC)

Yes Jane, it is ok for recently created items. It is also ok to request deletion.--Ymblanter (talk) 10:46, 20 August 2013 (UTC)
Great, and thanks for the quick reply! Jane023 (talk) 11:01, 20 August 2013 (UTC)

Adding th-article

Can somebody try to add this article th:ภาวะพบร่วม_PHACE to this item PHACE association (Q3377927). I already deleted the other item but I get an error when trying to add the th-article. --Tobias1984 (talk) 10:32, 20 August 2013 (UTC)

  Done--Ymblanter (talk) 10:48, 20 August 2013 (UTC)

w:Thymos moved to w:Thumos lost most of the interlanguage links

Talk:Q163987  – The preceding unsigned comment was added by Pashute (talk • contribs) at 13:06, 11 July 2013 (UTC).

That's all right now I suppose. Infovarius (talk) 09:15, 20 August 2013 (UTC)

Grammatically, "Thumos" is a word completely wrong for the Greek language (is a new Greeklish word, something between Greek and English). Only "Thymos" can be used in every relevant word. Rhythm can't used as Rhuthm; or Neurons as Neyrons; etc. because the letter "u" in Greek language can be used only as a "v" or "f" of "ph". So, Euthymos is Ephthymos (Εύθυμος); Europe is Evrope (Ευρώπη); Thumos is Thvmos or Thfmos or Thphmos (completely word); etc. One of the many examples is the Greek name Euthymos (Latin: Euthymus) see Euthymus (and all other relative words) in the Dictionary of famous lexicographer William Smith. The article name "Thumos" is not belong in a Wikipedia of a professional level. --Francois-Pier (talk) 19:30, 20 August 2013 (UTC)

The article in 2 items!

How is this possible: identical be-link in both Category:History of Japan (Q9818374) and Category:History of Japan (Q4424)? Infovarius (talk) 05:33, 21 August 2013 (UTC)

Even identical items with 2 identical links! Q10233082 and Q9923939! ??? --Infovarius (talk) 05:40, 21 August 2013 (UTC)
See Wikidata:True duplicates. I'll merge these and make a note on the True Duplicates page. The Anonymouse (talk) 05:46, 21 August 2013 (UTC)

New database dump and updated database reports

Hi, I have updated most of my database reports to the new 2013-08-17 database dump. New or noteworthy things this time are:

  • The new Tuvinian (tyv) Wikipedia and Vietnamese (vi) Wikivoyage are included in the language statistics for items
  • The number of items with Commons category (P373) is increased with more than 37,000 and has passed 800,000. A consequence is that all the commonsmerge lists with merge suggestions based on same Commons category for different items have grown in size.
  • The new projectmerge page, first made only 4 days ago, is decreased in size, but it is still very large (306,492 bytes) and may still cause trouble for slow/old computers. It lists different items with identical links to Wikipedia and Wikivoyage for same language. Many of these can be merged. There are many German (de), English (en), French (fr), Spanish (es), Polish (pl), Portuguese (pt) and Romanian (ro) links to check on the list.
  • The list of used disambiguations is as usual large. If you are looking for some way to help Wikidata, other than the many merge lists, it might be an idea to fix some of the cases where items which link to disambiguation pages are used as values in statements.
  • As usual there are many lists of merge candidates for items based on numbers and intervals (numbermerge) and country or region names (countrymerge) in link texts. These lists can be made for all language combinations. Just ask if you want to work on new combinations. As a new thing you can now move false positives (that is pairs of items which are suggested merged, but which are about different subjects) to an exclusion list. Then they will be removed from all merge lists after next update so they don't have to be checked again and again after each update. Items that are wrongly suggested spilt due to use of different numbers or countries in different links, can be moved an unmerge exclusion list to be removed from future updates.
  • All reports are listed on my userpage. They are currently placed as subpages to the user page, but I have decided to soon move all or most of them to the Wikidata namespace.

Byrial (talk) 09:02, 19 August 2013 (UTC)

Thanks for doing those again :) It might be time to move them out of your user namespace? I've talked to quite a few people who are looking for something like that but are unable to find