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/76.119.11.246

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

Hi,

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 http://www.wikidata.org/w/index.php?title=Q10784379&diff=0&oldid=51277312 for all changes since your last visit.

It's a mail for page http://www.wikidata.org/wiki/Q10784379, 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? 86.6.107.229 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) = 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).

• We could use 'Q11651459'.

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)

• We could use 'Wikimedia disambiguation page (Q4167410)'.

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)

• we could use 'Wikimedia disambiguation page (Q13416711)'.

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)

Problem with imported from Wikimedia project (P143)

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)

Source

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. 50.100.140.159 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. 50.100.140.159 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. 50.100.140.159 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"). -12.78.83.226 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)

vandalism

[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 http://wikidata-test-repo.wikimedia.de/wiki/Special:NewProperty 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. Del_♉sion23 (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. Del_♉sion23 (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. Del_♉sion23 (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. -- Lavallen^talk(block) 10:02, 8 August 2013 (UTC)

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)

Search: Niedersachsen

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. Del_♉sion23 (talk) 23:49, 7 August 2013 (UTC)

MediaWiki:Wikibase-error-sitelink-already-used. But what about translations? πr² (t • c) 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. Del_♉sion23 (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! Del_♉sion23 (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. -- Lavallen^talk(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? — ΛΧΣ²¹ 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. — ΛΧΣ²¹ 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)

• To find out what this discussion is about, I found http://blog.wikimedia.org/2013/02/07/echo-a-new-notification-system-for-wikipedia/ --  Docu  at 05:24, 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... -- Lavallen^talk(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.
Einzelheiten
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)

Wikidata Logo

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 — ΛΧΣ²¹ 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. --Revi^Discuss_{SUL 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.

BUT!

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. -- Lavallen^talk(block) 06:22, 11 August 2013 (UTC)

FYI, Alabama != Alberta. πr² (t • c) 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... -- Lavallen^talk(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! Del_♉sion23 (talk) 23:34, 11 August 2013 (UTC)

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

ENGLISH:
The Wikipedia articles

• English: Marine clay

and

• 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?

Detlef

DEUTSCH:
Die Wikipedia-Artikel

• deutsch: Klei

und

• 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?

Detlef

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

http://hu.wikipedia.org/wiki/Bogr%C3%A1cs

http://en.wikipedia.org/wiki/Cauldron — Preceding unsigned comment added by 195.212.29.191 (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)

Subitems

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)

http://toolserver.org/~holek/misc/no-interwiki.php 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)

JAnDbot

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 cs.wiki 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 cs.wiki 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 es.wiki article is about this concept in the labor laws in Spain whereas the one on fr.wiki 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)

merge.js

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)

Statements

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

http://toolserver.org/~magnus/ts2/php/wd_query.php?q=[%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)

• Thank you. AutomaticStrikeout 19:05, 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. Del_♉sion23 (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 Del_♉sion23 (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:

http://en.wikipedia.org/wiki/Wikipedia_talk:Requests_for_undeletion#of_wikidata_.26_undeletions...

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*

hello;

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:

http://www.wikidata.org/w/index.php?title=Q11605502&action=history

&

http://en.wikipedia.org/w/index.php?title=Paper_Rabbit_Rope&action=history

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 entity.claims.p569[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" (http://www.wikidata.org/wiki/Q3491508) but it's strongly connected to Blowpipe (tool) http://www.wikidata.org/wiki/Q1520198

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)

Perth

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. Del_♉sion23 (talk) 15:08, 19 August 2013 (UTC)

P107 (P107)

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! :) -- Lavallen^talk(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:50, 17 August 2013 (UTC)

+1 to your above hahc21. ·addshore· ^{talk to me!} 08:11, 18 August 2013 (UTC)

• There was some agreement that at least some people need to be informed Wikidata_talk:Properties_for_deletion#Inform_creator_and_people_that_participated_in_the_discussion. --Tobias1984 (talk) 12:38, 18 August 2013 (UTC)

Stop

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

• WD:Migrating away from GND main type
• Help:High-level classification

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 them. Let's move them to a more prominent place and give them very good non-techy descriptions so newcomers can find something to do? --Lydia Pintscher (WMDE) (talk) 09:36, 19 August 2013 (UTC)

Thanks Byrial. These are great. Filceolaire (talk) 10:30, 19 August 2013 (UTC)

Amazing, thanks a lot Byrial! Someday we will need a kind of mini participation tool to resolve these problems... GalaxyZoo did that and they got amazing results. Maybe it could be a project for next Gsoc?--Micru (talk) 19:45, 19 August 2013 (UTC)

If you want to enjoy with galaxies, there is a lot of duplicate item of the objects listed in the New General Catalogue (Q14534) ;-)

@ Byrial: is technically possible search duplicate items with names "NGC number" where number goes from 1 to 7841? Thanks for your work! --Paperoastro (talk) 14:30, 21 August 2013 (UTC)

which property for episodes?

Which property should be used to add episodes to e.g. a tv serie? The only appropriate I found is has part(s) (P527), but this isn't dedicated for episodes so the property can be used for other statements also, which would result in a list mixed of episodes and other stuff. --Nightwish62 (talk) 16:58, 20 August 2013 (UTC)

Which other part could have a series that could be confusing? Could you give an example?--Micru (talk) 17:08, 20 August 2013 (UTC)

Stop don't add episodes to the main item of the serie but link each episode to the main item of the serie. Snipre (talk) 17:52, 20 August 2013 (UTC)

Who said we should do so? --Nightwish62 (talk) 17:58, 20 August 2013 (UTC)

Should we make dedicated list-subitems for all and everything? Every serie get their own "episodes of %seriename%". Every location would get their own item 'mayors of %location%". Every band get their own item "album of %bandname%". Every sport event get their own "participant of %eventname%". This would lead us to millions of unnecessary 'subitems'. We can add this information direct to the main item itself, and so we should do. --Nightwish62 (talk) 18:09, 20 August 2013 (UTC)

By definition a serie is a sequence of episodes, so it's related to how we model sequences and express that a serie is a sequence of episodes (but at a higher level a serie is also a sequence of seasons, which are not episodes, that's why I proposed the subsequence of property. So I don't think we need a subitem. TomT0m (talk) 18:37, 20 August 2013 (UTC)

E.g. People or places. So the german label is "besteht aus" and I see no wrong when somebody make statements "The Simpsons has part (besteht aus): Homer Simpson, Bart Simpson, Lisa Simpson, Springfield, Shelbyville". All those stuff is part of the TV serie. --Nightwish62 (talk) 17:58, 20 August 2013 (UTC)

That would be characters (P674) and maybe we need one for places, something like "setting" or "takes place in".--Micru (talk) 18:09, 20 August 2013 (UTC)

WE have located in the administrative territorial entity (P131) and located in/on physical feature (P706) for locations and I am trying to get located in/on physical feature (P706) P766 (P766) broader so it van be used for anything located in a building. I don't think we need another property. all of these can be used with fictional places. Filceolaire (talk) 21:34, 20 August 2013 (UTC)

The problem with linking from the series item to the episodes is that the series item ends up with hundreds of statements and slows down. That's why it is better to link from the episode items to the season item and from the season item to the series item. "I think "part of" works for this with qualifiers "preceded by" and "succeeded by" to give the order. Thats my opinion. Filceolaire (talk) 21:34, 20 August 2013 (UTC)

part of the series (P179) works for this use, in fact. --Izno (talk) 21:47, 20 August 2013 (UTC)

I agree with Filceolaire, it makes no sense with Phase 3 coming in less than 6 months. There is no point in having an item with hundreds of episodes in it when the same info can be inferred from each episode having "episode of -> Show X". We end up with ridiculously long items like we currently have at United Nations. Surely we could infer that each country is a UN member by seeing that they have the statement "member of -> United Nations"? I don't know why we need to double it. Once phase three comes in, wouldn't we query <create list of Simpsons episodes> as <find items with statement "episode of = Simpsons">? That way we wouldn't need to host a list at the item for Simpsons, as we can generate the list automatically anyway. Del_♉sion23 (talk) 23:52, 20 August 2013 (UTC)

1. If many statements slows an item/query down, this must be solved. It can't be that there are any performance problem for just a few hundred statements. As far as I know, we're looking forward to store the population of e.g. a city, as soon as the data type 'number' is available. So if we have an annual demographics statistic for a specific city for the last 200 years, this could give us easy more than 1000 statements (year 1800: total inhabitant, percentage by gender, percentage by religion, percentage by age, percentage by citizenship, year 1801: ...). So I'm very surprised the most people here are concerned to have items with more than 100 statements.
2. Sure: Instead of add the episodes to the item, we could add the series to the episode. But there is no generic decision if we should make bottom-up or top-down or both direction statements. Or tell me the reason why there are a contains the administrative territorial entity (P150) top-down property, when it should only have and located in the administrative territorial entity (P131) bottom-up property.
3. About the suggestion to use part of the series (P179): This property is requested to be deleted.
4. Last but not least: I'm concerned that episodes-items could get deleted, when they are just linking to the series, but not vise-versa. Someone could take a look to the "what links here" of the episode, and since the list is empty it seems not notability. Sure it fulfills #3 of WD:N, but it isn't obvious as point of view from the episode item.

See, my problem is I would start creating episodes items. But the last two points (unsure property 'series' and it could be deleted without having another item which links to the episodes) I fear the episode item could get deleted. --Nightwish62 (talk) 10:20, 21 August 2013 (UTC)

Wikidata is all about using properties to describe atomic, individual objects and concepts and you don't get more atomic and describable than individual episodes of a TV show. I cannot imagine these being deleted from Wikidata at least not until after every Category, List and Disambiguation page has been deleted. Having the info on each episode on wikidata will however mean that the Wikipedias do not have to have articles on each of these. They can have a table for all the episodes in a season with all the fields filled in from Wikidata. I have just added "Individual episodes of TV shows" to Wikidata:Notability/Inclusion_criteria to confirm this. Filceolaire (talk) 12:21, 21 August 2013 (UTC)

Celsius

Wikidata Celsius (Q5479218) and Celsius (Q226181) should be merged.--Zweioeltanks (talk) 13:39, 21 August 2013 (UTC)

Added links. --Tobias1984 (talk) 13:48, 21 August 2013 (UTC)

Please add the request here: Wikidata:Requests_for_deletions --Tobias1984 (talk) 13:52, 21 August 2013 (UTC)

 Done Rippitippi (talk) 15:15, 21 August 2013 (UTC)

Merging pages

how to merge pages?

i found

http://pt.wikipedia.org/wiki/Eletroterapia (only portuguese)

and

http://en.wikipedia.org/wiki/Electrotherapy (this page have others languages)

I think that portuguese page must be merge to "Electrotherapy" page

I'm reading the help pages to understand how to do. I enabled the merge function but the function do not appears.. User:Japancase Talk 14:45, 21 August 2013 UTC

Please add the request here: Wikidata:Requests_for_deletions --Tobias1984 (talk) 13:53, 21 August 2013 (UTC)

Merge

Please take a look at this [19]. Merge is a fundamental guideline is that the whole community must take a final decision Rippitippi (talk) 14:01, 21 August 2013 (UTC)

item related Q-numbers

As there are some fiery ongoing discussion at moment (see above), time for some funny stuff. I notice there was some items which their item ID (the q-number) has a reference to the item itself. So far I found

• number of the beast (Q666)
• Stanley Kubrick (Q2001) (a reference to the movie '2001: A Space Odyssey')

Unfortunately Universe (Q1) wasn't Big Bang theory (Q323) which would be more suitable as for the begin of everything. However, I'm sure there a more funny Q-number related items. Did you know some? --Nightwish62 (talk) 22:29, 17 August 2013 (UTC)

Q42 is a good one for fans of Hitchhiker's Guide to the Galaxy. Also Q13 is not the kind of item a person suffering from it would visit. Del_♉sion23 (talk) 23:17, 17 August 2013 (UTC)

(edit conflict)I know a couple: Douglas Adams (Q42), Maya calendar (Q2012) and of course Wikidata (Q2013) :) --Micru (talk) 23:19, 17 August 2013 (UTC)

Q24 is also quite a good one. I also love how early this topic appears in our database (Q54). They missed one in not giving Q1984 to George Orwell :( Del_♉sion23 (talk) 23:22, 17 August 2013 (UTC)

It is far to be the only one (here as on the Web), but Q404... Louperivois (talk) 00:03, 18 August 2013 (UTC)

On the same IT concept I guess Q1337 should have a mention. Del_♉sion23 (talk) 00:34, 18 August 2013 (UTC)

I've started User:Delusion23/Wikidata:Humour to store this kind of thing. Feel free to add to it. If it grows into anything like [20] or [21], it could maybe be moved to main space. Del_♉sion23 (talk) 01:05, 18 August 2013 (UTC)

Haha, thank you guys. I didn't thought there was so much more. I love the HTTP 404 (Q404), even it appears it wasn't intended (the logs says: '(Duplicate of mathematics (Q395))'. Thanks Delusion23 for creating a fun-site. --Nightwish62 (talk) 08:04, 18 August 2013 (UTC)

Don't you see this?--GZWDer (talk) 06:50, 21 August 2013 (UTC)

I've moved the page to Wikidata:Humour. Hopefully it can be marked for translation and added to. It can be the Wikidata equivalent to the other sites on Wikipedia and Wikivoyage mentioned above. Del_♉sion23 (talk) 22:17, 21 August 2013 (UTC)

Central property change log

I propose having a central log where we record which changes we do to properties. I have changed catalog code (P528) has been extended and other properties will need to be adjusted to, but without having a central place to notify about this changes it will be hard to keep track.--Micru (talk) 18:13, 20 August 2013 (UTC)

•  Strong support --Nightwish62 (talk) 18:14, 20 August 2013 (UTC)
•  Support But I advocate as you know for reasoning at a higher level that properties: models, or types. The previous discussion about TV series is a good example of that : we reason in terms of episodes and series, not in terms of just properties. Changes in properties implies changes in models, and changing models might imply changes in properties, so those are linked. TomT0m (talk) 18:33, 20 August 2013 (UTC)
  • I agree with you, would it make sense to have a namespace "InstanceOf" that would list how the properties are normally used when the item belongs to that category? Maybe it would also help to find properties wrongly used or new uses that were not considered when creating them.--Micru (talk) 20:53, 20 August 2013 (UTC)
•  Comment I'll give some examples of 'changes of property usage'

• shares border with (P47)

• Initial: countries or administrative subdivisions, of equal level, that this item borders by land
• Now: countries or administrative subdivisions, of equal level, that this item borders, either by land or water

• place of burial (P119)

• Initial: place where subject is buried, ONLY if it is different from place of death
• Now: location of grave, resting place, place of ash-scattering, etc, (e.g. city or cemetery) for a person. There may be several places: e.g. re-burials, cenotaphs, parts of body buried separately. (no restriction it have to differ from the place of death)

• cast member (P161)

• Initial: (Label: Starring): actors as they are listed in the billing block of the poster for the film's original theatrical release
• Now: (Label: cast member): production's cast members, to distinguish starring or minor roles use qualifiers

So this was very significant changes to the usage/guideline of the properties. Users must be informed about this. Also the description has to change to all languages as soon as possible, so they didn't contradict each other. Therefore I support the proposal of Micru. Even more: I think we should have a central place about ongoing discussions of property changes, so everybody can take part. Otherwise it's possible just two people make a small discussion on the talk page of a property and then change the usage of it without a broad consent. --Nightwish62 (talk) 18:34, 20 August 2013 (UTC)

• Also, a place to discuss properties (and changes on them) would be good. Almost nobody watches the properties and so their talk pages. Wikidata:List of properties and Wikidata:Property proposal don't seem to be designated for this, plus they are split up in different languages. --YMS (talk) 18:36, 20 August 2013 (UTC)

 Comment I think this should be turned into an RfC. We really shouldn't make any changes any more based on votings in the English project chat. We have a "Property for Deletion" page, maybe a page "Change scope of property" would be a good proposal. --Tobias1984 (talk) 19:07, 20 August 2013 (UTC)

A central property change log is rather unrealistic. There is no way to ensure it is updated, plus there are multiple changes a day making such a log not manageable e.g. The edit war that occurs at P107 would be all over the log when not needed. Also really? Another RfC for a small thing like this is a no. If you want it create a log, feel free but there is no way to ensure it is updated even with community approval. John F. Lewis (talk) 22:47, 20 August 2013 (UTC)

What about using a possible template {{Property change request}} to be placed on the property discussion page and transclude the discussions in a central location?--Micru (talk) 23:26, 20 August 2013 (UTC)

Um, we already have a log of all edits done to properties. It's at http://www.wikidata.org/w/index.php?namespace=120&tagfilter=&translations=noaction&title=Special%3ARecentChanges. --Jakob (Scream about the things I've broken) 11:55, 21 August 2013 (UTC)

Recent Changes is probably best for this, but people can feel free to create a log of it all though. John F. Lewis (talk) 23:11, 21 August 2013 (UTC)

Proposal: rename "Properties for deletion" to "Properties discussion"

Since that page is not terribly active, I am thinking that we could use it also for "change of scope" requests. What do you think?--Micru (talk) 20:58, 20 August 2013 (UTC)

I think it makes sense to notify property discussions there but the announcement could be a link to the Property talk page where the discussion takes place - or the discussion could just be archived on the Property talk page. Filceolaire (talk) 21:39, 20 August 2013 (UTC)

Not really. Properties for deletion are for discussion of proposed deletion of properties. Property proposals is for the proposal of new properties. Irrelevant discussions based on single a property, should be at the property talk. Changing a deletion page to a general discussion page, means property proposals should also be merged there. So doing so is rather unrealistic. John F. Lewis (talk) 22:42, 20 August 2013 (UTC)

If the name is too general, it could be "Properties for change" which is more specific and leaves out the property creation page.--Micru (talk) 23:29, 20 August 2013 (UTC)

I still think 'Properties for deletion' is better for a page dedicated to deletion discussions. John F. Lewis (talk) 23:08, 21 August 2013 (UTC)

•  Oppose in favor of "Properties for discussion". Without the "for", it's not grammatical.--Jasper Deng (talk) 23:34, 21 August 2013 (UTC)

Q7745125

I think we can delete this item and replace it with novalue or somevalue. It isn't used in statements.

Or, another choice, can we use Q7745125 to show generic unknown value?--GZWDer (talk) 03:48, 22 August 2013 (UTC)

I agree, it seems like it should just be the builtin unknown value. Although see its latest request for deletion and the two threads about it in the sex or gender (P21) talk page. Seems like User:Ymblanter at least is for keeping it. Nemo157 (talk) 05:13, 22 August 2013 (UTC)

 Delete per Nemo157. --Ricordisamoa 14:14, 22 August 2013 (UTC)

Questions and comments on dates

Hi.

For properties with the date data type, how can this be handled for greek language?

For dates with precision on date, the month should be in genitive case. For example, 2013-08-22 should read "22 Αυγούστου 2013" (now it reads "22 Αύγουστος 2013")

For dates with precision on month, the date should be in nominative case ("Αύγουστος 2013")

When it will be possible to use date properties () in Wikipedias?

-geraki ^talk 10:27, 22 August 2013 (UTC)

For the parser function to work we need to close bugzilla:48937. I unfortunately can't say when that'll happen. Hopefully soon.

For the correct formatting we have bugzilla:48962. --Lydia Pintscher (WMDE) (talk) 15:47, 22 August 2013 (UTC)

Wikimania report

Heya folks :)

I just published my report from Wikimania. --Lydia Pintscher (WMDE) (talk) 15:41, 22 August 2013 (UTC)

HTTPS for users with an account

Greetings. Starting on August 21 (tomorrow), all users with an account will be using HTTPS to access Wikimedia sites. HTTPS brings better security and improves your privacy. More information is available at m:HTTPS.

If HTTPS causes problems for you, tell us on bugzilla, on IRC (in the #wikimedia-operations channel) or on meta. If you can't use the other methods, you can also send an e-mail to https@wikimedia.org.

Greg Grossmeier (via the Global message delivery system). 19:52, 20 August 2013 (UTC) (wrong page? You can fix it.)

Hi there. As I just updated on the meta page, we've delayed this rollout by one week. The change will now take place on August 28 at 1pm Pacific Time. Please take a look at gadgets or bots you maintain to make sure they'll continue to work; more information at meta. Sharihareswara (WMF) (talk) 19:41, 21 August 2013 (UTC)

The merge gadget does not request deletion of the empty page when we use secure logging; to use it we must keep logging 'old-style'. I could not find a matching entry in bugzilla. LaddΩ chat ;) 15:23, 23 August 2013 (UTC)

Delete

I need to delete this Q12219023 they themselves already this Q2474644 --Mohammedbas (talk) 06:02, 23 August 2013 (UTC)

I  Merged the two items. For future reference, see Help:Merge. The Anonymouse (talk) 06:17, 23 August 2013 (UTC)

Orchis anthropophora/Aceras anthropophorum : merges

Hello, Orchis anthropophora in english should be merged with Orchis anthropophora in french. Cordially. Christian COGNEAUX (talk) 09:03, 23 August 2013 (UTC)

Outsch! (time to collect and fix paper cuts)

Heya folks :)

We've come very far with Wikidata. So far we've concentrated on getting the basics up and running in terms of development. We've now reached a point where it's time to also look at some of the small annoyances and bugs that slipped through or that you didn't bother reporting because bigger things still need fixing. Those small things we realize though have a huge impact on how much fun it is to use Wikidata. We've therefor started a page to collect paper cuts. Paper cuts are small annoyances or bugs that are relatively easy to fix but have a large impact on how enjoyable it is to use the site. If you've come across something that fits this description please do report it at Wikidata:Paper cuts. If it's already in bugzilla please add "paper cut" to the whiteboard field there.

Cheers --Lydia Pintscher (WMDE) (talk) 16:50, 23 August 2013 (UTC)

URL datatype needs testing

Heya folks :)

The URL datatype is now available on test.wikidata.org. It'd be amazing if you could give it some testing. We hope to roll it out on Monday however there are a few things outside our hands that still need review. It might happen that we have to delay it because of that until the next deployment in 2 weeks. Either way some testing would be great and useful.

When testing please be aware that URLs are right now not checked against the spam blacklist and that there is an issue with too long URLs. This needs fixing before deployment here.

Cheers --Lydia Pintscher (WMDE) (talk) 17:20, 23 August 2013 (UTC)

I don't see an url datatype on Special:NewProperty... Ayack (talk) 18:13, 23 August 2013 (UTC)

Yeah I was just told. Apparently there is a missmatch between the page showing all available datatypes and that one. I filed a bug about it. As for enabling it for real: It seems Reedy still needs to flip a switch after all. I asked him to do that and hope he'll see my message soon and do it. --Lydia Pintscher (WMDE) (talk) 18:18, 23 August 2013 (UTC)

Ad Dakhiliyah

In my opinion pages Q14201307 and Q792550 should be unite. Thanks Lkcl it (talk) 16:22, 23 August 2013 (UTC)

I'm not so sure. The french and italian versions of the Wikivoyage pages in Q14201307 are about Q792550 for sure, but the english version describes 'Northern Oman', which is not exactly the same. Don't know how to deal with that, just sayin'. —Frank Geerlings (talk) 17:04, 23 August 2013 (UTC)

Ok, I have made a mistake. Is it possible to transfer on Q792550 only the french and italian versions of the Wikivoyage pages in Q14201307? Thanks --Lkcl it (talk) 17:46, 23 August 2013 (UTC)

 Done Del_♉sion23 (talk) 20:15, 23 August 2013 (UTC)

Thanks --Lkcl it (talk) 08:39, 24 August 2013 (UTC)

Add a deleting note to property label?

It's really a shame request for property deletion take that long to process. So I just got that idea we could add something like "(proposed to be delted)" at the end of the property name. This way we will a.) inform everybody who is using this property, so he can take part of the discussion b.) this will give some pressure to the discussion to be close faster, since we didn't like to have properties labeled that way. Please vote about this. --Nightwish62 (talk) 17:12, 24 August 2013 (UTC)

We need to use WD:RFC for this kind of thing, even if it's such a small thing. --Izno (talk) 17:43, 24 August 2013 (UTC)

You are more than welcome to open a new RFC process to get opinions over a topic, but that should be done after a long discussion via the other channels. --Nightwish62 (talk) 17:59, 24 August 2013 (UTC)

•  Support some type of notification. Maybe not in label, but on property talk page. Note: label is multilingual. Note 2: property can be deleted not throw "Property deletion" process. — Ivan A. Krestinin (talk) 17:50, 24 August 2013 (UTC)
• I think that something like this should be done, and when a property is proposed for deletion, then after the property name should come automatically some text like [deletion review]. --Stryn (talk) 18:01, 24 August 2013 (UTC)

  I agree with Stryn, sounds like a good solution (if the devs can do it!) Ajraddatz (Talk) 00:41, 25 August 2013 (UTC)

Property proposals associated with Wikiproject items

We have Wikiprojects as items on wiki data. Right now there are hardly any property regarding Wiki project items. Should we have properties related to Wiki projects? Before posting at Property Proposal I would like to hear community. Some property ideas:

• Parent Wikiproject/Daughter Wikiproject ( like Wiki project Sports is parent of Wiki project Tennis, vise versa)
• Related Wiki project ( every article/items/templates have related wiki projects, some categories are also related to wiki projects) It can be helpful in future by connecting items to wiki projects as in future we would be able to derive affiliated projects similar to inter wiki links from wiki data and even they are connected to other language by wiki data!)
• Related Portal ( many wiki projects have related portal and we have portal items too..)
• Any more ideas?

What you say? -Nizil Shah (talk) 19:03, 24 August 2013 (UTC)

Moved articles

The fact that Wikidata links are not corrected immediately when any Wikipedia article is moved but afterwards is a big systemic defect of Wikidata. Interwiki links should never disappear when a page is moved. However, after moving an article at en: or de: Wikipedia, User:Krdbot corrected the links in 1 or 2 minutes. After moving an article at cs: Wikipedia, BetaBot correct the link usually after 1 or 2 hours, which is unacceptably late. Links to pl: Wikipedia are also very delayed. --ŠJů (talk) 19:33, 24 August 2013 (UTC)

Oh, it seems to be solved expressly! The link was corrected automatically now! Thank You! --ŠJů (talk) 20:43, 24 August 2013 (UTC)

You should also to consider the resources of the server where the bot runs and the bandwidth for contact the 260+ Wikipedias. --β₁₆ - (talk) 23:46, 24 August 2013 (UTC)

That was anticipated to be considered before phase I of Wikidata. Disappearance of interwikis, commonscat link and potentially also all data from infoboxes in the article is absolutely unacceptable even for one minute. One or two hours delay is fatal failure. --ŠJů (talk) 20:20, 25 August 2013 (UTC)

Dutch translation for Theater (warfare)

The dutch translation should be slagveld. There is a dutch lemma with this name, but when I try to add this dutch translation, I get an error-message. ChristiaanPR (talk) 22:27, 24 August 2013 (UTC)

I added slagveld to theater of war (Q718893). The link was stored in another item that had only that link. --Tobias1984 (talk) 22:33, 24 August 2013 (UTC)

Best place/method to update an item of data (incorrect date of birth/date of death)

Wikidata had one source (enWP) for the death date of Ástor Piazzolla (Q172505), which it gave as 4 July 1992. I checked a half dozen other languages and they repeat the same date, but never with a source reference. According to contemporary newspaper articles [22][23], and to the leading music reference source [24], he died on the 5th not the 4th.

I've edited the wikidata item, and used the 'Imported from' property to identify the source as the "Los Angeles Times" (which was offered in the autocompletion). I wasn't given an opportunity to give a specific page reference/ link which obviously greatly reduces any verifiability. How should I have made this correction to maintain the same level of verifiability as in a wikipedia? And how are differences between wikidata and wikipedia, (and between wikipedia and wikipedia) flagged up to encourage consistency? Do I just manually check all 49 languages with a Piazzolla article and correct any that are wrong? Is there a better way? Scarabocchio (talk) 21:01, 15 August 2013 (UTC)

On Help:Sources you have the description of how to source statements. The webpage property is due this month, so as soon as it is available you will be able to include links to web pages too.--Micru (talk) 22:05, 15 August 2013 (UTC)

• Each wikipedia can use wikidata values (for example in infoboxes). In this case it will be automatically updated after change in Wikidata. Infovarius (talk) 06:29, 16 August 2013 (UTC)

I have edited Astor Piazzolla (Q172505) to add 2 of those references: Note that:

• I used 'stated in' for a newspaper link, as the guidelines. 'Imported from' is generally only used to signify that stuff has been copied from Wikipedia and not properly sourced.
• You have to save after adding the 'stated in' property and then go back and click 'edit' for that source to see the add button which lets you add the 'date of publication' and 'title' qualifiers to a source.
• 'Title' should show the headline of the article.

Hope this helps. Want to try adding that third reference? Filceolaire (talk) 18:50, 16 August 2013 (UTC)

Many thanks, all, for the tips and pointers! I'll add that third reference shortly (I've found a Spanish language source over the name of Piazzolla's last wife that gives the DoD as the 4th so I'm just investigating that). Two more questions:

• Am I right in thinking that there will be no imports from any Wikipedia that will overwrite an *existing* data field in Wikidata (ie that the 'master' copy of the data field contents is now considered to be the Wikidata one)?
• I can see that there are potential problems with automatically updated infobox contents failing to match the data in the associated article. Are there any tools for highlighting differences between Wikidata and Wikipedia articles?

Thanks, Scarabocchio (talk) 09:24, 17 August 2013 (UTC)

I think this could gain from additional feedback. --  Docu  at 03:08, 25 August 2013 (UTC)

Add easy multiple recurring statements

I just finished to add all episodes of the Stromberg TV serie. In detail, I created 46 new items and added 46 times the same statements (instance of:episode, series:stromberg, original language:German, original network: Pro7). It's quite boring to add the same statements again and again. So, this morning, I visited the Tool-Page to check if there is any Tool which can help add multiple recurring statements. I found this nice tool here. After some attempt on the Wikidata sandbox, I think I figured out how to handle the tool: I can add multiple p-values and multiple q-values. Whenever one p and one q value is checked, it will add the statement. That's really cool and I wished I had been aware of this tool before I started enter the TV episodes.

However, it's still not that what I was looking for: A tool which you can also predefine multiple p- and q- values and then adding with a single click at a stroke. Also there is no support for qualifiers, which would be helpful.

Is someone else interested to so a tool also? Is someone here who is able to code it? --Nightwish62 (talk) 08:08, 25 August 2013 (UTC)

I haven't tried it, but isn't that about what Wikidata:Tools/Array properties gadget (available in the gadget section of the preferences as Properties tool) is doing? --YMS (talk) 08:38, 25 August 2013 (UTC)

That tool sends the requests here: User_talk:Legobot/properties.js/requests. It looks like there are enough request there to keep somebody busy for a couple of months. --Tobias1984 (talk) 08:46, 25 August 2013 (UTC)

David Alarza

David Alarza (Q5799773) and David Alarza (Q5230670) are duplicate (same guy)

 Done --Tobias1984 (talk) 08:32, 25 August 2013 (UTC)

Quote from the English entry: "Alarza is a fan of the mountains of Spain and enjoys mountain biking." One of the true gems of Wikipedia prose. --Tobias1984 (talk) 08:36, 25 August 2013 (UTC)

Suggestion to merge and link articles - Kanelbulle / Zimtschnecke / Cinnamon Roll

Looking up Cinnamon roll I was surprised to see that the only other language with an article on the subject was in German. Especially since I knew the Danish article for this very thing existed and the German article linked to various other languages. Looking into the matter I can see that there's two German articles on the subject - one on the overall term Zimtschnecke which would translate into the other languages like the Norwegian Kanelbolle and the English Cinnamon Roll and an additional on the special type of Zimtsnecke, the Swedish Kanelbulle(German article).

I would suggest that Zimtschnecke and Kanelbulle gets merged, Kanelbulle deleted and following articles gets linked; Zimtschnecke, Kanelsnegl, Fəsəli, Kanelbulle (Boarisch), Rollo de canela, Korvapuusti, Kanelbulle (Français), Kanelbulle (Italiano), シナモンロール, 시나몬 롤, Fesalî (kilor), Kanelbolle, Skillingsbolle, Kanelbulle (Português), Плюшка, Kanelbulle (Svenska), ซินนามอนโรล Cinnamon roll.

I would do this myself, but this some of my first work here, I've never tried to merge or delete articles before, so I'm afraid of messing something up.  – The preceding unsigned comment was added by 84.238.81.70 (talk • contribs) at 11:25, 25 August 2013‎ (UTC).

We can not decide on merging of WikiPedia articles on WikiData, you would have to take the discussion to the German WikiPedia. --Sixsi6ma (talk) 10:03, 25 August 2013 (UTC)

and Wikidata cannot have links to two wikipedia pages in the same language on the same wikidata page so we have to have two wikidata pages - each with a link to one of the German wikipedia pages you found.

Go ahead and try fixing these two pages - It will be a good place to start learning how wikidata works. Remember it's a wiki and things can be undone.

Start by enabling the 'Move' gadget in your preferences. This will add 'move' to the menu that appears when you click on a sitelink.

Use this to move the sitelinks one by one till you have the right links on each of the two wikidata pages (This might mean one of the German pages is on a wikidata page by itself).

Good luck. Filceolaire (talk) 13:11, 26 August 2013 (UTC)

You may want to list this at WD:IC. --20.132.68.148 16:05, 26 August 2013 (UTC)

Wikidata doesn't automatically update when move a page?

Tianyamm2 moved zh:Dois Irmãos to zh:两兄弟镇 (巴西) and I moved it to zh:两兄弟镇. However, Wikidata item Q783009 doesn't automatically update.--GZWDer (talk) 11:36, 25 August 2013 (UTC)

The problem over here was probably that the second move happened to soon after the first one. As the item updates on Wikidata are executed via the (asynchronous) job queue it can happen that updating an item takes a few minutes. If a second move happens before the item can get updated both moves wont be replicated to Wikidata for technical reasons (I can further explain this, if desired). - Hoo man (talk) 11:57, 25 August 2013 (UTC)

Property proposal/References

Most properties on this page seem ready for creation: sufficiently explained, documented, with samples, most participants agree with the creation. Maybe a bit too boring for most users, but I can't think of too many reasons why not to create them. Obviously, they would all gain from additional feedback from other users.

There are three exceptions to what I just wrote: the property "based on heuristics", the XPath one, and the last one ("position in page or document" that is just too recent).

Anyways, I think it would help if a property creator or an administrator with sufficient experience in using/creating/updating properties would go through the list. --  Docu  at 12:43, 25 August 2013 (UTC) (edited)

Translatability of edit warnings needed

I don't know is it possible to be done by project admins, but the problem is that words under edit window from "Your changes will be visible immediately." to "this does not include the vast majority of web pages or images." are not translatable, while obviously should be. Ignatus (talk) 18:06, 25 August 2013 (UTC)

Those texts are included at MediaWiki:Edittools. --Stryn (talk) 18:35, 25 August 2013 (UTC)

De-adminship policy due to inactivity

Hello. It's almost five month from the latest confirmation (six months for the second-latest one) of administrators, so I think it's time to discuss and establish the inactivity review system and its method. Personally, I think we have a choice to refer to the methods in commons (now running) or meta (example). Your opinions are appreciated. Best regards. — Kwj2772 (talk) 06:35, 26 August 2013 (UTC)

Wikidata:Requests_for_comment/Defining_inactivity --Tobias1984 (talk) 06:37, 26 August 2013 (UTC)

Thanks. then it can be closed now :) Kwj2772 (talk) 06:53, 26 August 2013 (UTC)

It was closed last month and the policy has been added to WD:A. We've already lost one admin to inactivity since then. The next check for inactivity is on 1 September. You can follow the stats used at [[25]]. Del_♉sion23 (talk) 11:07, 26 August 2013 (UTC)

Link impossible to create to the Portuguese page : http://pt.wikipedia.org/wiki/SATA_Internacional

We need to add the Portuguese page as link to this English page. Indeed, we can't find the Portuguese translation.

So I tried to create the link with http://pt.wikipedia.org/wiki/SATA_Internacional but it was impossible. I got the following error: "Site link SATA Air Açores is already used by item Q1243903. Perhaps the items should be merged and one of them deleted? Feel free to ask at Project chat if you are unsure."

In other hand is it possible to create the Portuguese link to: http://pt.wikipedia.org/wiki/SATA_Internacional#SATA_Internacional

Thank you for your feedback, Claudio

Hi Claudio, I'm afraid it is impossible to add a link to that as it is not an article on its own, it is a section of an article. Wikidata does not yet have the functionality to add links to sections. However, it can be done the old way by adding a link to the bottom of the English article, like so. Hope this helps. Del_♉sion23 (talk) 11:01, 26 August 2013 (UTC)

Script needed for symmetric properties

Is there any script to replicate all symmetric properties of an item like shares border with (P47)? It would save me a lot of time! :) --Micru (talk) 15:21, 26 August 2013 (UTC)

Wiki Data Scraping

Hello Support,

I am a developer and need your help.I am working on a project in which Wiki content need to show on our project.I have used Wiki API (http://en.wikipedia.org/w/api.php) for retrieve contents.Its working fine but there is some issues with images.

I want to know is there any specific WSDL/Library in which Wiki content (search keyword base)return with XML format like description in single tag with images.

For the reference, I am using this link : http://en.wikipedia.org/w/api.php?action=query&prop=extracts&titles=elephant&format=jsonfm and its returns whole search contents without images. I want to know how we retrieve images with whole content.

In shortcut please let me know how to retrieve WikiContent with image and other text in single step.

Thanks, Karamveer Singh User:Karamveer

Try http://en.wikipedia.org/w/api.php?action=query&prop=extracts|images&titles=elephant&format=jsonfm and note the images in prop. Jeblad (talk) 04:38, 27 August 2013 (UTC)

Database property

As part of a discussion on Property proposals the following has been suggested:

1. Create a new "Catalog" property to link to items for databases and catalogs which have an entry for the current item.
2. Use the catalog code (P528) property as a qualifier to 'Catalog' to give the reference number in that catalog for the current item.
3. Use the proposed URL Formatter property on the item for the Catalog or database to specify how the 'catalog code' can be converted into a url.
4. Create a gadget which automatically converts the catalog code into a hyperlink, using the info in the URL property formatter.
5. Replace all of the Authority control and database properties with the new 'Catalog' property, with the catalog code (P528) qualifier.

Before I draft an RFC for this I wanted to do a sanity check here. Does this sound like it might work? Is there some obvious mistake I have missed? Filceolaire (talk) 12:00, 21 August 2013 (UTC)

I think that the most important issue is, that we would first need to find a new way to handle constraint violations. I would still prefer "catalog code" to be one level higher than the individual identifiers. Then all the individual identifiers would get a statement "subclass of = catalog code". I think adding statements to properties would generally be a neat idea. All the time properties could be a "subclass of = temporal relationship". --Tobias1984 (talk) 12:22, 21 August 2013 (UTC)

I prefer the new property as qualifier of catalog code (P528), but my opinion concerns especially astronomical catalogues that are collected together in big databases. In general, imho, it is not important the order, but the possibility to use constraint violations. At now "unique value" works well, and it would be useful to continue to use it with the combination of two properties ("principal" and "qualifier"). Therefore it would be nice verify if this combination could allow to use "format constraint" that would be very useful. --Paperoastro (talk) 14:09, 21 August 2013 (UTC)

Constraints would be expressed something like this

• Domain constraint
  • 'catalog' property with 'star catalog item' value can only be used on items which are instance of (P31) or subclass of (P279) of 'astronomical item'
  • 'catalog' property with 'musicbrainz performer catalog item' value can only be used on items which are instance of (P31) or subclass of (P279) of 'performer'.

It might be possible to add a property constraint template to the catalog items stating the class of items included in that catalog. The bots checking constraints could then use the info in this property.

• Value constraints
  • can only be used to link to items which are instance of (P31) or subclass of (P279) of database (Q8513) or 'catalog' item.

I'm not sure what you mean by an 'individual identifier'. Can you give me an example? Adding statements (or maybe just categories) to properties could be neat but is not needed to implement this proposal. Filceolaire (talk) 17:17, 21 August 2013 (UTC)

Usually a catalogue has a unique element for one "real object". Unfortunately, for various reasons, in the New General Catalogue, some real objects have more than one element (see for example Q31264 that corresponds in the catalogue to the elements "NGC 6" and NGC 20")! Some Wikipedias have articles for every element of the catalogue, included the duplicated ones! So in many cases we have two (or more) items for the same object. Using other catalogues and the constraint unique value, we can found them and remove the duplicate informations (see the second column of this table). --Paperoastro (talk) 13:49, 25 August 2013 (UTC)

• I think we must use lex parsimoniae principle. Can the data be described without qualifiers? - if yes then qualifiers are not needed. General property+qualifier scheme is more complex construction than concrete property. This complexity will extend complexity of every property processing algorithm. For example suggested constraint check algorithm is more complex that existing. What benefits have general property+qualifier scheme? Avoid property creation process - maybe more correct way: make this process more friendly? Reduce number of properties - we have no any limits to property count. — Ivan A. Krestinin (talk) 16:14, 23 August 2013 (UTC)

For me the lex parsimoniae says it is better to use one property with one qualifier and a thousand existing catalog items instead of a thousand new properties. Filceolaire (talk) 00:51, 24 August 2013 (UTC)

Seems like this is just another round of reimplementing "sameAs" in yet another way. The identifier have a context (or scope) where it is valid and that must either be identified through the property, through a qualifier or by using a proper URI as an identifier. Jeblad (talk) 04:50, 27 August 2013 (UTC)

al items up Q10000 have labels and descriptions in french !

Just a few million to go to fill everything :)

Are you aware of other relevant stat pages ?

Yay! Ajraddatz (Talk) 23:38, 26 August 2013 (UTC)

Indexing issue?

Typing male in the search field does not list male (Q6581097) as the first item, despite that I added&suppressed an alias to it to force its reindexing. Bug or feature? LaddΩ chat ;) 15:38, 26 August 2013 (UTC)

Explained by Wikidata:Project chat/Archive/2013/07#Wikivoyage is here and new features/bugfixes: male (Q6581097) has no sitelink at all...

It was created following Wikidata:Project chat/Archive/2013/03#Statement p21 (sex) should not use q43445 (female) as value; does anyone know some site links that could be added to that item? LaddΩ chat ;) 15:52, 26 August 2013 (UTC)

The sorting of search results is a known problem, look in the FAQ for more information on that.

q6581097 was intended to stay without links, it is only used as value for P:p21 because it is gramaticaly wrong to say Sex: Man.

q43445 is a total mess, it seems that it was inteded to be only used for female animal and is used for female in general in some languages, it needs to be sorted out. --Sixsi6ma (talk) 23:01, 26 August 2013 (UTC)

Property for authorative source

In some cases a reference for a statement might point to a source, and the user uploading the statement is also an employee at the organization, and further updates might also be expected for this statement and from this organization. The situation will for example emerge if we automate value extraction from Europeana. We just don't want to do this manually, we want to automate extraction of the values from the feed and insert them into the correct items and statements. Still we do want to make the process visible and transparent. Europeana aggregates metadata from several sources, but who do we list as our source? There are data providers, content providers, national aggregators and on top Europeana. I wonder if we have some kind of "authoritative source" for the specific curated dataset we are using, and then we should identify that one as our referenced source. In addition we should add an qualifier that says this dataset is part of a larger dataset, for example Europeana. If this dataset is then uploaded by the same organization, how do we expose that? Or is it more important to make mechanisms to verify that the value conforms to the reference, that is authoritative source? Jeblad (talk) 22:48, 26 August 2013 (UTC)

You can specify more than one source for an statement, for instance you can use P727 (P727) and Bibliothèque nationale de France ID (P268) and (soon) rank them by preference. Do you think that should be enough? --Micru (talk) 23:47, 26 August 2013 (UTC)

It is one solution that sort of identify a set of metadata about an entity, but it is not really the source but rather later identifiers used by Europeana and national aggregator instead of a proper "sameAs". The real source is the data and content providers, but at that level we don't see the identifiers used at higher levels (but it can although be generated). The dataset provided by Europeana is at least both curated and aggregated one time and possibly several times. Jeblad (talk) 04:27, 27 August 2013 (UTC)

English article on Boring links to German article Brunnenbau (drilling a well)

I wanted to change the link, so that it would go to the German article on Bohren, but the English article Drilling already links to there, so the system wouldn't let me do it just like that, and I don't know what to do now. Could someone please do this?

The German term Bohren covers the English terms Drilling and Boring, so in my mind it is OK that both English articles link to this one German article.  – The preceding unsigned comment was added by 194.25.102.189 (talk • contribs) at 08:54, 26 August 2013 (UTC).

It is not possible and not intended to link more than one article of one language in a single item on Wikidata. --Sixsi6ma (talk) 09:13, 26 August 2013 (UTC)

It seems reasonable to connect de:Brunnenbau with en:Well drilling and de:Bohrung (Geologie) with en:Boring (earth). I've done that, see items Q14693887 Q3210331 Q12177444. If you think this needs further attention, report the problem at WD:IWC. Mind you, we connect articles by their content (topic), not by their name! Littledogboy (talk) 12:26, 27 August 2013 (UTC)

Changed link to...

Seems to me that with the new build, "Changed link to [lang]" is displayed in history/watchlist when in fact a link has been added. Littledogboy (talk) 12:00, 27 August 2013 (UTC)

I saw this kind of summaries and edits yesterday, but haven't seen today. Do you have some diffs from today? --Stryn (talk) 12:05, 27 August 2013 (UTC)

Can't see any today, but even edits from months ago are now marked like this. Littledogboy (talk) 12:39, 27 August 2013 (UTC)

GeoCoordinates in diff

Tracked in Bugzilla
Bug 52501

Somehow the diff cannot be seen. It says: "PHP fatal error in /usr/local/apache/common-local/php-1.22wmf13/extensions/Wikibase/lib/includes/ClaimDifferenceVisualizer.php line 401: Object of class DataValues\GeoCoordinateValue could not be converted to string" Infovarius (talk) 20:29, 23 August 2013 (UTC)

I am looking into this bug. Thanks for reporting it. Aude (talk) 08:07, 28 August 2013 (UTC)

Hide source box for properties that don't need sources

There are, I think, certain properties that don't use sources (internal Wikimedia stuff, main types, some identifiers), and thus have no need for the source box ("0 sources, [add source]"). Would it make sense to hide the box with CSS? We could probably save quite a bit of space like that. --Yair rand (talk) 05:27, 27 August 2013 (UTC)

Good idea! Copy it here: Wikidata:Paper cuts --Micru (talk) 12:37, 27 August 2013 (UTC)

Main types... don't need sourcing? What world are you living in? o_o --Izno (talk) 23:52, 27 August 2013 (UTC)

Maybe not the best example, but I still think it is useful for common sense knowledge, or when the item is a source itself.--Micru (talk) 01:28, 28 August 2013 (UTC)

By "main types" I meant things like P:P107. How could that be sourced? --Yair rand (talk) 03:13, 28 August 2013 (UTC)

Presumably a reference to its webpage at the GND project. (Duh.) (This is one of the reasons why the property is being deleted—the property duplicates the information available where it can be sourced, and is un-sourceable otherwise.) --Izno (talk) 15:56, 28 August 2013 (UTC)

French translation for Urban area

In my opinion fr:Aire urbaine is a better translation for en:Urban area then fr:Région urbaine as it is translated now. I am dutch myself. ChristiaanPR (talk) 08:19, 27 August 2013 (UTC)

Addressed on Christiaan's talk page - LaddΩ chat ;) 21:30, 27 August 2013 (UTC)

Actual use of Wikidata data in wikipedias

Is there any page to track the actual use of data in wikipedias or other wikimedia projects? While planning how to use coordinates from wikidata in coord templates in Catalan Wikipedia, I searched for examples in other wikipedias and I didn't found anything. In fact, the only instances I could find of a Wikipedia showing Wikidata data were in template Commonscat in ca-wiki (en-wiki and de-wiki use Wikidata to check their Commonscat parameters but don't show Wikidata ones) and in infoboxes and stubs in oc-wiki (but I dare say there is a big misuse in oc-wiki).

Are there other good example of use of Wikidata in wikipedias? (beyond interwikis, I mean).--Pere prlpz (talk) 21:48, 27 August 2013 (UTC)

Special:WhatLinksHere/Template:ExternalUse lists some of the properties used on Wikipedia. --  Docu  at 21:53, 27 August 2013 (UTC)

Nice. Thank you.--Pere prlpz (talk) 22:17, 27 August 2013 (UTC)

Note that Template:ExternalUse is maitained manually, so actual usage is even higher. From my home wiki i can recommend "ultrawikidated" template cs:Šablona:Infobox rabín (and there is also relevant entry on papercuts). --Jklamo (talk) 13:08, 28 August 2013 (UTC)

Disorder with interwiki links in Wikipedia

I was pointed out at my Talk Page in the English Wikipedia that en:Wikipedia:Featured picture candidates is seemingly interconnected with ru:Категория:Орган. There is no Russian link in the body of the page (= nothing to overwrite), and the Wikidata item, Q3925302, is in order. Does anyone know how can this happen and how it could be fixed?--Ymblanter (talk) 05:32, 28 August 2013 (UTC)

I think it could be in any of the numerous transcluded pages. --  Docu  at 05:39, 28 August 2013 (UTC)

It's coming from en:Wikipedia:Featured picture candidates/File:Alabama Theatre Wurlitzer Organ.jpg, which is transcluded in that page. I'm not sure why, though, but I'm currently checking... The Anonymouse (talk) 05:40, 28 August 2013 (UTC)

Wow... turns out it was incorrectly transcluding a category.[26] The issue should now be fixed. The Anonymouse (talk) 05:45, 28 August 2013 (UTC)

It is now fixed, thanks a lot to both of you.--Ymblanter (talk) 07:00, 28 August 2013 (UTC)

Accessing interwiki data

For properties we can access the data from Wikivoyage by using, for example, {{#property:P373}}. Is there a similar way to access the data from the lists of interwikis? For example, if I wanted to automatically display the name of the corresponding WP article in Portuguese? Texugo (talk) 15:48, 28 August 2013 (UTC)

First, you need a Lua module to parse data from mw.wikibase.getEntity() (see mw:Extension:Wikibase Client/Lua for official documentation). You can import it:wikivoyage:Modulo:Wikibase; see its sitelink function: it returns the sitelink by DBname (or an empty string, if that sitelink is not present).
Then, you have to call it from a page or a template: assuming that you have imported it:voy:Modulo:Wikibase into pt:voy:Módulo:Wikibase, you can use {{#invoke:Wikibase|sitelink|dbname=ptwiki}} to get the sitelink title for Portuguese Wikipedia. But remember that (at the moment) you can only get the item linked to the current page. --Ricordisamoa 16:31, 28 August 2013 (UTC)

Perfect, thank you so much! Texugo (talk) 17:45, 28 August 2013 (UTC)

Sourcing requirements for bots - dates of birth and death

User:Legoktm has just closed Wikidata:Requests for comment/References and sources with the summary "All proposals were overwhelmingly rejected" and followed this up by marking Wikidata:Requests for permissions/Bot/SamoaBot 26 "approved. This bot imports birth dates and death dates from Wikipedia without importing sources.

If all proposals are rejected then that includes the proposal that bots can import data without sources surely. Or did I miss something?

For me birth and death dates are not common knowledge and need a source so I would oppose the approval of this bot, as many others have. Am I just being awkward? Are folks here happy to approve this bot? Filceolaire (talk) 12:12, 23 August 2013 (UTC)

The datas are already on pedias, if it's not sourced everybody will see that it is not sourced. So I say we take these imports as an opportunity to check consistency of datas in pedias, and we develop tools based on Wikidata to fact check and source the imported datas, as we took the item creation as an opportunity to clean the interwikis, the double item and so on. Take this as an opportunity, not a barrier that will most likely result in absolutely no changes into the quality of datas in pedias. TomT0m (talk) 12:37, 23 August 2013 (UTC)

Here the problem is now to know which pedia to use to "source" data imports. Does any bot a check if a source exists and if the source can be extracted ? If data are extracted from infoboxes we have to select first pedias which integrate directly sources in the infoboxes using the reference template and try to extract source data at the same time.

My problem with the current data imports is that bots are working without any big efforts to import sources while there is no urge to fill wikidata with data. Who is using Wikidata data right now ? Which Wikipedia decided to use in large extent data from wikidata ?

We have the time so better use this time to import data with sources when it's possible and only if not use the "import from" property as last solution. Snipre (talk) 13:18, 23 August 2013 (UTC)

We got a bootstrap problem. How is Wikidata useful if there is no data in it ? No imports means no data means no effort to improve the quality of data and continue as before. As I said, it's an opportunity to select the better datas, but first we got to motive people to do the effort of confronting the datas of different Pedias. We will motivate people to import sources of pedias on Wikidata if they have a better information than those who is currently on Wikidata. If there is no info on Wikidata, we cannot confront the different pedias to find the better one(s). We need a starting point, and tools to make the quality better. We're not losing anything, we just speed up and bootsrap the process thanks to what doors Wikidata opens. TomT0m (talk) 13:27, 23 August 2013 (UTC)

False: no bot imports don't mean no data. Then why do you need to confront data from different pedias ? If you have a source there is no need to confront data. Ok perhaps somebody did an error by typing the data but if you have the source of the data you don't have to do these checking/selection steps. By using wikipedia as data source you have to do the work twice: 1) data import and 2) data selection/confrontation. If you have directly external sources there is only the import work to do. Just an example. One guy came on the french project chat asking how to import census hungrarian data from the french wikipedia. Ok, nice, but as we looked at the data we see that the data were imported from the official website last year by a bot. Why do we have to import data from WP with possible errors (modifications, bad import) while we can do the job directly from the official website ?

"We need a starting point". Who needs that ? For each use (and by use I mean which current use) ? Each time somebody comes and asks how he can use wikidata in Wp the problems come from the tools and not from the data lack: not lua code to handle wikidata especially for infoboxes, missing datatypes, missing properties, no possibility to call different items for a wikipedia article,... We are not ready for the use of data so they is no urgent need for data: we will need massive imports of data once wikipedia will use in a large extend Wikidata. Wikipedia users are not waiting on data from wikidata, they want to know how they can use data from Wikidata in articles. How many infoboxes can handle data from wikidata ? Is there an template able to create a reference from wikidata ? You can have plenty of data, without these tools few persons will use your data. Snipre (talk) 14:50, 23 August 2013 (UTC)

I don't see how the lack of tools at the moment is opposed to my point. But there is already a lot of datas, and whatever you can think, most of them are good in pedias. We better import them in Wikidata to see where there is conflicting datas, with tools to point ton inconsistencies with other pedias to clean up the datas than starting from zero. Pedias will start to see Wikidata with a positive feeling when they see that when they start a new article the infobox is automagically filled and when the other will be completed, and when we could have report pages which shows inconsistencies a good work is a work not to be done. Because due to the volume, datas will nether be perfect. Just adding a source is better than adding the info and a source, we are humans, not robots, and humans code bots, keep user some slack and let them enjoy of the tools. TomT0m (talk) 23:01, 23 August 2013 (UTC)

T0m Tom; there are databases which contain birth dates and which are considered reliable. We can import some of these dates from there.

We have also agreed that there is a lot of information which can be imported without sources - just not this information.

If you find birth dates in wikipedia are consistent then that does not prove they are right - they might have copied each other.

When users start a new article and half of the infobox is automatically filled in then that will give them a motive to add the missing info. If they have no source for the info then that will remind them that a source is needed and they should leave that item blank till they have a source.

We are humans and therefore, like all humans, lazy. The bots are not humans and they may not do some of the things that humans are allowed to do. Filceolaire (talk) 00:36, 24 August 2013 (UTC)

@TomT0m I never say that wikipedia data are bad quality but if there is 1% of errors in WP data, people will say that the Wikidata is bad because ot this 1%. here we speaking about reputation of the DB. Right now there are different policies between pedias especially about sourcing and by mixing data from different pedias you decrease the quality of wikidata to the lowest level. So for pedias with high expectations about data quality wikidata becomes a mess and they won't use it because they can trust the data. If at the end they have to find themselves a source to confirm the data they just will say that wikidata is not an help for them: not a positive feeling at all. If you really want to know what wikipedians want just go the the project chats of the different pedias and ask them want they want. I already know it from a small request done by Lydia at the begining of 2013 in the different pedias and one of the main points was the reliability of data and this can be fulfilled only through correct sourcing

Wikipedians don't need wikidata so to have an interest to use wikidata they have to find something new or an improvement. If you just say "I offer you what you already have" they won't be interested, they won't change their habits. 178.237.94.235 10:22, 24 August 2013 (UTC)

I think it is worth mentioning that the import of birth dates by SamoaBot26 had 9 supports and 5 opposes, and the RfC didn't yield any conclusive result on how to regulate these data imports other than go through the standard bot approval process and specify where the data is coming from. --Micru (talk) 15:06, 23 August 2013 (UTC) We can throw loads of data onto Wikdata, but who is going to use our data if it's all unverified and not properly sourced? Del_♉sion23 (talk) 20:22, 23 August 2013 (UTC)

No, pedias will be able to select the quality of the datas they want to use, this as been stated quite a few times already through ranking, and programming in Lua in just a few lines of codes for the whole Wiki, with a fine grained filter. It's an opportunity to improve the overall quality of datas which are already in all pedias with a strict respect of the quality requirements of local pedias. It's an opportunity to clean the 1% mistakes by getting tools to better spot them (Byrial seems to have plenty of ideas), fix and source them so they become examples of quality instead of mistakes. It's an opportunity to work on the datas instead of ignoring them, in short. And it does not removes the possibility of imports from other databases with the database as a source later at all, Wikidata will handle that very well. TomT0m (talk) 10:32, 24 August 2013 (UTC)

---

I am not convinced at all about consensus here, so I'm not running SamoaBot 26 for now. --Ricordisamoa 23:54, 23 August 2013 (UTC)

---

Well, thanks for letting me know that you were discussing my close here... I think you have a few facts wrong. First off, the RFC I closed was Wikidata:Requests for comment/Sourcing requirements for bots. I closed the other one too, but I assume you're upset about this one. Secondly, you're misquoting me. I said "All proposals were overwhelmingly rejected" in the little summary table of WD:Requests for comment, that's not what my actual close is. I said: "As a whole, the idea of requiring sources is rejected. Sources are still recommended though, and bots should try to use better/reliable sources when possible. Legoktm (talk) 06:04, 23 August 2013 (UTC)". I believe that my statement accurately reflects the consensus below in the section "Main proposal". Since the proposal was not passed, we default back to the status quo which is that it is okay for humans and bots to add data that is not sourced (with the obvious caveat to use common sense). Legoktm (talk) 05:48, 24 August 2013 (UTC)

I'm sorry. I should have notified you. I also got the reference to the RFC wrong. Sorry again. Your summary above does reflect the balance of the vote on that RFC and again I apologise for suggesting otherwise. I was frustrated at the result going against me and reacted to quickly.

I still fear that adding millions of statements without sources will damage wikidata as it becomes an echo chamber of mostly right facts instead of the gold standard for accuracy it could have become. Filceolaire (talk) 08:30, 24 August 2013 (UTC)

Good luck with finding reliable sources for dates of birth. In many cases, no records exist, even the subject may not have known their own date of birth. Danrok (talk) 00:55, 29 August 2013 (UTC)

There is a related question at Wikidata:Project_chat#Best_place.2Fmethod_to_update_an_item_of_data_.28incorrect_date_of_birth.2Fdate_of_death.29 with a user trying to solve an actual Wikipedia problem. Maybe some of you have better suggestions to help the user solve this. --  Docu  at 02:17, 29 August 2013

Wrong interwikis for doc Subpages

Where can I found List of items which template documentations are linked to main template like this I want to correct them. Yamaha5 (talk) 13:00, 24 August 2013 (UTC)

Maybe User:Yamaha5/incorrect template interwiki? --Ricordisamoa 13:43, 24 August 2013 (UTC)

:)) I guess he means a more general list not only English wiki /doc –ebraminio^talk 16:25, 24 August 2013 (UTC)

No, like Q13421299 (see history). --Izno (talk) 16:42, 24 August 2013 (UTC)

This is a widespread problem which causes interwiki links to not appear in the right place. Could this not be fixed with a bot removing /doc (or equivalent) and reporting conflicts to be done manually? Del_♉sion23 (talk) 22:58, 24 August 2013 (UTC)

@Ricordisamoa: I want query result or list which shows all langs incorrect link. as you see I made User:Yamaha5/incorrect template interwiki :)

as Delusion23 said is it possible to solve them by bot. here is the sql

SELECT page_title FROM page join langlinks ON page_id = ll_from WHERE page_namespace = 10 AND page_is_redirect = 0 AND (page_title LIKE "%/doc%" or page_title LIKE "%/Doc%") GROUP BY page_title ORDER BY count(ll_from) DESC;

Yamaha5 (talk) 18:33, 25 August 2013 (UTC)

Ricordisamoa thanks for your bot.

• User:Yamaha5/incorrect_template_interwiki-fa  Done
• User:Yamaha5/incorrect_template_interwiki updated and added some new subpages
• User:Yamaha5/incorrect_template_interwiki-fr
• User:Yamaha5/incorrect_template_interwiki-es

please run you bot on these three. thanksYamaha5 (talk) 10:44, 26 August 2013 (UTC)

I could do it, but I'd wait for SamoaBot 37's approval; and please generate the list from itwiki --Ricordisamoa 16:38, 26 August 2013 (UTC)

At first I made list for italian and it seems italian users are so active and the list was empty :)Yamaha5 (talk) 19:32, 26 August 2013 (UTC)

Maybe it's because itwiki uses "/man" instead of "/doc" subpages, please check them again. --Ricordisamoa 01:27, 29 August 2013 (UTC)

User:Yamaha5/incorrect_template_interwiki-it here you are :)Yamaha5 (talk) 08:34, 29 August 2013 (UTC)

Data acccess for Wikivoyage and bugfixes plus testing needed for the URL datatype

Heya folks :)

Wikiyovage now has access to the data here - meaning they got phase 2. With this the first sister project is fully supported \o/ The next sister projects will follow. More information on this soon.

We've also just updated the software here. This brings a number of bug fixes and other improvements. The ones that are probably most important for you:

• The copyright warning no longer pops up again when you change your language
• There is now a new special page to list items/properties without a description in a given language. Thanks for the patch by Bene*.
• The message that pops up when you want to add a link to an item which is already in use in another item has been improved. Thanks for the patch by Nemo bis.
• Broken links to set sitelinks in the non-JavaScript version have been fixed. (bugzilla:51914, bugzilla:52095)
• The automatic comments for edits have been improved. They are more detailed now.
• API: You can now provide custom edit summaries for edits via the API.
• API: You can undo a revision via the API.
• API: Bot edits via the setclaim API module are now marked as such (bugzilla:50933).
• API: Precision and globe parameters are now required for geocoordinate data.
• Starting in a few days a Wikidata edit that shows up in recent changes and watchlist on the client (Wikipedia/Wikivoyage) is going to be marked with a "D". Thanks for the patch by umherirrender.

Unfortunately we were not able to put the URL datatype on the test system on time for this deployment. It didn't get enough testing so we couldn't deploy it today with a good conscious. We know you're waiting for this but it's better to give it a bit more testing and roll it out in 2 weeks with the next deployment. The URL datatype is now live for real on test.wikidata.org for you to try. Please give it a try and report any bugs you encounter.

Please let me know if there are any issues.

Wikidata's world

Oh and one more thing: Abraham, Denny and I sat down for an evening trying to capture what Wikidata is about in a video. Hope you like it :)

Cheers --Lydia Pintscher (WMDE) (talk) 22:05, 26 August 2013 (UTC)

I was expecting that each cloud and each person would be tagged with their Q number! Other than that looks nice :) --Micru (talk) 23:49, 26 August 2013 (UTC)

Hah! Damn... Missed opportunity right there ;-) --Lydia Pintscher (WMDE) (talk) 07:00, 27 August 2013 (UTC)

Since the update, User:Magnus Manske/missing props.js doesn't work anymore and User:Magnus Manske/wikidata useful.js have some bugs (on Firefox 23 and Internet Explorer 9). Pyb (talk) 12:40, 27 August 2013 (UTC)

What exactly is happening? We tried and it seems to work here. --Lydia Pintscher (WMDE) (talk) 13:05, 27 August 2013 (UTC)

There is probably a conflict between the gadget called Preview and User:Magnus Manske/missing props.js. Pyb (talk) 13:28, 27 August 2013 (UTC)

and my copy of User:Magnus Manske/wikidata useful.js was outdated. Now, everything works ;) Thx for your help. Pyb (talk) 13:39, 27 August 2013 (UTC)

Please check the newly added subtitles. I made some serious changes on them (like "disconnections" -> "these connections"), so either I really fixed it or I completely destroyed it. --YMS (talk) 19:44, 28 August 2013 (UTC)

accessing property P625 (coordinate location)

I cannot seem to access this property from Wikivoyage. When I use {{#property:P625}} or {{#property:coordinate location}} it returns a complete blank. Am I doing something wrong? Texugo (talk) 18:06, 28 August 2013 (UTC)

No unfortunately that's not supported yet in the parser function. We need to close bugzilla:50277 for this. Sorry! You can access it via LUA though. --Lydia Pintscher (WMDE) (talk) 19:13, 28 August 2013 (UTC)

Thanks. Is it available only in the degrees/minutes/seconds format, or can it be retrieved in decimal format as well? Texugo (talk) 19:17, 28 August 2013 (UTC)

It's only decimal format, but lua can be used to convert it to other formats. Aude (talk) 22:51, 28 August 2013 (UTC)

Just to double-check (since it displays on the data item in degree format), it's only available in decimal format? Or did you mistype? Texugo (talk) 23:14, 28 August 2013 (UTC)

Also, is there an existing Lua module somewhere I can use to access the lat and long coordinates individually? I don't know how to program my own. Any help would be greatly appreciated! Texugo (talk) 11:02, 29 August 2013 (UTC)

You might find some in: Property_talk:P625#ExternalUse --  Docu  at 19:08, 29 August 2013 (UTC)

See the coords function in it:voy:Modulo:Wikibase. --Ricordisamoa 19:26, 29 August 2013 (UTC)

Great, thanks. I'll play around with that. That had been added since I first looks at it: Wikibase a few days ago... Texugo (talk) 22:01, 29 August 2013 (UTC)

Bot tasks

Two bot tasks were proposed on Wikidata:Bot requests by Magnus Manske:

• Set sex:male for item list (permalink)
• Birth and death dates from prepared list (permalink)

They got formally approved, but gained several oppositions. But if there is anyone who thinks these two tasks should not be done, please speak now or forever hold your peace, since I'll start them in few days. --Ricordisamoa 20:32, 28 August 2013 (UTC)

• Both look OK to run to me. Ajraddatz (Talk) 21:58, 28 August 2013 (UTC)

  Long discussion there. Snipre (talk) 00:38, 29 August 2013 (UTC)

•  Support. Ayack (talk) 06:46, 29 August 2013 (UTC)

International infoboxes

Maybe I am missing something, but I see talk about using the various properties for infoboxes for city, region, country, states articles, etc. but isn't a lot of that functionality really limited to only the English versions of WP and WV? If I make an infobox for Poland on ja: or pt:, etc. and then pull the property for capital or currency or type of government, I will only be able to get them in English, right? Texugo (talk) 23:13, 28 August 2013 (UTC)

I don't believe that's the case, unless the information here isn't filled in. I'm pretty that whatever language project you're on will cause the related information to show up in a particular way. --Izno (talk) 23:56, 28 August 2013 (UTC)

Maybe I'm not explaining myself well. Imagine I'm on ja: and I want to make an infobox that calls the "capital" property. The only data stored in the wikidata item for that property is "Andorra la Vella", in English. There is no way for it to come back with アンドラ・ラ・ベリャ because there is no place for multiple language labels to be stored, neither in the item for Andorra nor in the item for its capital. The same can be said of all the other non-code properties. Am I missing something? Texugo (talk) 01:08, 29 August 2013 (UTC)

Yup, you can't see the input forms for the non-English properties. Add babel boxen to your user page for the languages you're interested in, or install the LabelLister gadget, then browse to any particular item of interest. (See also the the paper cut on this very issue.) --Izno (talk) 01:22, 29 August 2013 (UTC)

The 'Capital' property has a multilingual label and a multilingual description. The items for 'Andorra' and for 'Andorra la Vella' (capital of Andorra) also have multilingual labels and descriptions. If no one has input Japanese Labels and Descriptions for these properties and descriptions then there is no way to come back with Japanese labels. To enter Japanese labels change your language to Japanese using the mysterious symbol near your user name at the top of the page. To see (and edit) multiple languages at the same time put a babel box on your user page listing the languages you want to see. Hope this helps. Filceolaire (talk) 01:25, 29 August 2013 (UTC)

Excellent. Exactly what I needed to know. Thanks! Texugo (talk) 01:36, 29 August 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ A good piece of advice for all those people that post welcome messages. Add a little message about babel. A lot of people are missing out on a real cool feature. You can copy paste the code of the welcome message from my page to your own user page if you want to. Also babel should be added to the standard welcome message. --Tobias1984 (talk) 06:37, 29 August 2013 (UTC)

Interwiki links to incubator versions

I see that the Wikivoyage article on Japan is able to link to the Chinese Wikivoyage article in Wikimedia Incubator.

Can someone also help enable the English Wikipedia articles to link to the other Wikipedia test editions in Wikimedia Incubator? --DaveZ122 (talk) 09:23, 29 August 2013 (UTC)

That's an old-school local interwiki link: [[zh:日本]]. Should be possible to insert this in the English article, too, but I doubt it's a good thing to to. Just wait until Chinese Wikivoyage becomes a regular project and you can insert a regular interwiki link. --YMS (talk) 09:26, 29 August 2013 (UTC)

Bluestone (English), Blauwe hardsteen (Dutch)

I think the English page Bluestone might have to be merged with the Dutch (nl) page Blauwe hardsteen, but it's already linked with other pages. – The preceding unsigned comment was added by 94.224.53.151 (talk • contribs) at 11:56, 29. Aug. 2013‎ (UTC).

bluestone (Q4930575) and bluestone (Q325173) I presume. -- Nemo157 (talk) 14:30, 29 August 2013 (UTC)

 Merged Del_♉sion23 (talk) 20:47, 29 August 2013 (UTC)

Merge ?

Q6581324 and Q6938689 --Rippitippi (talk) 16:00, 29 August 2013 (UTC)

Why (and how)? One is for a single year, one is for the whole decade. In many Wikipedias, both will exist, and the first will be a subcategory of the latter one. --YMS (talk) 16:11, 29 August 2013 (UTC)

Thanks for that, I also didn't notice... seems like I have a word-blindness... :) --Stryn (talk) 16:18, 29 August 2013 (UTC)

Surely you're only joking... Littledogboy (talk) 16:13, 29 August 2013 (UTC)

yes my fault, is time to go away from pc :-) --Rippitippi (talk) 16:39, 29 August 2013 (UTC)

Want to get red links

Hello! I'm making a template that collects data from Wikidata in basque Wikipedia, in order to get some data from cities automatically. I have noticed that certain data doesn't appear if it doesn't exist that object in our language. For example, if I put the template in the article about eu:San Francisco I don't get the mayor's name, because there's not such article in our wiki. Is there any way in which I can force the data, knowing that it's a name, in our wiki? -Theklan (talk) 19:47, 29 August 2013 (UTC)

You must add label in euskara. Now I have added. Can you check if now appear? --ValterVB (talk) 20:23, 29 August 2013 (UTC)

Yes! Now it appears, but without the red link. Only in plain text. -Theklan (talk) 20:29, 29 August 2013 (UTC)

But, there should be another solution. Mayor names are names, so they don't suffer lots of changes from their original name to the name that shall be displayes in other languages. If the link is red, it could encourage people to make more articles. But if we have to make the label in order to see it, then we don't know if the data exists in Wikidata or not. -Theklan (talk) 20:34, 29 August 2013 (UTC)

Template:Finished and Template:Section resolved

Could those be merged? --Ricordisamoa 23:02, 29 August 2013 (UTC)

Yeah. I think that Finished could just be redirected to Section resolved, since the latter is bot archived it seems. Ajraddatz (Talk) 00:24, 30 August 2013 (UTC)

Merge

Item Sardaukar (Q1256675), which is hungarian "Sardaukarok", must be moved into Sardaukar (Q2479721) = Sardaukar in english and others. Sardaukar (Q1256675) was generated by a robot. "Sardaukarok" is a plural form of word "Sardaukar". BR, Pkunk (talk) 06:48, 30 August 2013 (UTC)

 Done if you find any more please add them at Wikidata:Requests_for_deletions --Tobias1984 (talk) 07:26, 30 August 2013 (UTC)

Thank you, Tobias1984 -- Pkunk (talk) 07:36, 30 August 2013 (UTC)

Wikied

For all of those people using wikiEd. I'm just asking for two buttons to be added to the toolbar to quickly link to items and properties. If you have an opinion about that please join the discusion at en:User_talk:Cacycle/wikEd#Wikidata_links_to_items_and_properties. --Tobias1984 (talk) 07:29, 30 August 2013 (UTC)

Automatic archive/Split by month for WD:IC

Does anyone know how to set up automatic archival for Wikidata:Interwiki conflicts? It would save it having to be done manually. Also, what do people think about separating out the reports into different pages by month? The list is getting very long and unmanageable. Del_♉sion23 (talk)

Hazard-Bot (and similar) should be instructed to archive sections only if "status = resolved". --Ricordisamoa 01:40, 30 August 2013 (UTC)

If you ask me: AA – yes please, perhaps 5 days after marking as resolved (if possible); split – no. Littledogboy (talk) 12:42, 30 August 2013 (UTC)

If anyone knows how to get Hazard-bot to begin performing archives that would be great, thanks. On the second point, I disagree with Littledogboy, I think splitting it would be better. We still have several reports from November and December when the project first began, some ICs do not get solved quickly. This is usually because they are very complicated. I think it is desirable to split them by month, and then concentrate on emptying each page with the earliest being prioritised. If they are not split, the page will eventually become impossible to navigate. Del_♉sion23 (talk) 22:02, 30 August 2013 (UTC)

What happened to the 'Move' gadget?

I have the Move gadget enabled but it isn't showing up in the sitelink 'edit' menu.

Anyone know anything about this? Filceolaire (talk) 01:00, 30 August 2013 (UTC)

 fixed, thank you for reporting; some updates on the Wikibase UI had changed many CSS classes. --Ricordisamoa 01:23, 30 August 2013 (UTC)

Thanks. That's great. Filceolaire (talk) 22:04, 30 August 2013 (UTC)

Anyone else having problems when moving more than one sitelink (first one works fine, second one also works, but dialog window isn't closed; in Opera at least)? --YMS (talk) 22:22, 30 August 2013 (UTC)

On a similar subject, I need to click twice on "edit" to edit identifier properties (VIAF, BnF...) and there seems to be no way to modify such strings - need to be deleted and recreated ?! See France Martineau (Q3080732) for example - LaddΩ chat ;) 03:18, 30 August 2013 (UTC)

That was a similar error on AuthorityControl.js;  fixed. --Ricordisamoa 08:16, 30 August 2013 (UTC)

Great! :) Thanks - LaddΩ chat ;) 12:05, 30 August 2013 (UTC)

Grouping external identifier statements

Given the continuous stream of new "identifier" properties, I wonder if it would not be possible to group them at the bottom of each item, somewhat like inter-language links, some kind of purely formatting-level grouping. - LaddΩ chat ;) 14:23, 30 August 2013 (UTC)

92 identifier properties according to Aug 27th's User:Byrial/Property_statistics

Property	Label (English)
P:P214	VIAF identifier
P:P227	GND identifier
P:P244	LCCN identifier
P:P247	COSPAR ID
P:P268	BnF identifier
P:P269	SUDOC identifier
P:P271	CiNii author identifier
P:P345	IMDb identifier
P:P349	NDL identifier
P:P351	Entrez Gene ID
P:P352	UniProt ID
P:P354	HGNC ID
P:P359	Rijksmonument identifier
P:P373	Commons category
P:P380	Mérimée identifier
P:P396	SBN identifier
P:P402	OpenStreetMap Relation ID
P:P409	NLA identifier
P:P434	MusicBrainz artist ID
P:P435	MusicBrainz work ID
P:P436	MusicBrainz Release Group ID
P:P454	Structurae ID
P:P455	Emporis ID
P:P477	Historic Places identifier
P:P480	Filmaffinity identifier
P:P481	Palissy identifier
P:P486	MeSH ID
P:P492	OMIM ID
P:P497	CBDB ID
P:P502	HURDAT identifier
P:P535	Find a Grave ID
P:P536	ATP ID
P:P549	Mathematics Genealogy Project identifier
P:P586	IPNI author ID
P:P593	Homologene ID
P:P594	Ensembl Gene ID
P:P595	IUPHAR ID
P:P597	WTA ID
P:P599	ITF ID
P:P604	MedlinePlus ID
P:P633	Répertoire du patrimoine culturel du Québec identifier
P:P635	ISTAT ID
P:P637	RefSeq Protein ID
P:P638	PDB ID
P:P639	RefSeq RNA ID
P:P640	Léonore ID
P:P646	Freebase identifier
P:P648	Open Library identifier
P:P661	ChemSpider ID
P:P662	PubChem ID (CID)
P:P665	KEGG ID
P:P667	ICPC 2 ID
P:P668	GeneReviews ID
P:P671	Mouse Genome Informatics ID
P:P675	Google Books identifier
P:P683	ChEBI ID
P:P685	NCBI Taxonomy ID
P:P686	Gene Ontology ID
P:P687	BHL Page Id
P:P696	Neurolex ID
P:P698	PubMed ID (PMID)
P:P699	Disease Ontology ID
P:P700	Kemler ID
P:P704	Ensembl Transcript ID
P:P705	Ensembl Protein ID
P:P709	Historic Scotland ID
P:P715	Drugbank ID
P:P716	JPL Small-Body Database identifier
P:P718	Canmore ID
P:P721	OKATO identifier
P:P723	DBNL ID
P:P724	Internet Archive ID
P:P727	Europeana ID
P:P728	GHS hazard statement ID
P:P731	Litholex ID
P:P732	BGS Lexicon ID
P:P745	Low German Bibliography and Biography ID
P:P757	World Heritage identifier
P:P758	Kulturminne identifier
P:P759	Alberta Register of Historic Places identifier
P:P760	DPLA ID
P:P761	VISS ID
P:P762	Czech cultural heritage ID
P:P763	PEI Register of Historic Places identifier
P:P764	OKTMO identifier
P:P791	ISIL ID
P:P804	GNIS Antarctica ID
P:P809	WDPA id
P:P818	arXiv eprint identifier
P:P821	CGNDB Unique Identifier
P:P824	Meteoritical Bulletin Database ID
P:P827	BBC programme identifier

I think that is a good idea, I would even favor Tabs, one for identifiers, and one for deprecated (historical) information.--Micru (talk) 15:11, 30 August 2013 (UTC)

The devteam will implement statement display order configuration. We will be able to do that, by ranking, or semi automatically a community bot. TomT0m (talk) 15:23, 30 August 2013 (UTC)

Any timeframe set? LaddΩ chat ;) 16:55, 30 August 2013 (UTC)

Don't think so, but my source is the office hour log, maybe I missed something in there reading too fast. TomT0m (talk) 17:18, 30 August 2013 (UTC)

Major Wikidata users are not humans. Making beautiful user interface for Q-pages is not major task. More important task is creating easy to use data model and data set. Grouping, coloring, and etc. are tasks for data visualization systems (for example for infoboxes). — Ivan A. Krestinin (talk) 16:07, 30 August 2013 (UTC)

For now, it is often human users who manually fix constraint violations, resolve property conflicts and merge individual items. Until visualization systems or ordering get deployed, scrolling up and down for pages is a pain - effort would be better spent elsewhere

BTW most such identifiers feature a clickable link meant for human users - LaddΩ chat ;) 16:55, 30 August 2013 (UTC)

I wonder if it is possible to use just one property named "identifier" and add many qualifiers for GND, VIAF .... and whatever you need in future. It is also sometimes troublesome to be unable to choose the position of a property, so sometimes properties that belong together are in a divided position. There should be a defined table for the properties which alows the software to reposition the order of properties to "default" order. This would inprove overview and readability a lot and helps to identify missing properties more easily.--Giftzwerg 88 (talk) 00:04, 31 August 2013 (UTC)

OpenData

I just want to mention a french article on a blog hosted by the newspaper Le Monde (Q12461) about the OpenData. To summarize 1) no unique structure for data storage 2) two approaches: Open Data and Open API 3) data quality is essential for data use.

Link: here (sorry, in french). Snipre (talk) 18:30, 30 August 2013 (UTC)

 Comment No mention of Wikidata: Wikidata is not yet considered as a major player of the OpenData. Then there are plenty of other projects working on the subject. If wikidata want to become a player among the others we have to propose something which isn't really done yet and this can the merge of different open databases into an unique database, Wikidata. For this we have to concentrate on data extraction from open databases like census databases from the different countries. If we can propose in an unique system data currently available in separated and non compatible databases we will offer something new in the OpenData world. Snipre (talk) 19:05, 30 August 2013 (UTC)

Interesting, thanks. --Tobias1984 (talk) 19:18, 30 August 2013 (UTC)

Wikidata is still in development, the crucial parts which are the value data type and queries are not ready yet. And there is no mechanism for handling big chunks of raw data... at least there is some interest in finding a solution for that (see the discussion page on meta:DataNamespace). When all that is solved, then we can complain about not being mentioned, but so far we can feel lucky enough if anyone knows at least dbpedia which is in the game much longer. OTOH, Wikidata's role is not as much in data creation, as it is in data curation and distribution, which is a different category.--Micru (talk) 19:32, 30 August 2013 (UTC)

What Micru said. Wikidata will succeed if it can provide a seamless user interface for editors of the other WMF projects to edit wikidata so we have a large number of editors curating the data.

Our Unique Selling Points will be:

• Large number of editors
• User interface in 200 languages
• the Wikipedia brand (you don't need to ever hear the name wikidata to use or edit our data)
• quality of our data (Yes; eventually)

We are a long way from that at the moment but we might have something ready to launch by wikimania 2014, this time next year. Filceolaire (talk) 21:58, 30 August 2013 (UTC)

@Snipre : that's not surprising that Wikidata is not mentioned, not only the project is young but also, when we speak of Open Data we usually speak of publication of datas by public administrations and services, this article is an example of that. Wikidata could do that, but that's not its main goal. Last but not least, I want to cite something : OSM a alors développé un outil pour permettre aux contributeurs d’OSM d’unifier les données de cette base, permettant à la fois d’améliorer les données d’OSM et celles du producteur. OSM is cited, its model is more a crowd generation and aggregation of data, successful it looks like, than a we just import datas from other sources and cite them model. It seem that there is other ways :) TomT0m (talk) 00:06, 31 August 2013 (UTC)

NO:Prima Vista

I think Prima vista in Norwegian should be linked with Blattsingen in German. --Trygve W Nodeland (talk) 21:01, 30 August 2013 (UTC)

 Merged sight reading (Q1066850) into sight reading (Q882254). Thanks for reporting, --Ricordisamoa 21:27, 30 August 2013 (UTC)

Large number of merges

I've stumbled upon a large list of merge candidates. There are many Basa Sunda (su) language links about Indonesian places listed at this page that need merging (see a few scrolls down the page). They take the form of "Place, Place, Place" and almost all of them have an equivalent link in Indonesian (id) already on Wikidata. The only difference is that the su link will have accents on the letter e, whereas id will not. Searching for the Sunda (su) link in Wikidata will usually bring up the item for the equivalent link in Indonesian (id).

A recently merged example is "Karanglayung, Conggeang, Sumedang" (Karanglayung, Conggéang, Sumedang).

It would be great if a way could be found to automate these merges, but if not, there's a lot of work here for any Wikidatans who specialise in merging. These pages have gone without a link to any other Wikipedia for about 7 years. I've fixed some that went back 9 years. Del_♉sion23 (talk) 23:48, 27 August 2013 (UTC)

I will soon make some tests with my script. Regards, --Ricordisamoa 04:09, 28 August 2013 (UTC)

 Doing… --Ricordisamoa 12:18, 28 August 2013 (UTC)

 Done for all pages in su:Kategori:Kalurahan/désa di Indonésia --Ricordisamoa 01:29, 29 August 2013 (UTC)

Wow, thanks so much :) Del_♉sion23 (talk) 20:08, 29 August 2013 (UTC)

 Doing… for su:Kategori:Kabupatén di Indonésia --Ricordisamoa 01:00, 30 August 2013 (UTC)

Both su:Tegalsumedang, Rancaekek, Bandung and su:Tegalsumedang, Rancaékék, Bandung exist: should one of them be deleted? --Ricordisamoa 01:31, 30 August 2013 (UTC)

I think they should be merged into the one with accents on the e and then the empty one redirected. Del_♉sion23 (talk) 23:45, 31 August 2013 (UTC)

Minimalismus/Minimalisme (architectuur) should be merged.

Would someone please merge the Dutch Minimalisme(architectuur) and Frisian Minimalisme (arsjitektuer) with the German Minimalismus(Architektur)? Thank you. Suidpunt (talk) 09:28, 31 August 2013 (UTC)

 Merged Del_♉sion23 (talk) 10:03, 31 August 2013 (UTC)

Baie dankie! Suidpunt (talk) 10:06, 31 August 2013 (UTC)

RfC:Guidelines_for_RfC_process

Last day to propose modifications to the draft of the Wikidata:Requests_for_comment/Guidelines_for_RfC_process. Without any big modifications or question I will close the discussion part tomorrow and start the decision part on Monday for 4 weeks. Snipre (talk) 12:40, 31 August 2013 (UTC)