Hi, I think it would be useful to have a noticeboard for translation administrators, like the ones for administrators (WD:AN) and bureaucrats (WD:BN), to contact the TAs and to discuss things related to translation administration if required. I just want to hear if there is objections or suggestions before I create the page. Regards, Byrial (talk) 08:42, 24 April 2013 (UTC)
My only concern would be wondering if the AN is busy enough to justify splitting it off into a third rights-based noticeboard? Maybe a "Translations noticeboard" rather than one that is labeled for TA's would have more scope and traffic? Courcelles (talk) 18:17, 24 April 2013 (UTC)
I do not see it as a split from the administrators' noticeboard. As you can see in the page translation log, most active TA's are not administrators. But the name "Translations noticeboard" is fine for me, as it signals that everybody are welcome, not just the TA's. Byrial (talk) 09:47, 25 April 2013 (UTC)
I noticed some users are moving aliases from "en" to "en-gb" and thus effectively making "en" an "en-us" version.
I don't think "en" should be limited to "en-us". Whether there is a need for an "en-us" version is another question. -- Docu at 09:36, 25 April 2013 (UTC)
It's happening the same in Portuguese, with European Portuguese "pt" and Brazilian Portuguese "pt-br". I use European Portuguese, but I don't think that the code is OK, principally because many of the Brazilian Portuguese users are editing in "pt" with the "pt-br" variant. The only solution I see (because I think that languages versions are useful to avoid editing war) is rename "pt" to "pt-pt" or "pt-eu" and "en" to "en-us" and others be divided if needed, like in Spanish or French. - Sarilho1 (talk) 15:06, 25 April 2013 (UTC)
Projects have a need for multiple versions of a language. Where multiple versions exist, a "hierarchy" would be useful. This would allow the author of an article about a British subject to use Wikidata in the infobox, select en-gb as the language and have en-gb used if it is available, but default to en if en-gb isn't available. We wouldn't be able to support this if we made "en" US English. Of course someone will no doubt tell me that (a) this feature is already available or (b) it would never work! QuiteUnusual (talk) 15:31, 25 April 2013 (UTC)
The real question is, if "en" ≠ "en-us", than what is "en"? I don't think that we can represent all English variants with a single "en" version. The Anonymouse (talk | contribs) 00:02, 2 May 2013 (UTC)
en is en-us. This has probably historical reasons, because Jimbo co-founded Wikipedia in the US, so that the first contributors where American. Regards, Vogonetalk00:32, 2 May 2013 (UTC)
en is only en"-us" in the interface. en.wp for example allows both British English, American English, and a handful of other recognized dialects to be used for an article. Which I think we should respect. Users who are moving things around nonsensically should be asked to stop, and, quite frankly, editors shouldn't be able to change the other languages. But maybe in this case Wikidata is better than the other wikis in this regard, because we can have the languages separate? I'm not sure. (See below with the de-formal considerations.)
Anonymouse, I don't think we should care (if and until we need to integrate Wiktionary, which has other issues on top of that). --Izno (talk) 02:09, 2 May 2013 (UTC)
en:Jugular vein is essentially the same as de:Vena jugularis, Vena jugularis is the Latin term for jugular vein (or better: jugular vein ist Latin derived English). There are three jugular veins, there is no proper jugular vein. The English article (and those in all other languages) is just an explanation of this fact and therefore a kind of disambiguation page even if it is not labelled as a disambiguation. I do not know who had the strange idea to settle Interwiki links over to a project where experts do not have access rights.--Uwe Gille (talk) 13:35, 28 April 2013 (UTC)
Hey Uwe Gille, you will get all the base you belong, please explain your problem with the access rights. Greetings, Conny (talk) 15:39, 1 May 2013 (UTC).
Political offices
US: head of State: Barack Obama, legistlative body: US congress. There is some inconsistency here.
I think we should rather have "head of State: President of the United States, and have the list of US presidents, with date qualifiers, in Q11696. But then should we do that with mayors of Small Town, Nowhere ? Should we create a "Mayor of Small Town, Nowhere" item containing the list of mayors ? --Zolo (talk) 08:46, 28 April 2013 (UTC)
This sounds like av very useful solution also for other complicated subjects, like the division of Sweden. Add the list of counties in "Q200547", the list of Provinces in "Q193556", instead of in the item of Sweden. A Province is not above or under a County, and it's not as simple as describing them as administrative division until XX, since they still are used for several purposes, and some of them did not even exist when they where administrative. It would also make it easier to describe other kinds of semi- and or non-administrative division. -- Lavallen (block) 11:36, 28 April 2013 (UTC)
I agree, re presidents. Alternatively, the data about who the presidents were at whatever times could be held by the items for the individuals (office held: POTUS, 2000-2008), but regardless of that, the value for head of State should reference the position, not the person. Re "Mayor of Small Town, Nowhere" items, I'm not sure. Would we also do that for parliamentary constituencies? One item for Constituency #523, and one for Member of Parliament for Constituency #523? Maybe it would be better to limit the use of items for positions to those that would already have items by merit of having a Wikipedia article somewhere? --Yair rand (talk) 16:09, 28 April 2013 (UTC)
Re smaller places, maybe replace the "head of the local executive" with a "local executive" one taking values like "Mayor–council government" ? But we still need to retrieve the name of the person himself for the infobox. I guess I would be fine with having it in the item about the him, but that seems to mean that many infoboxes will have to make rather complex queries in the full database to find the person holding the right office, at the right place and time. That sounds a bit expensive, doesn't it ? --Zolo (talk) 07:35, 30 April 2013 (UTC)
When I worked with the items related to Poland, I found that the title of the Mayor in a city/municipality/county could be different depending on the local tradition. In Sweden there is also different titles depending on location. This is more complicated than it first looked. -- Lavallen (block) 13:18, 1 May 2013 (UTC)
I believe that the current false positives' rate is low enough so this filter should prevent users from editing (or at least show a warning), instead of simply tag the change. --Ricordisamoa13:35, 30 April 2013 (UTC)
Eh, there are still some false positives. I have no clue what motivates people to add the language as the description, though O_o Ajraddatz (Talk) 13:34, 1 May 2013 (UTC)
With several hundred languages, a hope about a working summary for a single language, a regexp that hopefully only match correct words, and a system for warning messages that is completely inadequate for the intended use – no this will not work. Some of the problems can be fixed, but the main problem is that the whole idea is wrong. Imagine ~400 filters to do this in all languages. In a multilingual environment it is necessary to use multilingual tools to handle language issues. In this case the tool is grossly inadequate for the issue it shall solve. Jeblad (talk) 20:36, 1 May 2013 (UTC)
Original Photos of Mid-Century U.S. Weapons Components and Historical Documents from the US Navy Yard, Washington DC.
Just wanted to share - maybe folks have use for this material. Missiles, munitions - useful primary visual resources for Wikipedia. I will be adding about 125 images. Please see my album (Picasa) at the following address:
We've made 3 submissions for this year's Wikimania. If you're going to be there it'd be lovely if you could vote for them by adding your name at the bottom of the proposal:
We've just deployed new code here including bugfixes. The ones you probably care about are:
when clicking "edit links" on a Wikipedia article the user is automatically taken to the language links part of the item. Hopefully it is now more obvious how to change the links.
fixed a few cases where edit conflicts where detected in error
added automatic edit summaries for adding qualifiers and claims
I don't know is this related to these bugfixes, but when I go to user contributions page, e.g. my Special:Contributions/Stryn, there is linked "newer 100" and "latest". Before they haven't been links. --Stryn (talk) 20:44, 1 May 2013 (UTC)
The Wikidata client just "invited" me to create a link from my User talk page, so I did, and it's here: Q11843281. Question: I thought we weren't supposed to use Wikidata links for user pages. So why did it invite me? Is this a bug, or did I miss a change in policy? StevenJ81 (talk) 19:51, 24 April 2013 (UTC)
I've deleted it. You might consider dropping a question on Lydia's talk page (who is present in the topic just above this). --Izno (talk) 20:04, 24 April 2013 (UTC)
I think we could reconsider this policy, I see no real good reason not to be able to manage user's interwikis ... Plus does not it make sense to have an item for a Wikimedia contributor ? TomT0m (talk) 10:18, 25 April 2013 (UTC)
Wikidata isn't really that good at managing non-article interwikis. Such items tend to get lost in the main content. Already disambiguation pages are more a burden than much help. -- Docu at 11:17, 25 April 2013 (UTC)
I don't understand, what do you mean by that ? User pages could be managed by users themselves if it is that a burden. Classifying them is easy with a property - or by a bot, it's easy to check if an item is linked to a page in Users namespaces. TomT0m (talk) 15:39, 25 April 2013 (UTC)
If it's easy for categories and disambiguation pages, could you get it done? It would really help. -- Docu at 15:43, 25 April 2013 (UTC)
Related Question
While we're at it, though: are iw's (even coded ones, rather than Wikidata ones) forbidden on User talk pages? I tried to add one there, but it appeared like a regular, in-line text link. StevenJ81 (talk) 15:59, 29 April 2013 (UTC)
No, interwiki links don't "work" (show up on the left sidebar) on user talk pages. In fact, interwiki links don't "work" in any talk namespace. The Anonymouse (talk | contribs) 23:57, 1 May 2013 (UTC)
Redundant information in geo-info, what is the policy?
I've got a question that has bothered/been wondering me for some time, and may have been discussed before: what is the wikidata policy for using geo-info? There are a lot of items that can be related to some geo-item. But do we need to link to only the smallest geo-unit that can be associated to the item, or repeat all upper-level geo-info?
E.g. If we have a town in the Netherlands, should we mention the municipality, country and continent (the last 2 would be redundant info), or only the municipality? It can have a lot of impact, e.g. by accident I encountered the item Volkswagen. Should we only state it is in Wolfsburg, or also Niedersachsen, Germany, Europe. I did some searches, but did not find a clear answer about this. My opinion: no redundant info, mention the smallest unit, the rest can be queried. Droadnaegel (talk) 22:52, 28 April 2013 (UTC)
Support I agree with the principle "no redundant data", we just have to be careful in the cases when several parallel systems of division applies to put in in the smallest (available) unit within every system. Also: do we already have a way to query needed data from the available data, or is it still a planned feature? The help pages didn't help me to much (yet)...--Šlomo (talk) 10:39, 1 May 2013 (UTC)
Šlomo and Lavallen, it's very true we need to be careful. And make unambiguous hierarchies. So if an item has 2 or more upper administrative levels, the items immediately below it need to resolve it (probably hard to automate). But my point is that we ONLY need to resolve it in the levels immediately below. E.g. Netherlands has 2 continents (probably applies to more countries like Turkey, U.K. ). Then the continent needs to be set in all the provences in the Netherlands. But, only there. There is no need to repeat all this info in all the items below that. E.g. Q4989654 (Huize Ruurlo) now points to Gelderland AND Netherlands. To avoid redundancy it should only point to Ruurlo (if unambiguous, else add one more upper level). Then Ruurlo should point to Berkelland. Berkelland to Gelderland. Gelderland should point to Netherlands and Europe(to solve the 2 continents in Netherlands). And Netherlands finally point to 2 continents. There is no need to repeat all this info in all items below each of the levels. That would be redundant and harder to maintain. Droadnaegel (talk) 18:57, 1 May 2013 (UTC)
Is see one serious problem with "in administrative level". In Sweden there is only 3 administrative levels. The state, the county and the (primary) municipality. Secundary municipality is nothing you tell something is located in. If I would say that "I live in the Västernorrlands Ländsting", it sounds like I live in the office of the municipality-administration. The secondary municipalities are not geographic in that sense. All of Sweden is divided in församling, but #1, it is not an administrative division, #2 there can confusion of what aspect of "församling" I am talking about: Is it census, clergal activity or an election? We also have some other kinds of division, but they are not administrative, and several of them do not cover all of Sweden. In many cases is there also hard to tell in which socken/församling something is located. Sometimes it's even hard to tell in what landskap. So, yes, we should avoid redundant information, but it is not always that simple. -- Lavallen (block) 13:24, 2 May 2013 (UTC)
It should in each case use the Property:Is_in_administrative unit to give a link to the administrative unit it is in. The guidelines for places say to give the country as well but not all the intermediate administrative units. Filceolaire (talk) 14:44, 2 May 2013 (UTC)
@Lavallen, I share your concern. E.g. in the example I gave above, all buildings, statues, bridges, ... should go into Berkelland if it must go into an administrative unit. But a more specific division is possible, i.e. the town/village/city in that lowest administrative unit. So the castle Huize Ruurlo could go into Ruurlo (a village), but the problem is that that is not an administrative unit, but still useful as geo-location. Even the lowest ADMINISTRATIVE unit can be subdivided into multiple units with geo-relevant data (a municipality still can have multiple villages), and I would like to have that possibility, but P131 is not suited if limited to administrative units (and to stay ontopic, also the levels above should not be repeated for all these bridges, buildings etc. Just Ruurlo should suffice if unambiguous).
@Filceolaire, interesting to know there are guidelines, do you have a pointer where they are? I could not really find them, except for a discussion on P131 talk page (without clear consensus/decision), and a very general guideline about hierarchies. Droadnaegel (talk) 20:24, 2 May 2013 (UTC)
[en] Change to section edit links
The default position of the "edit" link in page section headers is going to change soon. The "edit" link will be positioned adjacent to the page header text rather than floating opposite it.
Section edit links will be to the immediate right of section titles, instead of on the far right. If you're an editor of one of the wikis which already implemented this change, nothing will substantially change for you; however, scripts and gadgets depending on the previous implementation of section edit links will have to be adjusted to continue working; however, nothing else should break even if they are not updated in time.
Ideas to do this all the way to 2009 at least. It is often difficult to track which of several potential section edit links on the far right is associated with the correct section, and many readers and anonymous or new editors may even be failing to notice section edit links at all, since they read section titles, which are far away from the links.
In future, all you need to do is move the sitelinks from the highest item into the lowest item and then list the item at Requests for Deletion. On a side note, I have done this for you and Deleted the item. John F. Lewis (talk) 16:46, 2 May 2013 (UTC)
In the property description I read that it may have only 7 values, but really I can add any item as value for this property.--Ahonc (talk) 15:27, 2 May 2013 (UTC)
A data-type which only allows a limited number of values are not created yet, and I do not know if there are any plans for it. Meanwhile, there are external scripts who watch this property to see if there are invalid values anywhere together with a abusefilter. -- Lavallen (block) 16:36, 2 May 2013 (UTC)
Developers have made it clear that they don't intend to implement anything that would restrict values for a property. Their rationale has something to do with freedom and not imposing ontologies but I suspect convenience for developers is also a bit of motivation. In any case I'm sure somebody has a bot, a bot project or a plan for some sort of edit filter that will make it easy to automatically or semi-automatically flag or correct "incorrect" values for P107 or other properties where only a small range of values make sense. Pichpich (talk) 02:23, 3 May 2013 (UTC)
P:P463 "member of" that according to the description is supposed to be restricted to people.
Can I relabel/rediscribe them, so that we get two plain, symmetrical properties "members" and "member of" ? Properties are supposed to define relations, I cannot see any use in contraining the type of item this way. Actually, it even prevents from stating that the European Union is a member of the World Trade Organisation (reminds me of User:Denny Vrandečić (WMDE)'s "restricting-the-world" blog post).
Relating to #Political officesabove: would it be ok, to put the list of US presidents in the "member" property of the "president of the US" item ? It may not be scalable to small villages, but at least it would make things easy for major offices ? --Zolo (talk) 17:43, 2 May 2013 (UTC)
Precisely which relation does member of (P463) define? How does it relate to the more generic part of (P361) property? Is 'member of' simply 'part of' where the domain (allowed subjects) is people and administrative units and the range (allowed objects) are organizations? If so, and if member state (P100) is to be merged into 'member of' because the former is redundant, then why not merge 'member of' into 'part of'? Emw (talk) 03:34, 3 May 2013 (UTC)
"Member states" is the reciprocal of "member of" (see United Nations). I am not sure that this property is a very good idea, but currently, it exists.
The member / part distinction has been discussed before the property creation. I think "member of" is an intransitive subproperty of "part of". --Zolo (talk) 06:15, 3 May 2013 (UTC)
Template:Infobox football biography
Hello. I would like to ask if, later, there will be a different use of templates like Template:Infobox football biography. I meam, for example, in the page Javier Saviola there are the teams he played and others. If we put date and place of birth and the appearances, goals, years of every team, there will be a way by using the template and the name of the player of the wikidata page, to have a full completed template in every wikipedia that use the template, using the interwikis of every team etc; Maybe Ι wasn't clear, english is not my mother language. Xaris333 (talk) 18:04, 2 May 2013 (UTC)
No, I'm talking about a javascript/css-solution to add such links under the toolbox but above the interwiki-links, ie, without any code at all in the page. -- Lavallen (block) 18:44, 2 May 2013 (UTC)
Edit link for section now appears at the wrong place. Didn't it use to be at the right side of the screen? Can this be fixed? -- Docu at 05:33, 3 May 2013 (UTC)
Hi. I enabled the LabelLister gadget, but nothing changes. Maybe the newer Java versions are the problem, but Cat-a-lot on Commons shows up. Any ideas, any hints? (I still have Windows XP) Thx --Chris.urs-o (talk) 06:42, 2 May 2013 (UTC)
Can you see the "Labels list" button next to the "Read" one? When clicking on it (if there), what happens? Out of curiosity, what skin are you using? FrigidNinja11:29, 2 May 2013 (UTC)
Thx. The Google Chrome skin is standard, I didn't change it. I was looking for something on the corners of the screen like Cat-a-lot of Commons, I didn't see the 'Labels list' tab next to the 'Read' one. --Chris.urs-o (talk) 11:58, 2 May 2013 (UTC)
You missunderstood me. I didn't see it before User:FrigidNinja said where I should look. I see it now, shame on me. --Chris.urs-o (talk) 13:19, 2 May 2013 (UTC)
As part of its Task 5, SamoaBot is setting the taxon name as English and Italian label (if not existing), since I feel that taxon name is better than none. Do you think that it should add the taxon name as label also for other languages (es. Spanish)? --Ricordisamoa08:25, 3 May 2013 (UTC)
I agree that it is better than nothing, if a Wikipedia article is inexistent in a particular language. I would guess that the taxon name is a "valid" label for all the languages that use the Latin alphabet, and maybe some more? I have seen it in use on many WPs, including but not limited to "no", "nn", "da", "sv", "fo", "is", "fi", "es", "fr", "de", "nl", "pl" and "pt". And in the (relatively few?) cases where a common name actually exists in a particular language, the label can always be changed later. - Soulkeeper (talk) 18:52, 3 May 2013 (UTC)
How do you set property that have no item set?
I am sure this has been discussed before, how does the community intends to handle for properties that have no item for them. for example, there are some article for people with place of birth that is set to a place that is not an item. Would there be a new data type that would allow for either item and text for value of a property. Even for the date timestamp, some article has exact date for a birth date of a person but some has missing value or just a circa for when a person is born. --Napoleon.tan (talk) 00:48, 4 May 2013 (UTC)
If no item exist for, say, a place of birth, I think that you just create a new item for that place. The date/time datatype does not exist yet, but it is my understandig that you will be to able to indicate the wanted precision of the value. Byrial (talk) 05:36, 4 May 2013 (UTC)
Adding source in JavaScript
Hi everyone, I'm having trouble understanding how to set a reference for a claim. I looked at the manual at "api.php" but I don't understand the "snaks" parameter. Can anyone write an example for me? Assuming that the GUID is known. Thank you --Viscontino (talk) 14:48, 2 May 2013 (UTC)
If you'd like to set "imported from (P143) English Wikipedia (Q328)" as a reference, you should give the following string as the "snaks" parameter: EncodeURIComponent('{"p143":[{"snaktype":"value","property":"p143","datavalue":{"value":{"entity-type":"item","numeric-id":328},"type":"wikibase-entityid"}}]}') --F705i (talk) 14:14, 4 May 2013 (UTC)
It is the URL-encoded form of the following JSON: {"p143":[{"snaktype":"value","property":"p143","datavalue":{"value":{"entity-type":"item","numeric-id":328},"type":"wikibase-entityid"}}]} --F705i (talk) 14:22, 4 May 2013 (UTC)
Hi! I'm translating Help:Label to Catalan and would like to localize the Nutshell template, I have been trying to do it but without success, the template syntax is too complicated for me (after all I'm a translator, not a programmer! ;)). I'd like to import (or link, or embed, or...) to Wikidata an existant template in Catalan Wikipedia, "Plantilla:5 cèntims" what is the Catalan equivalent to "Template:Nutshell". Anyone can help me? Thanks in advance!--Qllach (talk) 07:49, 4 May 2013 (UTC)
Done! Thank you very much for your assistance! However I'd like to know if there's a way to change the image as well, the Catalan translation has nothing to do with a nut! I'd like to use this image. Thanks in advance again!--Qllach (talk) 11:50, 4 May 2013 (UTC)
I agree. It was better if Template:Nutshell itself was translated, instead of the text placed in a subtemplate. Then it would be easy to replace the image in translations – which it isn't with the current model. I will look at it later. Byrial (talk) 12:28, 4 May 2013 (UTC)
I've restored all the edits made by this ip. Though Help:Editing seems to be little outdated. --Stryn (talk) 13:07, 4 May 2013 (UTC)
Date of birth?
As far as I can tell, there is no way to add a 'date of birth' field in the appropriate situations. I would imagine the issue has been raised before. I'm just wondering why this option does not exist (unless it does and I missed it)? AutomaticStrikeout (talk) 14:50, 4 May 2013 (UTC)
Is there any way to link to an item or property so that the text be different, depending on the user language (like in statements)?
For example, the two simplest ways to link are [[Q845715]] (no replacement text) and [[Q845715|Bonson]] (if used on translatable pages, e.g. help pages, the replacement text needs translation. But labels are already translated, which results in double work).
I'm talking about some template, e.g. label: {{label:Q845715}} gives Бонсон/Bonson/Bonsone/...; {{label:P123}} gives издатель/publisher/casa editrice/..., depending on the language set in preferences. A similar template can be for descriptions. --Michgrig (talk) 12:36, 27 April 2013 (UTC)
Also should be an opportunity to write something like {{label:Q845715|ru}} to get Бонсон even if Russian is not the user's interface language. --Base (talk) 12:40, 27 April 2013 (UTC)
I have done an proof of concept on Module talk:User:Snaevar/test. This does come with an cavecat, since it uses an expensive function called mw.title.getContent(title) and there is an 500 expensive parser function count limit on wikidata. Now, are there any users with knowledge on lua (for example lua string functions) and/or regexes that are willing to help finish this module? Or do I need to look for help elsewhere?--Snaevar (talk) 15:07, 2 May 2013 (UTC)
Hi, folks~I believe that this chat page is growing too fast. It's hard to keep track of all discussions, and it's hard to filter them, and it discourages people from discussing subjects older than a few days.
I don't think so large already as to require splitting up into so many pages. Maybe a general discussion page for properties could be split off and everything else could be left at Wikidata:Project chat? --Yair rand (talk) 19:07, 29 April 2013 (UTC)
Oppose (as proposed. I like Yair's idea better.) And in any event, this would be helped by better routine archiving; is there a reason things are being retained for such a long time? Not to disparage NaBUru38's POV, but there must be some length of time after which we can consider a topic well and truly closed. StevenJ81 (talk) 20:22, 29 April 2013 (UTC)
I bumped it from 7 days of no comments to 5. Lets see how well that goes, and then see if subpaging is needed. Legoktm (talk) 02:00, 30 April 2013 (UTC)
Speaking of which, we may have a problem with the archives soon. The March one has 648 kB, and there's a hard limit of just 2 MB. -- Ypnypn (talk) 03:40, 30 April 2013 (UTC)
March and April were special month with a lot of things to manage following the implementations of Wikidata. And since one week I think discussions which need long time started as RfC. Snipre (talk) 08:15, 30 April 2013 (UTC)
Neutral First we need better categories like mentioned. Some of the allready stated go hand in hand and can not get split. Conny (talk) 15:42, 1 May 2013 (UTC).
-1 makes things more confusing and reduces participation. Biggest or longest discussions can be split elsewhere. --Nemo22:01, 2 May 2013 (UTC)
Hi,
Today I found some Ips removes the ensite links without any reason !1 - 2 - 3. may be it should better to limit them for removing langlinks! Yamaha5 (talk) 10:10, 3 May 2013 (UTC)
I created a page for the AACS encryption key but I cannot figure out the class structure. I want to enter in the value of it's hexadecimal representation, but I cannot figure out the appropriate way to do so. I eventually just entered the actual value in as an alias. That doesn't make sense, however, as there are multiple AACS encryption keys and the LITERAL value of the item is '09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0'
Do I ask for a new property or something?
Currently, numbers are not supported as a property data type. Even without that, though, I'm not sure of whether a single item requires its own property.--Jasper Deng (talk) 03:50, 5 May 2013 (UTC)
Property P402 and OpenStreetMap
Hi. I've been looking at the possibility of tighter integration between Wikipedia and OpenStreetMap, and, on finding Property:P402, thought that I had found it. I've now received some quite persuasive arguments at Wikipedia:Wikipedia_talk:WikiProject_Geographical_coordinates#Wikidata.2C_.7B.7Bcoord.7D.7D.2C_and_OpenStreetMap_relations that doing things this way is a really bad idea, and that the addition of Property 402 mappings be stopped now, before it goes any further. I've proposed an alternative, which would be to note the mere fact that a mapping exists for that object at OSM, perhaps including the specific mapping tag used, and then just handing this off to OSM for them to resolve at either the UI or API level. -- The Anome (talk) 10:47, 3 May 2013 (UTC)
The argument being made at the geodata project is that OSM IDs were never intended to be stable, that OSM makes no guarantee that they will ever have any meaning outside of their internal use within OSM, and are sufficiently mutable that having these mappings done in a simple way in Wikidata can be actively harmful. I agree that mappings between OSM and Wikipedia/Wikidata need to be established -- in fact, I'm really interested in contributing to it -- but there needs to be a better way to do it. Can you give an example of the use of OSM IDs in Wikipedia categories? -- The Anome (talk) 14:05, 3 May 2013 (UTC)
I have analyzed all information about items in the last database dump and have complete tables for labels, descriptions, aliases, sitelinks, statements and sources (qualifiers is missing, as they was not yet enabled when the database dump was made). I have made some language statistics and statement statistics available, but be aware that the data is rather old (from April 17).
I want to share the work I have made to extract the data, so please tell if there is something which can be extracted from these data, you want to know, and I will see if I can do it, either with the current data, or with the next database dump. Regards, Byrial (talk) 16:06, 3 May 2013 (UTC)
Another interesting statistic would be "how many items have been edited only by bots, in percentage out of total". --Ricordisamoa23:43, 3 May 2013 (UTC)
It would be, but I have at the moment no intentions of looking at the page history. The amounts of data would be too big for my computer. (It already takes about 3 hours to parse the 13 GB big XML file with the current pages from 2013-04-17, and the next one will probably be much bigger.) I do have plans to do some sorts of consistency checks for the statements (like when some item have some property (for instance about the type of item) then it should or shouldn't have some other property. Ideas for such kinds of checks are welcome. Byrial (talk) 06:07, 4 May 2013 (UTC)
I'd be interested in statistics about item "subjects", in other words a decomposition of all items into (disjoint) groups. I'll sketch a prototype:
10,621,495 items, thereof ...
Wikipedia "service" items
disambiguation items
category items
template items
items on persons
geographical objects
extraterrestrial items (planets, asteroids, etc)
countries
municipalities
items from domain "fauna"
items from domain "flora"
etc. Also of interest would be the number of items for which a "subject type" can not be algorithmically determined. (Through cuntinued refinement of heuritics that number should hopefully be near zero some day.) – brainstorming: A visualization of item class hierarchy as a treemap (Wikipedia) could be insightful (and nice to look at :-) -- Make (talk) 07:00, 4 May 2013 (UTC)
The subclass of and instance of properties should produce interesting an tree, rooted at entity. Those properties are designed to specify a subject's parent (or parents), and thereby create a rooted DAG of knowledge hierarchy for all subjects in Wikidata. Emw (talk) 22:29, 4 May 2013 (UTC)
What computer (in terms of processing power) and what tools do you use for the analysis? -- Make (talk) 06:47, 4 May 2013 (UTC)
Disjoint item groups is a good idea, I think I will work on that.
Computer & tools: I use a pretty standard laptop with 4 GB RAM and a Pentium T4500/2.3GHz processor and Linux. I use a selfmade C99 program which runs though the datadump file linearly while parsing both XML and JSON and inserting data into a MySQL database as found. Afterwards I add indexes to the database and extract statistics by querying it. Byrial (talk) 07:50, 4 May 2013 (UTC)
I would like this function as Property:P345, I mean, that shows a link. (i.e. Q977196) Filmaffinity is in English and Spanish and the links are:
http://www.filmaffinity.com/en/filmXXXXXX.html
http://www.filmaffinity.com/es/filmXXXXXX.html
I don't know if it is possible but I would like the link in Spanish for users who have Spanish as default language in Wikidata and English for other users. --Kizar (talk) 10:57, 4 May 2013 (UTC)
Hello, I checked the FAQ, bay could not find anything mentioned. I realized that when moving pages in Wikipedia, the Wikidata are not updated automatically. I think that this would be a good functionality to add to Wikidata.
If the above text is not clear, here is an example:
OK, it works by bots: [1], reaction time from article move, probably 9:22, then 9:42 (my note here), to 10:09 bot correction. I am not happy with the delay, but at least we all understand that such discrepancies are corrected automatically within one hour and are not staying for ever. I hope that in the future it can be built in and time to be "zero" (you know what I mean, small...). --FocalPoint (talk) 13:55, 5 May 2013 (UTC)
Arab puzzle
We seem to have a serious mix up of the categories about "Arabs" (people), the "Arab world" and the "Arabian Peninsula" in Q7023655 and Q5838665. If someone feels like solving this puzzle.... ;-) Multichill (talk) 21:52, 4 May 2013 (UTC)
sorry for my bad english. There is the Items Brother / Sister. Should we also use this für half-brothers and half-sisters or is there another item? If we have to use this, it should be at the Properties.
I've posted two questions to "Wikidata talk:Languages task force", but something tells me I'm going to wait a while to get a reply there.
The first question (which is also partly within the scope of this somewhat stale discussion) relates to what should be the appropriate item value of parameter P:P31 for items on languages. The second question concerns the property parameters that relate to the the taxonomy of a language.
The time-datatype is not here yet. (If I haven't missed anything.) But are there any solution for the problems relating to different calenders? I know there is lots of confusion in the subject on svwp sometimes. The problem is that the Gregorian calender was introduced at different times in different countries. -- Lavallen (block) 09:19, 5 May 2013 (UTC)
A qualifier can help to solve that. Like for unit in measurement: you specify the original unit (just chack if the system recognize those units) and data users will have to convert them in the appropriate format. In data management I prefer to avoid data manipulation before their storage: if there is an error and it really difficult to detect it without checking in the source. Snipre (talk) 00:48, 6 May 2013 (UTC)
But do we have "units" for this? ("Time i Graubünden") The big problem here is most often that the sources has not taken any care about it, since they have a local point of view. -- Lavallen (block) 04:39, 6 May 2013 (UTC)
Take a closer look: you changed the parameter in the template, not the actually displayed reason outside the template; however, I feel that this "duplication" should be avoided. fixed. --Ricordisamoa23:05, 5 May 2013 (UTC)
No, a property is generally created pretty quickly after there's consensus for it, assuming that the necessary datatype exists. --Yair rand (talk) 03:21, 2 May 2013 (UTC)
That property has a datatype that is not available yet (value). But you're right, there is some creating, sorting and archiving that has to be done on all the property proposal pages. --Tobias1984 (talk) 10:01, 2 May 2013 (UTC)
Without talking about that specific case, I will say that in general properties shouldn't be created unless there is some sort of consensus for them, so a lot of things sit there because there aren't enough people going in and saying "yes, this would be useful" (or "no, this is a bad idea"). Sven ManguardWha?18:13, 2 May 2013 (UTC)
@SvenManguard: In response to your comment I sorted and added templates to all the requests at Wikidata:Property_proposal/Term. I hope this will motivate people (especially those that added the requests) to add more information to the requests, and add their opinion to one or two of the other ones (preferentially those datatypes that are available). --Tobias1984 (talk) 09:41, 6 May 2013 (UTC)
Hi everyone, at the moment we have two ways of using a Commons Category link:
Link from an article to the exact same category on Commons. This is a one on one relationship. So an article has only one Commons Category link and only one article links to a certain Commons Category. This is the strict approach for example in use at the Russian Wikipedia
Link from an article to a more general category on Commons. An article still has one link to Commons, but a Commons Category might have multiple articles linking to it. This loose approach is in use at the English and the Dutch Wikipedia
These two approaches are conflicting. I don't want to have a discussion about which approach is correct, that's up to the Wikipedia's to decide, not us. It's just like Commons offering different images and the Wikipedia's deciding on which image they want to use.
What I do want to discus is how to mark (qualify) these loose links so that Wikipedia's like the Russian Wikipedia's can filter out these links and we can track of them so we can improve them over time. I think this can be done with qualifiers. I was thinking about using main article in category as a qualifier. So for example at Power Mac G4 Cube, a link to Commons:Category:Power Mac G4 is added with qualifier main article in category with a link to Power Mac G4.
Next step would be to use this qualifier on the Russian Wikipedia to not show the link. Is that already possible? Opinions? Multichill (talk) 16:08, 4 May 2013 (UTC)
I'm not even sure why this would be an issue for pedias which always use the most specific link. In every case that I've seen, a particular item only has one commons category associated with it. So for pedias where the most specific link doesn't match the particular item, can't those pedias simply not add a Commons Category template? I'm trying to see why we should make more work for ourselves here when a pedia could just elect not to use the particular template of interest.... --Izno (talk) 18:51, 4 May 2013 (UTC)
Problem is in commonscat and other template implementation: it is different in enwiki and in another wikies. This template shows category name in "Wikimedia Commons has media related to: ..." text in enwiki. But page name is used for this text in ruwiki and another Wikipedias. We can simple insert {{commonscat|Salyut}} to article en:Salyut 1, but we can not insert this form to ru:Салют-1, for this article {{commonscat|Salyut|Салют}} is required. Another problem is infoboxes: link to Commons usually present in ruwiki infoboxes (for example ru:Template:Река). This link requires only exact category, because only page name is displayed as this link name and it can not be overwritten. I suggest solve this problem using two properties: "Commons category" and "General\Similar Commons Categories". — Ivan A. Krestinin (talk) 19:04, 4 May 2013 (UTC)
Why do you say it is different? I am heavily using in now in the English Wikipedia exactly in the same manner I was using it earlier in the Russian Wikipedia, and I do not see any difference.--Ymblanter (talk) 20:47, 4 May 2013 (UTC)
I am sorry for Russian, it is hard for me write in English. Разница в том, что, если не заполнить второй параметр, то в англовики шаблон {{commonscat|Salyut}} будет выглядеть как "Wikimedia Commons has media related to: Salyut", в рувики этот же шаблон будет выглядеть как "Салют 1 на Викискладе", хотя линк указывает не на категорию соответствующую Салют 1, а на категорию Салют. Потому в рувики, дабы не вводить читателя в заблуждение, второй параметр обязателен. В англовики пользуются тем, что имена категорий на Commons названы по-английски. Всё это не так страшно для шаблона commonscat, его можно просто не ставить в статью, если на Wikidata неподходящая категория, всё намного хуже с карточками, там этот линк появляется автоматом, никто этого даже не заметит, и поправить его нельзя, т. к. карточки у нас не позволяют менять имя для линка на Commons. Из категории вроде ru:Категория:Статьи о населённых пунктах без категории на Викискладе статья также исчезнет, хотя реально никакой категории на Викискладе создано не было. Также бардак с нежёсткостью связи между категорией в Commons и предметом статьи делает сложным выявление ошибок, простановку обратных ивик из Commons и прочие задачи автоматизации. В общем нужно разделять категорию соответствующую предмету статьи и категории имеющие некоторое слабодетерменированное отношение к предмету статьи. — Ivan A. Krestinin (talk) 22:09, 4 May 2013 (UTC)
Ну, можно, в конце концов, вообще не показываеть название категории, просто отправлять в неё на Викисклад. И я совершенно уверен, что два года назад в русской Википедии второй параметр не был обязателен или ставился по умолчанию. За тем, что происходило в последние два года я, естественно, не следил. По-моему, это вопрос даже ве второ-, а третьестепенный, существует миллион технических решений его обойти.--Ymblanter (talk) 12:19, 5 May 2013 (UTC)
Вы скорее всего просто внимания не обращали, в обычной ситуации, когда тема категории совпадает с темой статьи, второй параметр не нужен. Речь лишь о той редкой ситуации, когда линк ведёт на нечто имеющее лишь некоторое отношение к теме статьи. А технических решений действительно миллион, главное, чтобы были данные с которыми эти решения будут работать, а их сейчас как раз не хватает... — Ivan A. Krestinin (talk) 15:22, 6 May 2013 (UTC)
"only page name is displayed as this link name and it can not be overwritten." — the ability to do that can be added to the infobox templates as easily as the ability to use data from Wikidata. --AVRS (talk) 21:56, 4 May 2013 (UTC)
The dilemma here seems to be that Commons category is being used to represent both
A) a subject's canonical mapping to Commons and
B) a subject's language-specific mapping to Commons (via {{commonscat}})
In this type of case, the {{commonscat}} on the Dutch Wikipedia is for the category for the subject's parent class. It can be deduced by evaluating the item linked by subclass of, seeing if that item has a 'Commons category' claim, and using that. This approach seems like it could solve a large swath of the loose links.
I agree with Ivan's blanking, at least initially. The Commons category property is the best solution we currently have to specifying the subject's link to Wikimedia Commons (task A), and expanding the role of that property to also include recording a language-specific mapping of the subject to Wikimedia Commons (task B) seems like a violation of the single responsibility principle. It also leaves unanswered how we should record the lack of such a language-specific mapping to Commons. For example, how do we record the the English version of the article in question does not have a {{commonscat}} link to Commons:Category:Power Mac G4? What about more complex cases where, say, three different language versions of an article link to three different Commons categories?
Because of the complexity that added responsibility introduces, my initial impression is that the Commons category property should only map the subject and Commons, not the subject as represented on various different Wikipedias and Commons. Emw (talk) 22:14, 4 May 2013 (UTC)
Agree with Emw. We should only have exact links here. If Wikipedias want to link to more general items, that is fine, if by any chance, we can find a good way to make the Commonscat template default to a more general item, that is great, but inexact links in Wikidata will make things complicated for no clear benefit. Additionnally, there is some work planned to better integrate Commons to Wikidata, and I guess it implies, at the very least to turn the Commonscat property into a sitelink, and that can only work if the category exactly matches the item. --Zolo (talk) 12:34, 5 May 2013 (UTC)
First in the "Table of properties". Clicking "Edit" --> Cannot find section. Uh, why that. Skipping that, would enter it under "Creative Works" -> "Music"
1. Try: Clicking "Edit" nearby the music section itself
- Edit box comes up, start to edit by pressing ENTER. Nothing happen. Wondering why. Pressing SPACE, nothing happen. Pressing DELETE, the site disappears and I'm on the List of properties again. Didn't now why at this time (meanwhile, yeah, DELETE key loads previous page)
2. Try: Same again
- This time I notice, there is some info at the top of the edit box: This page is a translation of the page Wikidata:List of properties/Works. Okay, I understand. Clicking this link. Ah, I see, now I'm on a subpage: Wikidata:List_of_properties/Works. Scrolled down to the music section and click the Edit link again. Hurray, once again "Cannot find section". Stupid me, thinking I could edit this way.
3. Try: First load the "creative work" subpage, then edit the WHOLE page, instead of the secion
- Big list of code, so I've to search the 'music section' first. The there is a lot of code concerning translation stuff I didn't understand
Result after 10minutes: Closing all windows and don't have any effort to enter the new property anymore.
You cannot make a new property simply by listing it there. To create a new property, you need to list your proposal at Wikidata:Property proposal. After a sufficient discussion, a property creator can choose to create or not to create the proposed property.
Anyway, the other problem you are encountering is the fact that this is a multi-language website. People want to be able to translate things, which can cause intense pain for editors in some cases. --Izno (talk) 13:09, 5 May 2013 (UTC)
I think he meant to comment the workings of the list page .. it had gotten quite horribly complicated.
Ricordisamoa did some changes today, so it should be easier again soon. Labels and descriptions are now loaded directly from the properties/items.
Making pages translatable is a bad idea, if it is a page that is changed all the time. It should be reverted. --Goldzahn (talk) 10:18, 6 May 2013 (UTC)
W3C standards for property "domain" and "allowed values"
The 'domain' and 'allowed values' in Template:Property_documentation, which are used in new property proposals, are represented in W3C recommendations for the Semantic Web by rdfs:domain and rdfs:range. What are others' thoughts on establishing "domain" and "range" as the name for those property parameters, and explicitly basing them on those RDFS properties? This should make Wikidata more interoperable with the rest of the Semantic Web. Emw (talk) 17:59, 5 May 2013 (UTC)
It's funny, as I read the post and saw the terms "semantic web" and "W3C recommendations" I already knew it's you who wrote it. It's obviously you're enthusiastic of semantic webs and that's okay. However, the point is: Is Wikidata a semantic web? Or is it 'just a kind of semantic web'? Or only partially a semantic web? At all, should it even be a semantic web or not? So I searched a little bit:
Sure, there are many websites which are bringing both (Wikidata / semantic webs) in context (Google search result) and there is even a semantic web homepage which refers a lot to Wikidata. But only people starts claiming Wikidata is a semantic web, it doesn't mean it is one or it was ever designed to be one. The definition of semantic web is: "a web of data that can be processed directly and indirectly by MACHINES". But here is some other statement, talking about the Wikidata goal "of the work to create a free knowledge base about the world that can be read and edited by HUMANS AND MACHINES". That's the different and I really doubt Wikidata was designed to be a REAL semantic web. It think many users here are participate because it is fun to collect and share data. It's less fun to follow the rulebook of an W3C recommendation. I'm telling neither the recommendations are bad, nor your effort to consider them are bad. Both it's fine. But I doubt Wikidata is right place to force all semantic web recommendations. A good example is our previous discussion about individual properties versus using the global "instance of" property. In my opinion it make sense to use individual properties. Sure not for all cases, but for those we discussed at that time.
Why I'm writing that much? I don't know. I don't want affront you, in no way. And perhaps I'm wrong and Wikidata is or should be a semantic web. I don't know. But it's better to think about this now and perhaps you'll be more happy changing to a real semantic web project than here in Wikidata? However, your comments and inputs are always appreciated. --Nightwish62 (talk) 20:31, 6 May 2013 (UTC)
So the question isn't whether Wikidata is part the Semantic Web -- clearly, it is. The question is how interoperable we want to be with it. I see this proposal to tie properties' "domain" and "allowed values" to rdfs:domain and rdfs:range like proposing that Wikipedia tie [[Image:Foo.jpg]] to <img src="Foo.jpg" />: a basic idea that makes sense. Do you have an opinion on that specific matter? Emw (talk) 02:00, 7 May 2013 (UTC)
Featured items
There's an ongoing discussion at WT:MP where I've proposed a very low-key "featured item" concept. Essentially it would work like this: There would be a semi-protected {{Current featured item}}, where every day or two anyone could add an item that they think showcases Wikidata's strengths. There wouldn't be any voting or room for the nastiness and drama that surrounds such things on Wikipedia; there would just be some simple criteria that featured items should meet (namely the use of all or most applicable properties and decent sourcing). Users would be expected to use common sense and avoid edit-warring, and if we went longer than a few days without a new item being set, that'd be fine too. What do we think about this? — PinkAmpers&(Je vous invite à me parler)21:51, 6 May 2013 (UTC)
I think stop "wikipediaism" in Wikidata - a good dataset about mount Neverrest is worthless when all other mountain Items are rubbish - to show the power, measure the quality of Wikidata and impress People do something like a "query of the day" --FischX (talk) 22:45, 6 May 2013 (UTC)
Amen. A featured item makes no sense and makes even less sense while we're still waiting for basic datatypes. How can we feature an item on a person when we know full well that 100% of newbies will ask "cool, but why not have a statement for date of birth?" And how can we require "decent sourcing" when there's still no agreement on how to source statements? If we want to showcase Wikidata, working on featured queries is a better idea, but an even better idea is to start some sort of task force to seriously think about making this place more attractive to new editors and especially new editors with no knowledge of databases. Pichpich (talk) 02:11, 7 May 2013 (UTC)
Well we need people with knowledge of databases, because that it is ;-) but yes making this place more attractive is important look at http://toolserver.org/~magnus/ts2/reasonator/?q=Q254 from Magnus there is a lot done right, showing Images does it not only make less boring it helps to find errors (trolling with common pictures is now relativly easy) also show some information from relative Items like gender in an easy way looks good and is usefull. --FischX (talk) 10:33, 7 May 2013 (UTC)
But you see what I mean: my grandma (or yours) can fix a typo on Wikipedia but she'll never fix a mistake on Wikidata because it's too technically intimidating. It doesn't have to be that way. Thanks for the link to Magnus' work: it's exactly the kind of improved interface we should strive for. I would note that he includes descriptions in statements, something I wish we'd implement (see three sections below). Pichpich (talk) 12:18, 7 May 2013 (UTC)
Denver
There was some confusion over at the article (or whatever the appropriate term is) for Denver, Iowa, which was mistakenly being represented as the Denver that is capital city of Colorado. I was briefly confused by it, but I believe I have cleaned up the problem. Still, as I'm new to this particular Wiki, I though it wouldn't hurt to get some more experienced eyes to make sure everything is accurate. AutomaticStrikeout02:10, 7 May 2013 (UTC)
For error detection purposes, it would be important to start displaying description (when they exist) when viewing the statements of a particular label. In the thread just above this one, AutomaticStrikeout noted problems with confusing Denver, Iowa and Denver, Colorado. Consider for instance Q184903 (David Fincher). A reader who checks an early version of the item (say this version) will read the statement David Fincher was born in Denver. A reader reading the current version will see an apparently identical statement that he was born in Denver. Yet the value of the statement has changed from Q1933882 (Denver, Iowa where I suspect Fincher never set foot) to q16554 (Denver, Colorado, where Fincher was born). Showing the descriptions would have made it easier for this mistake to be corrected quickly. Some bots have made similar mistakes (for instance by confusing bands with eponymous albums) and displaying descriptions would help humans identify and report bot bugs of this type. Pichpich (talk) 02:27, 7 May 2013 (UTC)
There is a consensus on merging Property:P46 with Property:P6 (and expanding it's scope to "head of any government"), yet nobody's going to make it happen - probably since nobody knows how to do it. Is there some procedure, or at least some tools to do it? Maybe a template to mark one of the properties as deprecated would be quite useful...--Šlomo (talk) 17:47, 7 May 2013 (UTC)
Wikidata doesn't allow the addition of an inexisting page in interwikis. However, there are Categories that only contains interwikis. In order to update the interwikis on Wikidata for renamed categories, I have to make a fake edit to create the page on the Wikipedia and undo it after (since it is impossible to directly create blank pages), that shouldn't be the case in my opinion. See [2]. Is there a possible solution for new pages (I can't think of anything else than categories) that only contains interwikis? In the past, we used to add the interwikis in order to make the category "blue", but now it is impossible. Thanks, Amqui (talk) 22:22, 4 May 2013 (UTC)
Yes, but it can take a lot of time before we know the name of the parent category in the local language. Amqui (talk) 00:39, 8 May 2013 (UTC)
Proposed merges
Should we have a separate page for proposed/requested merges? WD:Interwiki conflicts and WD:Requests for deletion frequently get these kind of requests from people who either do not have the know-how or the time to perform one themselves. It would be good to separate them as distinct from deletion requests (where an item/page needs deleting) and an interwiki conflict (where a conflict actually exists that needs solving). Del♉sion23(talk)23:08, 6 May 2013 (UTC)
I don't think it's a good idea, primarily because a request to merge is really just a request to solve a IC, simply a specific type of and trivially performed. Having only one page for confused and unsure editors (whether something should be merged or whether it is an actual conflict) I also think is preferable. --Izno (talk) 02:08, 7 May 2013 (UTC)
It sometimes happens that an item has different primary names at different time. For example, an old city with long history may have different names in different periods, but the "name" field can have only one value (per language). Aliases also suffer the same issue. Maybe a new property can be created for this: ideally it can be called "Name", used with some time qualifier(s), but the current name is of course a name too, causing some redunctant data ("Name" statement and the built-in "name"/"aliases" field); an "Old name" property may avoid this. However both resolutions need some care when people are changing the "name" field. Any other ideas? Liangent (talk) 14:02, 5 May 2013 (UTC)
Yes, we need something like that. I think we need a multilanguage-datatype to accomplish it. "Statistics Sweden" has an official Swedish name and an official English name. I can see from the archives that both the Swedish name and the English name has changed, and in the 19th century, French was used instead of English. -- Lavallen (block) 14:16, 5 May 2013 (UTC)
I am not sure what you mean an Item can have as many Aliases as you like and the Name field should orient itself on the name of the wikipedia page in this language.--Saehrimnir (talk) 13:25, 8 May 2013 (UTC)
Items with same taxon names
Hi, I made a list of items with the same taxon name from the 2013-05-05 database dump. I don't know the rules for taxon names enough to know when that is allowed, so I would appreciate ideas about how to avoid false positives, and also about how to catch more cases of duplicate items for taxons. Thank you, Byrial (talk) 11:48, 7 May 2013 (UTC)
Items with the same taxon name could be avoided if we had a separate property for synonym(s), but we don't, so I think we may have to mark synonyms with some qualifier (unless we make a property for synonym, of course). But right now, one species can have the correct taxon name A and synonym B, while an item has the correct taxon name B, and that could be considered a false positive. Nice lists, I'll look through them. - Soulkeeper (talk) 07:26, 8 May 2013 (UTC)
Most of these duplications are wild form vs. domesticated form. I'm not a biologist, but isn't there some fancy distinction? —★PοωερZtalk10:34, 8 May 2013 (UTC)
Some domesticated forms are regarded as subspecies and get their own name, like Foo bar domesticus. While other domesticated forms don't get their own taxonomic name. For those, I think it would be sufficient to not use the taxon name property, but instead use the species and/or parent taxon property. - Soulkeeper (talk) 13:07, 8 May 2013 (UTC)
Thanks for taking care of this. It is not possible for me to create the list live, as I have no live access to a database with all statements. In theory it could be updated daily using incremental dumps, but my current programs cannot do this, and I think that it would be too much work for me anyway. But I intend to update when complete database dumps are available, that is with 2 to 3 weeks interval. Regards, Byrial (talk) 14:31, 8 May 2013 (UTC)
Is the oversight bar set too high?
Right now, we have no oversighters. Now, that is likely to change in a matter of hours, but only by a factor one with Rschen7754's promotion. The other oversight requests that were open have all been closed as unsuccessful because the candidates didn't meet the required threshold of numerical support. None of the candidates received much opposition and I would argue that the problem was a lack of !voter participation. Perhaps, in light of that, it would be reasonable to consider lowering the numerical bar a little, maybe to 20 support !votes? AutomaticStrikeout20:44, 7 May 2013 (UTC)
Furthermore, lowering the numerical bar a little is not possible at all. A global policy exists, which says that at least 25 support votes are required for promotion. Additionally, I wouldn't say 25 is very much. As well our admin reconfirmations as our bureaucrat elections had mostly over 30 support votes. I guess, the lack of participation is caused by a lack of interest in having a local oversight team by the community. Regards, Vogonetalk21:02, 7 May 2013 (UTC)
You keep repeating that, but considering your public statements on the matter of Oversighters, you might just be perceiving that because it matches your own views. As much as I, as a candidate, don't want to admit it, I think that a much more plausible scenario is that the list of candidates did not excite/appeal. Sven ManguardWha?21:14, 7 May 2013 (UTC)
I see at least 6 OS-actions and 10 CU-actions from Stewards within a month. Therefor I think we should have such user-rights locally as soon as we can summon enough support for such RfP's. But it's obvious that we are not there yet. -- Lavallen (block) 06:11, 8 May 2013 (UTC)
I'm seeing a lot of editors accidentally logging out and then having their edits revdel-ed. They are actually supposed to be suppressed upon request from the original editor, but are currently being revdel-ed by random admins. Perhaps we should be handling this differently? --Rschen775422:25, 7 May 2013 (UTC)
In my opinion, revdel by default is sufficient. If the user wishes further action for some reason, it should be up to him to contact a steward or, if we get a local OS team, the local oversighters. Regards, Vogonetalk18:08, 8 May 2013 (UTC)
In my opinion, the RfOS's with 20 (Sven Manguard and Courcelles) should've been extended, as both had chances of passing. However, we cannot override the global policy here, and we have to make do with that.--Jasper Deng (talk) 06:20, 8 May 2013 (UTC)
Sometimes, interwiki links go to topics which are almost identical, but not completely. For example, Q51638 has some links to articles about the ascension itself, while some links go to articles about the day on which the ascension is celebrated, and some articles describe both things. Also, English Wikipedia has separate articles about both things: w:en:Ascension of Jesus (has all interwiki links) and w:en:Feast of the Ascension (has no interwiki links). How do you clean up a mess like this? --Stefan2 (talk) 20:22, 5 May 2013 (UTC)
When we were still in the old system (local interwiki's) these kind of articles were always in a state of conflict. I think we end up with different items for the specific meanings and some languages will not be linked. Multichill (talk) 10:45, 9 May 2013 (UTC)
Open Source repository for bot software
How about an Open Source repository for all bot programs and scripts developed for Wikidata? Where could we create it? --Ricordisamoa22:31, 7 May 2013 (UTC)
I knew it, of course! But is there any chance to get a script added to the main repository, or at least as a plug-in? --Ricordisamoa10:47, 9 May 2013 (UTC)
Generic property for power source
There is a property proposal for the "power source" of satellites. I think this property could actually be applied to a lot more items. Would be nice to have some more oppinions: power source. --Tobias1984 (talk) 06:47, 8 May 2013 (UTC)
Hi everyone (and especially the people who are interested in bots), I published and documented two scripts to mass add claims using Pywikipedia (rewrite):
claimit.py: A script to mass add Wikidata claims to a lot of items based on pages on Wikipedia
harvest_template.py: A script to mass add Wikidata claims based on information harvested from Wikipedia templates.
Both are still a bit rough, but work. Running them is quite easy and sure much easier than having to code these kind of bots yourself! Have fun. Multichill (talk) 18:43, 9 May 2013 (UTC)
I've recently experimented with Lua and created Module:RFBOT to quickly get a list of RFBOTs by username (in either long or short form).
It is intended to be used in {{LOB}}, in place of that ugly sequence of switches. At the moment it "only" supports up to 500 RFBOTs (if you know how to loop infinitely, let me know) – much better than 15, though! (I often had to increment it to support my SamoaBot with 45 current requests).
PS: I used getContent() ~= nil to check if a page exists. Do you know a better (and maybe less expensive) technique? --Ricordisamoa16:05, 9 May 2013 (UTC)
"Novalue" snaktype in place of "placeholder images"
As part of its Task 15, SamoaBot is replacing some "placeholder images" as Flag of None.svg with the "novalue" snakType. Is "novalue" suitable and ideal for this purpose? Or should I use "somevalue"? Or maybe completely remove the claim? --Ricordisamoa21:06, 10 May 2013 (UTC)
For me "somevalue" is better. It means that an image should exist, but at the moment we haven't it. --β16 - (talk) 21:42, 10 May 2013 (UTC)
If the item has a flag, but we do not have it yet, add "somevalue". If there is no flag for the item, add "novalue". If you do not know, remove the property. -- Lavallen (block) 11:27, 11 May 2013 (UTC)
I have removed a lot of files with coa in items who has a coa on some projects, but shouldn't have. I would love to add "novalue" in those, but the interface isn't the most helpful in this matter sometimes. -- Lavallen (block) 11:27, 11 May 2013 (UTC)
How can you add new property to the property list?
As agreed before for proposing property, once a property is unanimously approved, you can create a property now. I noticed that I do not have authority to add a new property in the special page Wikidata:List_of_properties so even if I created a property, how do I describe it?
As a second question, sometimes proposed property only get notice once and get commented once, can I promote the proposed property in the chat? or since it was not disagreed by anyone and just agreed by one or few member, does it mean it is unanimously approved?
Lastly, I noticed the list of property has a script error in them. I think it has something to do with using a ref tag. Anyway, since I do not have authority to edit it, just want to shout it out to those who can fix it.
--Napoleon.tan (talk) 04:24, 11 May 2013 (UTC)
First: How works the 'status' field at the top of the proposal box? I'd like to change the status of Wikidata:Property_proposal/Person#Assocciation_Football_Player_Height_.28en.29 to something other than "in progress", as the proposal creator itself rejected the proposal. However, I don't know how this works at the only I can see in the wikicode is: "< !-- leave this empty -->"
What is the meaning of the background color? Some are gray, others are blue, but I can't figure out what's the system of this coloring.
About the colors: background is gray when data type is planned, but not yet available (samples: date/time, number/quantity). In all other cases it's blue. -- Docu at 10:01, 11 May 2013 (UTC)
Thanks for your answer and adding the information to the template documentation. However, I'm just wondering how many users/editors are aware about this. Also: Not all have the knowledge to find this template documentation. What do you think about to indicate it in some other way, more clearly for the users? --Nightwish62 (talk) 10:14, 11 May 2013 (UTC)
If the chosen datatype isn't available, this is also displayed next to it. The color is mainly of use for property creators who can (or can't create) a property. For commenting on a proposal, it doesn't matter that much. -- Docu at 10:21, 11 May 2013 (UTC)
Big problem with wikidata and wikipedia! (missed interwikis)
I came across with many pages which are built in wikipedia and for interwiki the creator directly added them to wikidata's items. now some of them doesn't have interwiki!
how can I find their last item? (now they are removed from item and don't have any item) and it is not possible to searching inside wikidata histories!
how can I find their previous item (now it has incorrect item! and it is not clear what was their last interwiki)
these two issue are very impotent because users can not trace interwiki changes in wikipedia history! Yamaha5 (talk) 11:10, 11 May 2013 (UTC)
i want to create wikimedia project with videos anyone can help me – The preceding unsigned comment was added byAkuthotasridhar (talk • contribs) at 10:38, May 11, 2013 (UTC).
Could this be a qualifier for the GND type? If "GND type = person" a qualifier could say "Fictional = no, yes, disputed"? We probably would need a "disputed" option because if it is Boolean then some people are going to add things like "Moses & Fictional = yes or no" and the advocates of either option are going to be at each others throats ;) --Tobias1984 (talk) 16:55, 2 May 2013 (UTC)
Agree with the "is fictional" boolean, but I do not see the use of the "is fictional instance of", I think it is way clearer to just have one property to express fictionality.
I do not think GND type should take qualifiers, as it is an externally defined controlled vocabulary (yes, it arguably runs counter to the whole Wikidata structure, but then, let's just not use it....). --Zolo (talk) 17:13, 2 May 2013 (UTC)
Do not use the GND type for this. Period. It has enough issues as is that have been pontificated at length elsewhere.
This issue comes up occasionally. A boolean would be nice but probably isn't in the near term. For fictional characters, we're probably okay. It's fictional other things that we look like we have an issue with. --Izno (talk) 17:27, 2 May 2013 (UTC)
I do believe that marking things as fictional is going to be important, and I think it needs to be a property. I think that we're going to have some conflicts over it (not only religious topics but also things like extraterrestrial life), but a few problem areas shouldn't stop us from making a property for this. Sven ManguardWha?18:11, 2 May 2013 (UTC)
It at least needs to be a qualifier. I'm not sure a property is necessary, but that comes down to a detailed discussion of this. --Izno (talk) 19:38, 2 May 2013 (UTC)
I am fairly sure I had read about a boolean datatype somewhere, or is it just bug in my brain ?
There will surely disagreements over the fictionality of a few things, but we can have several contradictory statements (source A claims that Jesus is fictional, source B that he is not). That works more clearly with a boolean datatype though. --Zolo (talk) 20:08, 2 May 2013 (UTC)
If we have a is-fictional property, I think it should only be true for things which are be definition fictional. Examples: Sherlock Holmes, Enterprise, and so on. Something which is proven to not have existed, such as phlogiston, w:Flat Earth, and so on, aren't fictional – they're false. There's a big difference between an supposed empire that was proven archaeologically not to have existed, and an empire in a movie. -- Ypnypn (talk) 23:59, 2 May 2013 (UTC)
Dealing with flat earth is nothing. Wait until we start discussing the boolean fiction flag on Moses or Noah's Ark... Pichpich (talk) 02:16, 3 May 2013 (UTC)
Then a guideline to mark them as religious characters or events should be possible and a lot less controversial. TomT0m (talk) 19:39, 5 May 2013 (UTC)
I don't see how. Moses is a prophet and Benedict is a pope, making them religious, but the controversial issue is whether Moses existed, and therefore whether he is a person. The same will be true of Homer. --Jfhutson (talk) 19:57, 5 May 2013 (UTC)
I think that what TomT0m meant by "religious" meant: believing in its existence is a matter of religious belief. But I do not think it really works.
Assume the following claims are correct (and by and large I think they are):
Historians all agree that Muhammad existed
The existence of Jesus is debated among historians.
No historical evidence suggests that Moses existed
I think the value for "is fictional" for Muhammad is then "False", that for Jesus is "True <source A, B> "False <source B, C> and that for Moses, well not so sure, but same as Jesus I think. --Zolo (talk) 20:23, 5 May 2013 (UTC)
"The Ringworld is an astronomical object and there is no mention of the fact that it is a fictional one." - come on, what a bullshit is this? It is pretty obviously not an astronomical object in the meaning of the property as it will be used in 99 % of the items. Should Wikidata be a serious database or a crude mixture of real facts and fictional stuff using the same properties?!--D.W. (talk) 20:21, 3 May 2013 (UTC)
It is pretty obviously both a fictional object and an astronomical object.
The opinion here seems to be that yes, the properties "should be mixed", primarily because it becomes an overhead nightmare to maintain two separate sets of properties. An "is fictional" boolean would fix the problem, but until that is an available option, users should add the appropriate properties. (And not revert others.) --Izno (talk) 20:44, 6 May 2013 (UTC)
Serious, it becomes a nightmare to have special properties, but it is OK to add an extra "is fictional/is not" to every item? If you do any programming/listing you then always need to add an extra request to avoid that your listing of organizations with headquarter in San Fransisco will also list Star Trek Starfleet, or a list of space vehicles consisting mostly of science fiction space ships..but I see that Wikidata is already full of stupidity - Worf´s nationality is united federation of planets and klingon empire...I better stop to read and work here, if its ruled by childish people sorting their favorite tv show characters in every detail..--D.W. (talk) 17:25, 7 May 2013 (UTC)
Are we talking about properties or items? It doesn't seem like we need two sets of properties, but two sets of items (as mentioned above, we already have fictional location, fictional city, fictional country, fictional universe). That seems like much less a nightmare than adding an extra property (is fictional) to every single item. They seem to be fundamentally different sorts of things than their respective real things, though perhaps each should be linked to its real thing by a property like "is a fictional representation of". I'd be much more likely to describe Sherlock Holmes as a character than simply as a detective. --Jfhutson (talk) 18:31, 7 May 2013 (UTC)
I read this discussion and I'm agree with Jfhutson (and D.W.). Imho it is more simple use a correct set of items, as proposed by Jfhutson, instead of manage another general property that could complicate queries, as D.W. noted. --Paperoastro (talk) 19:41, 7 May 2013 (UTC)
I agree that this is an important Topic and should be decided by the Community quiet quickly before it gets out of hand but I think making a property is fictional which is by default false would be an good option thus it only has to be added to the fictional things. But I could also live with Excalibur is instance of fictional sword.--Saehrimnir (talk) 11:27, 8 May 2013 (UTC)
I see in this discussion basically 3 proposed ways for marking fictional stuff:
1: Metropolis – Property: fictional instance of, value: city
Comment: I prefer this way. It is simple, correct, and doesn't need new items.
This makes the most sense to me. The item is linked to the real thing without being called an actual instance of it. This seems like the most correct way of describing a fictional thing. --Jfhutson (talk) 14:04, 8 May 2013 (UTC)
2: Metropolis – Property: instance of, value: fictional city
Comment: Could be used, but you will have to (unnecessarily) create new items for everything which can have fictional instances.
Comment: I do not like this because a fictional city is in my opinion not a city, so I think that would be a false claim. The claim should be valid even if you don't take the qualifier into account. (The qualifier gives the conditions for the claim, not shouldn't make something false become true).
This Proposal was also like: Metropolis – Property: instance of, value: city, Property: is_fictional, value: true but for this your argument is also valid.--Saehrimnir (talk) 13:05, 8 May 2013 (UTC)
Comment: More complicated than #1, but can also be used with other properties as qualifiers, such as "subclass of" and others. Byrial (talk) 12:26, 8 May 2013 (UTC)
the forth approach is especially interesting since it would allow us to add fictional claims also to a non-fictional entity... Metropolis is an Idea of something that is a city. I could live with all these proposals (instead of just blindly delete anything, related to fiction) --Shisma (talk) 13:38, 8 May 2013 (UTC)
I don't know what you mean with "add fictional claims also to a non-fictional entity", maybe an example would help. If we create the property "is fictional", I think it should be used for and only for fictional items. But you could possibly use many qualifiers at once along with instance of, for the fictive population, country, mayor and so on. Byrial (talk) 14:11, 8 May 2013 (UTC)
So there will be no boolean datatype. I still think that "is fictional" is by far the simplest and most flexible solution. "Is fictional instance" sounds sort of ok too, but it is less flexible, for example when the fictionality is disputed. Also a fictional item can have exactly the same properties as a non-fictional item, the only difference is that it does not exist. So really a separate "is fictional" property sounds the most logical solution to me. I think I would support emulating a boolean datatype with dedicated items for "True" and "False" (and possibly allowing a few other values like "disputed"). --Zolo (talk) 15:56, 8 May 2013 (UTC)
As noted above, there's no problem with disputed cases because you can have sources for competing claims. So Moses is a fictional instance of a prophet according to the four sources given in the fourth para of en:Moses#Historicity, and is an instance of a prophet according to the source at the end of the section. I'm assuming this model is going to be used for all kinds of disputed claims (only disputed by RSes) that are much less significant (date of birth, etc.). --Jfhutson (talk) 16:12, 8 May 2013 (UTC)
There is no problem with having several values in a "is fictional" property, but I do not think having something being both a person and a fictional instance of person is really clear (if I saw that about a subject I didn't know about, it would rather look like an error by someone who did not know about the "fictional instance" property). But it has other problems too: it does not allow values like "unknown" (if a single source states that the existence of something is not known). And it is not just about disputed claims. This is also what has been referred above as "fictional claims also to a non-fictional entity". For instance, if a myhth states that a city was founded by some guy, I think it would make sense to have: "Founder: Some guy (fictional: True)". --Zolo (talk) 06:17, 9 May 2013 (UTC)
OK, I suppose you could have Founder: some guy (source:some myth), but that's stretching what I was assuming the purpose of sources would be, and I guess being the founder of a mythical city is fundamentally different from being the actual founder of a city. I can see how this problem makes #4 more appealing. --Jfhutson (talk) 14:24, 9 May 2013 (UTC)
I don't know these templates. Which sense do they have? And is this a proposal to force people to use it? If yes, then I'd oppose, if users and admins can decide whether to use it or not, and the templates are just an extra, then I do not see any problems with the change. Regards, Vogonetalk14:51, 8 May 2013 (UTC)
@Jasper Deng: Didn't you just recently suggest that yourself, Rschen7754 and PinkAmpersand should "stop bickering about each others' actions" ? ;)--Snaevar (talk) 16:28, 8 May 2013 (UTC)
The fundamental thing that needs to happen is that people need to be checking the category for requests though... otherwise it's useless. --Rschen775422:34, 10 May 2013 (UTC)
This would be useful, if someone checks the usage. I had to use this template too, when somebody blocked NAT IP with autoblock... JAn Dudík (talk) 12:10, 13 May 2013 (UTC)
AB, RB und PTC
Would it not be more simple if the Autopatroll-right was included in the groups of Rollbackers and Property creators? Now I am in three user-groups, and it looks a little strange to me to wear so many hats in one single project. I do not propose to remove the Autopatroll-group, but to make it redundant if you are in one of the other two. Just like all of these are redundant if you are a sysop. -- Lavallen (block) 19:02, 11 May 2013 (UTC)
I would strongly support that (and already did that when the user groups were created) but there's a strong enwiki majority which seems comfortable with having several seperated flags. Regards, Vogonetalk19:23, 11 May 2013 (UTC)
Support for me, I think we have in general to many rights here which must be asign manually. I would support an easier system with Autopatroller (includes confirmed, automatic after some edits) than Rollbacker (after some more edits). The property creator property I would delete because we have enough Admins here. I also see like Vogone no need for local Oversighters. We have a lot of administration here, we don't really need I think. --Pyfisch (talk) 20:05, 11 May 2013 (UTC)
Property creator was created specifically because the community thought it would be good to have a set of users separate from the administrators able to make properties. That's probably not going to change in the near future. --Izno (talk) 20:10, 11 May 2013 (UTC)
I prefer to see rights assigned separately from one another myself and don't feel the need to "merge" certain user rights here. Whether it's 2 hats or 3 hats, it's still the same permissions, and this way, the permissions set on a person are clear. /me shrugs --Izno (talk) 20:10, 11 May 2013 (UTC)
I'm under the impression that if this was passed, one would have to get either the rollback right or the property creator right in order to be autopatrolled. If that is the case, it could create a problem of having too many unpatrolled edits. AutomaticStrikeout22:10, 11 May 2013 (UTC)
Support including the "autopatroller" flag in the "rollbacker" and "propertycreator" user groups. Not propertycreator in rollbacker, nor rollbacker in propertycreator or propertycreator in autopatroller, of course! --Ricordisamoa23:08, 11 May 2013 (UTC)
Sure, let's merge autopatroller into RBK and PTC (while of course maintaining a separate autopatroller group). While we're at it, why not merge (auto)confirmed into autopatroller like I suggested ages ago? (Also while maintaining a separate group.) — PinkAmpers&(Je vous invite à me parler)15:36, 13 May 2013 (UTC)
Support adding autopatrolled to rollbacker and property creator. Definitely keep autopatroller as a separate right, though, because most users are not rollbackers and/or property creators. I also Support merging confirmed into autopatroller since all autopatrollers should be (auto)confirmed. The Anonymouse (talk | contribs) 15:47, 13 May 2013 (UTC)
Hello, I think it's not a good idea to use Wikipedia as source. This gives false security, one can think on the first view, the property is well sourced, but this isn't the case. For example: Berlin has italian wikipedia as source for zipcode, that is really grotesque, I would expect something else more reliable, f.e. Deutsche Post.--Sinuhe20 (talk) 19:14, 12 May 2013 (UTC)
It is "imported from", not "this is source". We agree with you, we're just not quite the best way how to do it yet. --Izno (talk) 19:36, 12 May 2013 (UTC)
Actually most people will see "source" and will only see "imported from Wikipedia" only after they click on the word source. I also believe this makes Wikidata look bad even although we're fully aware of (and all agree on) the fact that Wikipedia shouldn't be used as a source and the fact that the current solution of at least tracking the origin of the imports is better than nothing. Pichpich (talk) 03:18, 13 May 2013 (UTC)
Why is it important to know, where unsourced data is imported from? Actually, data having no other reliable source shouldn't be imported from Wikipedia.--Sinuhe20 (talk) 09:58, 13 May 2013 (UTC)
It helps us to identify which sources are unreliable, and by that to track other mistakes in the import of information. -- Lavallen (block) 11:07, 13 May 2013 (UTC)
That sounds illogical for me. If the named source is trustworthy enough, no "imported from" is needed. If it is not, it shouldn't be imported anyway. I think it is time to write a bot, removing such unclear information, otherwise wikidata will be flooded with more and more "data rubbish".--Sinuhe20 (talk) 12:24, 13 May 2013 (UTC)
for this item, and the not artikkel is true. What is the reason, and is there an action I can take in the script to avoid problems like this. For those who might be interested - I'm trying to compare the value of p41 with what we have in our infobox, and put our article in a category based on the result. This works for thousands of articles, but not for this one. Haros (talk) 04:24, 13 May 2013 (UTC)
Seems like something weird is going on, as mw.wikibase.getEntity() should return a table structure but instead returns a nil. I think this could be an indication of a bug in the libray, or some supporting code, or the database. Jeblad (talk) 14:45, 13 May 2013 (UTC)
maybe two imported from Wikimedia project for one source
Often the source for a claim is "imported from Wikimedia project" with a languageversion of wikipedia. But most time, it's not clear from which page, category or template the statement is taken. Wouldn't it be better to add one source with two properties, the "imported from Wikimedia project" with the category/template/etc. from which the statement was imported, and a "imported from Wikimedia project" with the languageversion from which the category/etc. is taken? this would make the info replicable at least. I made a example of this for Arnold Schwarzeneggersoccupation: actor.--CENNOXX (talk) 22:40, 11 May 2013 (UTC)
Well, imported from really should go away at some point. It's a temporary property for use until we can add real sources in a sensible fashion. --Izno (talk) 23:01, 11 May 2013 (UTC)
Yes, I do not think "imported from" will ever be used in the Client. It can be used here to track where something went wrong. -- Lavallen (block) 06:49, 12 May 2013 (UTC)
In general these items were imported from the Wikipedia page linked to in the sitelinks by a bot. If a human were importing such info then I hope he or she would also import proper source info from the source Wikipedia page Filceolaire (talk) 20:17, 13 May 2013 (UTC)
Different kind of articles in the same item
I see our robots adds a lot of information now, but I see some problems, Here Legobot adds P360 (list of) persons, with source "enwp". That is a correct for enwp. The enwp-article is to it's content a list of governors of a former county in Sweden. But there is a special item for "list of governor in Malmöhus County". You will find it in Q10553879. But it only exist on svwp.
Another thing is that P94 (file with COA) has been added to items about urban areas in Sweden. But Swedish urban areas never have a Coa. Cities and Municipalities often has a Coat of arms but never an urban area. But most projects has merged the article about the City of X and the article of Urban area of X. I think svwp is the only project who has separate articles for each of these subjects. There is today only missing articles for a special kind of citys: "Municipalsamhällen", who are the smallest of all kinds of cities in Sweden. But a project on svwp is working on creating separate articles for them to.
The list of property should be as specific as possible. If all linked articles of this item are lists of Q10553879 then link the specific one. And if a bot adds a less specific again, inform the owner of the bot.
Either, like in the discussion below by creating 3 types of items (a,b,a&b) or, as I would prefer in this case, by being specific and creating 2 items, one for the city and one for the urban area. You know your local administrative units best. The foreign wikis should then adapt. :-) 80.187.104.20519:57, 13 May 2013 (UTC)
Wikidata:Requests for comment/A need for a resolution regarding article moves and redirects is discussing allowing links to redirect pages to help in just such cases as this. In most cases, where a wikipedia has one page covering both Urban area X and City of X there will also be a redirect page for City of X. The Wikidata page for City of X can then link to the redirect page in those cases where a separate page for City of X does not exist. If you think this is a good idea then go and comment on the RFC. Filceolaire (talk) 20:43, 13 May 2013 (UTC)
Unable to create new item
I searched for "peach tree" and was told that it did not exist. Then I tried to create a new item and was told that the new item could not be created because it already existed. I don't understand. Can anyone help? ChriKo (talk) 22:31, 12 May 2013 (UTC)
If your language has separate articles for the fruit and the tree and we have one entry for both then I'm not sure what we do. Secretlondon (talk) 13:09, 13 May 2013 (UTC)
In this special case of fruits and their plants it is nearly always the case that you have A) articles with plants and a section regarding their fruits, B) A plus an extra article regarding the fruit and C) only regarding the fruits. Then, link first all A) articles which explain the plants. the remaining ones are then only about the fruit. 80.187.104.20520:05, 13 May 2013 (UTC)
Wikidata:Requests for comment/A need for a resolution regarding article moves and redirects is discussing allowing links to redirect pages to help in just such cases as this. In most cases, where a wikipedia has one page covering the fruit and the tree there will be a redirect page for the fruit. The Wikidata page for fruit can then link to the redirect page in those cases where a separate page for the fruit does not exist. If you think this is a good idea then go and comment on the RFC. Filceolaire (talk) 20:46, 13 May 2013 (UTC)
Properties and qualifiers
Technically, (correct me if I am wrong) properties and qualifiers are the same thing. This means that some pages intended as qualifiers can be inserted as properties and vice versa. For example, the recently approved academic degree property, according to its proposal discussion, is used in conjunction with alma mater, with alma mater as a qualifier of academic degree. However, this proposal was not commented on. I would like to propose a way to distinguish the two, or at least provide an consensus-based indication of which P:XXX are properties and which ones are qualifiers. If possible, I would also like to see the software to automatically recommend qualifiers upon inserting a property into an item. Any comments? --Wylve (talk) 08:58, 13 May 2013 (UTC)
Properties and qualifiers are not the same. However what you may mean is that properties are used in the same way in claims and in qualifiers, and BTW also in the same way in sources. It is logical to me to use "alma mater" as qualifier for "academic degree" so you can specify at what university or school the degree was achieved. That can be useful if a person have several degrees from different schools. (Technicaly you could also use "academic degree" as a qualifier for "alma mater", but I would find that strange as I consider the degree the most important part). But I am not sure what is it you want to distinguish regarding those two? Byrial (talk) 11:36, 13 May 2013 (UTC)
I still don't really understand qualifiers. It seems that the only thing that can go in a qualifier is a property, there is no free text annotation, or anything else. The qualifiers I would like to add are things that doesn't exist any more but used to. X had an instance of Y, but doesn't any more. I suppose that would require dates. Free text would at least give me something to play with... none of the existing properties allow me to qualify any of my statements the way I want to. Secretlondon (talk) 13:06, 13 May 2013 (UTC)
Each property takes a value of a certain datatype. The current datatypes is item, string and Commons media. Date/time, quantity/number, monolingual and multiligual texts are planned (and maybe more?) The datatype of a property is fixed and cannot be changed and is independent of if the property is used in a claim, a qualifier or a source. You cannot have a qualifier to indicate when something happened before it is possible create properties with the date/time datatype, so that is what we are waiting for. Byrial (talk) 13:36, 13 May 2013 (UTC)
Yes. Qualifiers are Properties used in a special way. I'm sure there are (or will be) some Properties which can be used either way and I don't see this as a problem. Notes on how a Property is to be used go on the Property page and for the Property:alma mater property I agree that it should note that it is generally used as a qualifier to the Property:academic degree. Likewise the page for Property:academic degree can have a note that it generally uses Property:alma mater as a qualifier. Filceolaire (talk) 20:58, 13 May 2013 (UTC)
Full text search not working correctly for some terms
If I enter "Röntgendenkmal" in the search field, the AJAX dropdown suggests two entries (Q2202687 and Q2202689). But if I actually perform a search for this term, there are no results. Other searches, like for "Röntgen", seem to be working normally. So what's wrong with my search? --YMS (talk) 11:18, 13 May 2013 (UTC)
I have this problem all the time - even when I specifically use Search by Item. Sometimes to find what I'm looking for I have to try and add the sitelink to another item so that the WD software can tell me it is already in use, and give me the Q number... QuiteUnusual (talk) 11:22, 13 May 2013 (UTC)
Hi. I have a question. After I request deletion for a page, do I have to mark it as patrolled? Thanks in advance. --LlamaAl (talk) 00:03, 14 May 2013 (UTC)
Should we add email notices to Wikidata? Users would be able to create a notice (at Special:MyPage/Emailnotice) that is displayed when someone uses the form to email them. The English Wikipedia has this; I use it to give the user some information about my emailing practices, etc. To change this, someone would have to replace MediaWiki:Emailpagetext with the following code:
You can use the form below to send an email message to this {{GENDER:$1|user}}.
The email address you entered in [[Special:Preferences|your user preferences]] will appear as the "From" address of the email, so the recipient will be able to reply directly to you.
{{#ifexist:User:{{#titleparts:{{FULLPAGENAME}}|1|2}}/Emailnotice
|{{User:{{#titleparts:{{FULLPAGENAME}}|1|2}}/Emailnotice}}
}}
1) I see no need. If anyone has some message to people e-mailing them, they could write it on their user page. 2) I don't like the idea that something from userspace is transcluded into a user interface message. I see a potentiel for abuse. 3) It would only work if the e-mail sender happens to use English interface (unless you care to alter MediaWiki:Emailpagetext for all supported langauges). Byrial (talk) 05:27, 14 May 2013 (UTC)
We have had a rollback removal requests, but in regards to administrators and above, I suppose it may be worth doing so we hopefully we are a long way away from needing such request publicity. John F. Lewis (talk) 15:07, 14 May 2013 (UTC)
Yes, hopefully it won't happen for a while. Wikidata is about ten years behind enwiki and that is a good thing. It's much less drama-filled. AutomaticStrikeout15:36, 14 May 2013 (UTC)
I am interested in finding duplicate items in gu and en wikipedias and merge them. How can I find items with only GU (gujarati) interwiki link so I can find appropriate english wiki item and merge it?--Nizil Shah (talk) 23:47, 13 May 2013 (UTC)
I made a list for you at User:Byrial/Items with only Gujarati link with items which only links to Gujarati and no other languages from the last database dump. There is more than 19,000 such items, which too many to list on one page, so the list is limited 1,000 items. Please tell if I should limit or sort the list in a specific way. I can also e-mail the complete list to you if you are interested. Regards, Byrial (talk) 01:11, 14 May 2013 (UTC)
Thanks for prompt reply. Can you short list by excluding items with description:"village in Gujarat state, India" (gu wikipedia have 15800 articles on villages which have same description added by bots and my priorities are merging other items before them, I will take care of those villages after availability of Merge tool.) Email me list excluding villages. regards,--Nizil Shah (talk) 10:38, 14 May 2013 (UTC)
I excluded items with English description "village in Gujarat state, India" from the list, and only show Gujarati label if it is different from the link text. The resulting list have 3,838 items and is not that much bigger than the previous list with 1,000 items, so I updated the page with the complete list, and didn't e-mail you. I hope that is satisfactory. Regards, Byrial (talk) 13:21, 14 May 2013 (UTC)
Thanks a lot..you remove so much burden of finding article with only single gu wikilink. Cheers again. Can you further cut down list by removing items which are deleted (shown as a red link in a list), not necessary but may help understand how much work is pending? :D --Nizil Shah (talk) 19:35, 14 May 2013 (UTC)
You are welcome. It is not so easy to remove items which have been deleted from the list, as it is made from the data found in the last public database dump from May 5. and I have not at the moment access to newer data. It might be possible to find a solution (using the toolserver database), but I will need some time to do that. Byrial (talk) 23:28, 14 May 2013 (UTC)
Looks like a new deletion interface, with buttons for merging items and deleting them. Obviously, this isn't working yet, but I like the concept. FrigidNinja02:32, 14 May 2013 (UTC)
Oh, ok. As an aside, is there any currently usable tool here that has the information contained on that page (i.e. # of sitelinks, claims, labels, descriptions)? AutomaticStrikeout02:35, 14 May 2013 (UTC)
Great idea! You can see if an item really is empty before deleting. Suggestions: 1) Have you access to WhatLinksHere from a Lua module? If so, you can also count incoming links from the item namespace. 2) It could also check aliases. In the May 5 database dump I found 90,109 cases where there is one or more aliases for a language, but no label for the language. (It seems that Sk!dbot have or had a habit of doing that). Byrial (talk) 05:39, 14 May 2013 (UTC)
1) I was just thinking of getting "WhatLinksHere", but the documentation doesn't help. 2) Done aliases! Thanks for helping, --Ricordisamoa05:48, 14 May 2013 (UTC)
[3] is this what you wanted to point at in your link? Can sombody asses how it works? @Ricordisamoa your Gadged looks good.--Saehrimnir (talk) 17:12, 14 May 2013 (UTC)
It looks like Ricordisamoa have designed user interface so I pointed to script.. :) I am eagerly waiting for merge tool.--Nizil Shah (talk) 21:38, 14 May 2013 (UTC)
Property Versions
It has been requested for several time that property P348 'stable Version' should be generalized, I've created a proposal for this here. Please comment (there), so that we can hopefully do this quickly. -- MichaelSchoenitzer (talk) 22:25, 14 May 2013 (UTC)
Help for small translation
Just go here [4] and translate just one description line in languages you know. It will take few seconds and help us a lot. Thanks.--Nizil Shah (talk) 22:39, 14 May 2013 (UTC)
Do not blindly copy the template with its name, it is not perfect; for example, properties which are to be used as labels appear as "q12345" when there is no label in the language — and there is no link. --AVRS (talk) 11:28, 13 May 2013 (UTC)
Thanks, HenkvD. Now the template returns text only if there is a label, and makes the text a link (only if it will be blue). As for the name, I thought it might be too general for the template. --AVRS (talk) 15:06, 15 May 2013 (UTC)
I think it should best be short otherwise the infobox templates with a large number of Wikidata properties will become even more unreadble. That is why I initially choose the name Template:Wikidata. HenkvD (talk) 17:53, 15 May 2013 (UTC)
Chemical formula
Hi. Alunite (Q338106) has and end member formula on rruff.info/ima/: KAl3(SO4)2(OH)6. I'm confortable with this, the formula is similar to my school time. De.wikipedia uses a different notation: KAl₃[(OH)₆|(SO₄)₂]. Is this ok? --Chris.urs-o (talk) 13:49, 15 May 2013 (UTC)
Actually the error shown is "The time allocated for the script to run has expired". I usually get this on php when execution exceeds 30 seconds, maybe the property list is already too long. --Napoleon.tan (talk) 05:00, 14 May 2013 (UTC)
The maxium runtime for lua is 10 seconds. If you are intrested in knowing what the lua runtime is on that particular page, then there is an "NewPP limit report" in the source of the page with "Lua time usage" among other performance statistics.--Snaevar (talk) 13:13, 16 May 2013 (UTC)
strange error
In Q6006 when I wanted to import interwikis it shows this error:
Saveerror:
*Alengthconstraintistriggeredforlanguagecode"ko".
*Thereis{{PLURAL:1|aconstraint|constraints}}violationfor{{PLURAL:1|description|descriptions}}"모양을 내어 구부린 ..."for{{PLURAL:1|languagecode|languagecodes}}"ko".
I just tried to made shorter, and I just testing remove and import interwikis, It is working now. Can you check it is working? Regards.--DangSunM (talk) 13:31, 15 May 2013 (UTC)
I wonder how it was possible to enter a too long description in the first place, but anyway if somebody can tell what the limit is, then I can easily make a list of too long labels, descriptions and aliases. Byrial (talk) 14:02, 15 May 2013 (UTC)
I see. I cannot check now as I forgot that I limited the fields in my local database to 256 bytes (which are different from characters). But I will make a list of too long labels, descriptions and aliases in the next database dump which is in progress right now, but seems to be stalling. Byrial (talk) 19:11, 15 May 2013 (UTC)
This bot edit put the start of a HTML comment <!-- into a value field. As a consequence a constraint violation report was "destructed" beginning from where the value was quoted. Fortunately the edit was caught quickly and reverted. However such edits should not happen in the first place. Bot operators should really do some sanity checks on each statement they are about to submit. -- Make (talk) 09:04, 12 May 2013 (UTC)
How could that destruct a constraint violation report? The value should generate a format violation report, otherwise the constraint violation tool is broken. Byrial (talk) 09:57, 12 May 2013 (UTC)
On second thought, I have to agree (partially): string values could be anything, consequently whenever one uses a string value from a statement, one should take appropriate measures to prevent unwanted side effects. (I have asked the creater of the constraint violation reports if he would consider to add some checks.) However I still think, that bot operators should as well take some responsibility and have sanity checks in their code. -- Make (talk) 10:43, 12 May 2013 (UTC)
Of course bots (or other users) shouldn't insert wrong values anywhere, but the tools should handle it when they do. Byrial (talk) 11:12, 12 May 2013 (UTC)
Has this been assessed before? String values that contain Wikitext, parser functions, HTML code, (what else?) can have unwanted side effects when the strings are reused (printed, ...) What recommendations are there to avoid such side effects? -- Make (talk) 10:43, 12 May 2013 (UTC)
There are two different problems and both should be corrected: (1) the bot that adds VIAF data should recognize only valid VIAF identifiers and should not insert incorrect data; (2) any reports that show data that could be entered by a user (that might contain HTML tags) should escape all special characters properly. Rsocol (talk) 05:21, 17 May 2013 (UTC)
Diff question
I just want to understand what Nullzerobot did here. It looks from the diff as if he added the th sitelink, though however this very sitelink used to be there before and I can't see any change at all. --YMS (talk) 21:05, 16 May 2013 (UTC)
...lock a this Diskussion from the disambiguation pages task force:
== Interwiki Links and Disambiguation ==
Some days ago, I tried to set an interwiki link to a disambiguation article and got an error message. If I got this right, it is not allowed/possible to link an article to a disambiguation, right? (If it actually IS possible, please correct me!)
I do not quite understand, though, why this should be a good idea. I'm thinking in terms of WP articles. Let's say there's a 'normal' article on a non-ambgious word in one language, while the same word in another language has several meanings. If, in these cases, it is not possible to link the article to its ambiguous foreign-language counterpart, you have no way to tell readers where to find the information they are looking for in another language.
Now, don't say that the article in the first language should be divided if it is really about two different concepts. That won't work in many cases as what is regarded one logically solid and indivisible concept in language A might be regarded as two completely different (and in the eyes of the speakers "logically" different) concepts in language B. This is a linguistic problem; anyone familiar with translation or linguistics will agree. Ignoring this and simply not allowing the linking of normal to disambiguation articles will result in extreme user-unfriendliness.
Another point I do not quite understand: Are interwiki links always non-directional? If so, that would mean, you simply cannot allow links from normal towards disambuation items while at the same time disallowing links in the other direction... - while this distinction indeed would be a good idea in terms of user-friendly and goal-oriented linking.
If anyone can clarify my doubts revise the disallowing of this kind of links, it would be greatly appreciated. And I also think that this might be quite an issue in the long run...
Another, similar problem: It appears to be impossible to link from two items to the same item in another language. The underlying linguistic/logical problem is the same as explained above, although in this case it's not about disambiguation pages... Is this so? --5.158.132.7218:49, 24 April 2013 (UTC)
It is technical possible to link articles and disambiguations. Do you have an example where it was not possible for you? And for the last question: yes, it is technical impossible to link two items from one language to one in another language with wikidata but you can still use the old fashioned interlanguage links. --Knopfkind (talk) 23:50, 24 April 2013 (UTC)
If you cannot link 2>1, as you say, then the only way to do this is an interwiki link. Now look at the history of that article: Many reverts with the explanation that wikidata links to disambiguation pages are not allowed or that the correct way are wikidata links not interwiki links... E.g.:
"Änderung 115995064 von Anka Friedrich rückgängig gemacht; Interwikilink zeigt auf eine BKL in en-WP. Das ist in jedem Fall falsch. Wenn schon unklar, dann bitte aus Wikidata entfernen."
"Revert auf Version von Benutzer:Anka Friedrich (12. Sep. 2012, 16:56). Grund: Nutzlose Änderung. Interwikis laufen über Wikidata."
You got the error message because you cannot link two items to one article, that's correct. For a database which is used by all wikipedias, you have to have clear and general rules. The Halsband/Collar problem is a really specific exception/problem. I don't think it's helpful to adjust the rules here in wikidata just for this case (or for every future exception). As I already remarked here, in my opinion this problem should be solved with local interlanguage links and cannot be solved in wikidata. I also commented your question here. --Knopfkind (talk) 10:10, 25 April 2013 (UTC)
Thanks again for your comments. The problem apparently is that some users think that iw-links are prohibited from now on?!
Now to this: "The Halsband/Collar problem is a really specific exception/problem." Unfortunately not. It's something that happens all the time. I can't tell you any examples right now, but as a translator and graduate linguist I tell you that 1:1 congruency between concepts actually is rather rare. OK, just a few examples:
de:Gerätestecker + de:Steckdose -> en:AC power plugs and sockets
de:Gerätestecker + de:Steckdose -> es:Enchufe
...etc. You could continue this list ad nauseam. While some of these examples are intrinsicly linguistic problems, arguably, some of them could be resolved by dividing or joining articles - a lot of work across many language versions and you will still have conflicts... --5.158.132.7213:07, 25 April 2013 (UTC)
I see your point. But right at the moment I have no other idea than using local interlanguage links. Assuming you are starting a discussion about changing the rules (article <-> disambiguation and 2>1) this needs to be confirmed by the community and even then you still have the software sided problem. And I'm even not sure if this is only a problem of the wikidata software or the mediawiki software in general because 2>1 was also not possible with the old interlanguage links (only the first links to one language was displayed). Do you have an idea to solve this problem? --Knopfkind (talk) 15:24, 25 April 2013 (UTC)
If you can indicate the right place where to continue/move this discussion (on either of the two issues...), I'd appreciate that :-) And concerning iw-links/mediawiki software: 2>1 links were/are possible. Obviously you mean that 1>2 links weren't possible (which is ok as it isn't really a problem imo). --5.158.132.7216:00, 25 April 2013 (UTC)
I guess that the wikidata:Project Chat is the Right place because we need a general rule for normal Interwiki links maybe a commentary indicating that they were checked/created after the introduction of Wikidata.--Saehrimnir (talk) 03:23, 27 April 2013 (UTC)
The German de:Halsband is one article about different kind of collars, and some Wikipedias have different articles for these kinds of collars. The general problem was discussed at this RFC and it was decided that it is allowed to link items to redirect pages to help with this. Now dog collar (Q8441013) links to de:Hundehalsband which is a redirect to de:Halsband. If the non-existing de:BDSM Halsband was created as another redirect, that could be linked to from bondage collar (Q1572196) and so on. (Note: It is decided that it is allowed, but it may not yet be technically possible, I don't know the status for the needed technical changes). Byrial (talk) 08:46, 15 May 2013 (UTC)
This is not a Wikidata Problem, it is a structural problem of de.wp that there are stupidly many People try to merge the whole site into the article "Enzyklopädie". The only solution is in this chase not to link to de.wp if there is no Article because linking to redirects is only working around the intention of Wikidata. --FischX (talk) 10:11, 15 May 2013 (UTC)
Or this is a structural problem of en.wp (and may be nl) that there are too many pages - for each a cough - which can be described in one article :) Infovarius (talk) 17:01, 15 May 2013 (UTC)
I approve the existance of problem mentioned by 5.158.132.72. And it's quite a frequent problem for disambigs too. Also I admit that introducing links to redirects will solve a part of the problem. Another part is 1>2 links which are completely broken by now (some time ago they were functioning, and now they are in Wikisources). May be this is not a Wikidata deal because there can be complicated situations like 1>2>3>2>1 which can't be resolved by centralized hub. --Infovarius (talk) 17:01, 15 May 2013 (UTC)
Have a better look at the examples given above and you will see that this is really an issue (and not a de.wp or en.wp problem...) We're excluding lots and lots of extremely helpful links if 2>1 iwlinks and links to redirects are not allowed! 37.49.102.8116:32, 2 June 2013 (UTC)
Two Commons categories in the same element
Some elements have two different Commons category property (p373) example - usually with the same value imported from two different wikipedias. This makes {{Commonscat}} templates using it in Wikipedias not to work. Is this duplicity intentional? If not, is it going to be fixed?--Pere prlpz (talk) 21:23, 15 May 2013 (UTC)
Potentially, there could be, but in general, there shouldn't. Especially the 2nd link on Q114357 shouldn't have been added. -- Docu at 00:00, 16 May 2013 (UTC)
Elements of a statement (as reference)We schould discuss this. What case do you mean?
(a) one statement with two sources
(b) two statements (same property, same value, different source)
As I understand it, (b) should not happen and be converted to the equivalent form (a). And from what I have seen, I got theimpression, that form (a) is used as (temporary) documentation to keep track where bot-added statements originate. -- Make (talk) 06:13, 16 May 2013 (UTC)
Sample mentioned above Q114357 is type (b). (a) is fine. There could be (c): two statements (same property, different values). -- Docu at 08:46, 17 May 2013 (UTC)
To prevent problems with two Media-files I have in the templates on svwp only requested the first claim, nomatter how many they are. In the future there will maybe be other possibilities. -- Lavallen (block) 10:03, 16 May 2013 (UTC)
Property help should be presented like template help on the front page, not buried on talk page
I would like for this community to look to how it presents its property usage. At the moment one has to dig into the talk page, and wade through whatever is there, if there is anything there, and it among all the other chatter that is on the page.
I would like to propose that for the property namespace that we look to utilise some of the smarts that have been learnt and applied for templates in that there is a subpage [[/doc]] page that is transcluded into its parent and that is within a <noinclude> frame. This would allow users to go to the property which is the link, look at the page and its instruction. There can clearly be a link to [[Property talk:{{BASEPAGENAME}}]] to where people can see and read the conversation that supports the property. Also on each doc there can be a standard default component that links to all our important Property help pages.
We should be able to set this up within the framework for such a doc page to be displayed if it exists. Making things easier for the users is surely something that should be valued for our users. — billinghurstsDrewth06:15, 17 May 2013 (UTC)
1-Now when we want to merge item A to B we should move all langLinks one by one and when the item has many langLin it is boring!
2-how we can move clams? In many cases item A will be empty but it has many clams which are useful to move them to item B151.46.239.17523:30, 9 May 2013 (UTC)
Users have the "move" gadget available to them for moving langlinks quickly. Not sure about claims though. There is some useful info on merging at Help:Merge. Del♉sion23(talk)23:51, 9 May 2013 (UTC)
3: It's quite hard to find the right items to merge. For example, if I want to add site link A to item Q1 (which already contains link B), a text message appears that it's already used on Q2. I have to copy the string "Q2" manually and paste it into the address or search bar. If I now find that Q1 and Q2 are to merge, and Q1 is more complex, I have to go back to Q1, copy the string "Q1" (from the address bar, it's nowhere to be found in the site text), go back to Q2, click a site link's "edit" button, click "move", paste "Q1", click "move", wait (and then face issues #1 and #2).
If I use the new "add site link" feature from inside Wikipedia for my initial task (link A to B), there's even more steps, as the message there just says "A problem occured". I then have to go to Wikidata somehow, click the ItemByTitle search link, enter the language code of A, enter A, search, open the item, open ItemyTitle search again, enter language code of B, enter B, search, open item, and then start to merge.
4: It's also hard to move labels and descriptions. The "move" gadget doesn't take care for those either, and working with the labelLister is no fun at all if I want to transfer labels and descriptions for multiple languages. The "autoEdit" tool helps a bit, but it's still not really good. And without the labelLister, I don't even see there are labels and descriptions for several languages (if they don't happen to be in my babel box list). --YMS (talk) 08:30, 10 May 2013 (UTC)
Merging definitely needs to be easier and more efficient than it is today. My own duplicate "collection" already contains more than 1400 candidates, and it's growing. A lot of work if it's going to be done "the old fashioned way". - Soulkeeper (talk) 19:13, 10 May 2013 (UTC)
Once wikidata external API comes out of beta we will need to guarantee persistent uris which means we will need to leave a redirect (not yet available from the developers) on the "deleted" pages. Filceolaire (talk) 08:49, 18 May 2013 (UTC)
I don't know if this is the right place to put it but I have not found one task force for movies. On this page there is a very long list of elements with the same IMDB id and in most cases are about the same movie and should be merged. --Kizar (talk) 00:35, 18 May 2013 (UTC)
I have corrected the first 40 or so entries on the list. In none of these cases it was duplicates. It was either wrong information at the sources, or mention of a person with IMDb template on a page linked to another item than the item of the person. Byrial (talk) 10:09, 18 May 2013 (UTC)
I've found plenty of duplicates there also. They tend to fall into these two categories categories:
Same film
Film/TV show confused with Actor/Actress/Director/Character/Series/Episode/Season
The former needs a merge. The latter needs to be corrected, though I'm not sure how long before a bot comes in and re-adds the ID as the original mistake is usually on a Wikipedia article with an external link. Del♉sion23(talk)11:43, 18 May 2013 (UTC)
That makes even less sense. The Beatles are part of a person? The Beatles are a subset of persons? I know you're not a big fan of GND (neither am I) but it's just silly to try to force the issue. The Beatles are a an organization and more specifically a rock band. That's all we need. (well I guess The Beatles would argue that all we need is love) Pichpich (talk) 15:32, 19 May 2013 (UTC)
I am inclined to delete statements about sex and profession etc. from such items, as I think that these things should be statet for the individual persons (which can be found with has part(s) (P527) property), and not for the group item. Do you agree? Byrial (talk) 10:49, 18 May 2013 (UTC)
I agree with you about sex and profession statements. I think that, for this kind of case we should have an item for the reunion which is considered as a list and an item for each member. So, the properties about member(s) of the reunion would be set in the item of each member of the reunion and not in the item about of the reunion. But, if we choose this system, we will have to modify bots to make them don't had properties related to member to the reunion item. Tpt (talk) 10:59, 18 May 2013 (UTC)
I agree. The property for sex should only be used for individual people, not for groups (even if the members of the group are all the same gender, for example Spice Girls) Del♉sion23(talk)11:47, 18 May 2013 (UTC)
On en.wiki, articles on multiple people aren't included in categories that only make sense for individuals. Instead, the redirects about each individual are categorized. For instance en:Sacco and Vanzetti is not included in the category "1891 births" (but the redirect en:Nicola Sacco is) or the category "1888 births" (but en:Bartolomeo Vanzetti is). The equivalent on Wikidata would be items for the individuals. Pichpich (talk) 14:25, 18 May 2013 (UTC)
It would have been nice to be able to create a relation between those redirects and the related items here on Wikidata. For me, that is more important, than being able to have interwiki to redirects. I see to many items where the subjects has been merged only because "number of bytes" is a measure of quality on Wikipedia. -- Lavallen (block) 15:03, 18 May 2013 (UTC)
I think that it makes a lot of sense for wikipedia to group associated items in the same article even if it makes things more difficult for wikidata. The change to the software to let us link to redirects should, however, help with this when it is implemented. To respond to the original question: P107 (P107) for ((Q|208415}} should be person. Filceolaire (talk) 20:23, 18 May 2013 (UTC)
This is in some ways similar to an issue I've had with articles on churches (and I imagine this will occur for other organizations) which are often about buildings and the organizations housed in them. Ideally, we would have a separate item for each notable thing (building and organization). --Jfhutson (talk) 22:07, 18 May 2013 (UTC)
Yes, it a common problem. Churches and organisation is not a big problem on svwp, but schools and buildings are. Since schools easily change buildings, it's a strange habit.
But the problems that made me respond to this thread is that all Swedish municipalities changed 1970/1971. Some of them survived geographicly until 1974, when they merged with somebody else. Even if the geographic extension of the municipalities was the same 1970 as 1971, the official name and far more serious, the type of organisation, changed. I have to create items without sitelinks for the municipalities 1971-73, to be able to make a structure that describe the process. There are redirects for these (uncreated) items, but today I cannot create a relation to them. -- Lavallen (block) 05:27, 19 May 2013 (UTC)
I think that adding "P76 (P76)" and "P77 (P77)" to items that already have "P74 (P74)" is extremely redundant and should be avoided: such items could simply inherit those properties from the genus, and so on. However, Dexbot and BotMultichill are mass-adding those properties to such items. I hereby propose to stop them from running those tasks. --Ricordisamoa17:23, 18 May 2013 (UTC)
I suppose that these properties helps to human readability (as Wikidata is not only machine-readable database). This is because many genera has only scientific names, while "P76 (P76)" and "P77 (P77)" usually have common names. Infovarius (talk) 19:28, 18 May 2013 (UTC)
I don't agree. Wikidata is not strictly for humans: data can be "prettified" later, and IMHO we could have a Lua module to automatically generate taxoboxes or taxonavigations with few information on each item. --Ricordisamoa21:06, 18 May 2013 (UTC)
I disagree because if you want to see it that way, nobody should add P107 (main type) to items which have already something that shows what is the main type (e.g. birth date or birth place). figuring out properties of an item by some other properties of that item is not our job, and besides Wikidata is not for Wikipedia exclusively, If google wants to know what is the phylum of a species, we shouldn't make them to write a very complicated code to review and load so many other pages every time to understand what is the phylum Amir (talk) 05:43, 19 May 2013 (UTC)
Hello I would like to suggest an improvement in the section "read in another language". Many times me (or other users speaking different languages all over the world) are looking to find an article in their language, and we find it in other language. When entering "read in another language" we can see a list of languages that have been written the same article. I want to offer to add a form "Request this article in your language" at the bottom of that list (pic01),
pic01
there it will be possible to choose from a list of languages that do not yet have that article, the requesting process is completely finished by the user in that form. So, requesting for articles that exist in other languages will be very intuitive and user-friendly for readers all over the world, who dont know the "normal" ways for requesting an article.
after requseting the data will move to db like this: (pic02)
pic02
users will see requests like this: (pic03)
pic03
and they can go to requests page, that will contain table like the db, but somthing friendly with sorting options.
what is your opinion?
someone can help me technicaly do it?
thank you all the users of Wikipedia!
liran.--Liransha (talk) 04:57, 19 May 2013 (UTC)
I've developed a simple Python script to help merging properties; it can remove multiple claims at once, and I'll soon add support for sources. You can view a preview here.
What's the plan exactly? Should that not be head of local government merged into head of government, and head of local government property deleted? Danrok (talk) 17:45, 19 May 2013 (UTC)
Is there any possibility to use "Wikidata Useful" to add "novalue" or "somevalue" to a property? I know how to modify it, to be able to add any normal claim like 'px:qy', but I feel unsure if 'px:novalue/somevalue' is possible to do. -- Lavallen (block) 16:39, 19 May 2013 (UTC)
Allow multiple entries of the same article
I can see it is impossible to add the same article into miltiple Wikidata items. Will it be possible in the future?
Example when this is needed:
There is a French localized version of a computer game, and there are articles in another languages about this specific French version. The French article would have to be both in the Wikidata item connecting articles about the game in general and in the Wikidata item connecting the articles about the French version.
Real-life example:
Japanese article "Kawaii", which is a Japanese word for "Cute". (but not exactly, the meaning is not quite the same). There are articles in many languages about the concept of cuteness in the Japanese culture (the articles are usually titled "Kawaii"). The Japanese article is currently in the Wikidata item for "Kawaii" (Q281639), but it would also want to be in the Wikidata item for "Cuteness" (Q1183652) so that other articles about "Cuteness" linked to it.
Another problem. Currently, the English-language article "Cuteness" links to the Japanese article "Kawaii" using an old-fashioned interlanguage link in the article text. But recently someone on Wikidata removed the Japanese article from "Kawaii" (Q281639) and added it to "Cuteness" (Q1183652). As a result, a bot removed the interlanguage link from "Cuteness" in the English Wikipedia as "provided by Wikidata". When reverting the move, I had to undo the bot action in the English Wikipedia too. --Moscowconnection (talk) 08:32, 19 May 2013 (UTC)
To address your first sample, I think it is conceivable that there be two items: one about the game and another about the localized version. In that case, I think only the main item would have interwikis, but not the one about the localized versions. -- Docu at 16:47, 20 May 2013 (UTC)
Actualy, it was already discussed here: #Interwiki problem!. My problem was hypothetical, I simply wanted to show why multiple entries of the same article should be allowed. As an aside note, I think Wikidata is flawed and very inconvenient. The technical skills needed to edit Wikipedia have just risen to a new level. --Moscowconnection (talk) 17:43, 20 May 2013 (UTC)
See also Wikidata talk:Interwiki conflicts. It should be possible to link to redirects in the future, which hopefully will be showable in interwiki links (I haven't seen any mention of an actual implementation or plans though). --AVRS (talk) 15:15, 21 May 2013 (UTC)
County of 'state' items
This was brought up earlier #Notability question, but I'd like to bring it up again to see what the clear consensus is. The item in question (in particular) is Q12037308 (county of South Dakota). The one discussed earlier was Q11774062 (county of Arkansas), but there are many more: Q13217186 (county of Arizona), Q13212489 (county of California), Q12262532 (county of Minnesota), etc. It probably would be a good idea to keep or delete them all. Should these items be kept or deleted? The Anonymouse (talk | contribs) 15:38, 20 May 2013 (UTC)
Since the definition of a County is different in each US-state: keep.
i.e. this cannot be used as reason to create items as "municipality in Norrbotten County, Sweden", since every municipality in Sweden looks the same, nomatter in which County. -- Lavallen (block) 16:35, 20 May 2013 (UTC)
If the definition of a county in each U.S. state is different, it's so negligible that it doesn't even matter. I think we should just use Q47168, county, for counties. TCN7JM on the Road (talk) 19:39, 20 May 2013 (UTC)
It is absolutely not negligible. In California, counties have extensive powers, in Connecticut, they have no powers at all. --Zolo (talk) 20:11, 20 May 2013 (UTC)
I wasn't talking about governmental definitions, I was talking about geographical definitions. I don't really see how the amount of power counties have in each state warrants different items. Either way, why can we not just use Property:P131 to differentiate between states? TCN7JM20:42, 20 May 2013 (UTC)
I think that specifying what the political/economic attributions of an administrative division is very relevant data. As it cannot be done at the federal level, that needs to be done at the state level, just as we have separate items for communes of France and communes of Italy. The main argument I see against state-specific property, is that is makes it a bit harder to generate links in the settlement_type parameter of en:Template:Infobox settlement. But this is just one instance of a major question that we need to solve in more general terms: whatever we do, we will often get values that do not have a valid Wikipedia sitelink (that not be very obvious in en.wikipedia, but it is for smaller languages). We need a more general way to handle that, probably through smarter templates. In this case, I guess it should be something like linking to the first valid sitelink encountered going up the item's subclass of (P279) chain. --Zolo (talk) 21:32, 20 May 2013 (UTC)
I will just agree to disagree. Since this issue only came up because I was doing stuff with South Dakota county items, what shall I do? Shall I add the "county of South Dakota" item to the county items I work with? TCN7JM21:38, 20 May 2013 (UTC)
I think it would be odd for Wikidata use a system whereby a new item has to be created every time we want to answer a statement and there isn't an appropriately named item available. It would be like blue linking every word in every sentence in Wikipedia. Can there not be a way to allow for a string answer instead? The same way that some key words in infoboxes are linked but not all are? Del♉sion23(talk)20:13, 20 May 2013 (UTC)
I dont think using a sring would make any sense here. The question is not about the name (indeed it may make sense to relabel "county of California" into "county"). What matters here is that a county is not the same things in different states, and that can only be captured by an item. Suppose you want to get a list of all subdivisions of the US that have some fiscal autonomy, it should include counties of California, but not counties of Connecticut. If we want to be able to do that, we need a dedicated "county of California" item. --Zolo (talk) 20:20, 20 May 2013 (UTC)
That is exactly what I said, and I stick by that opinion. The extra specificity is unneeded when we already have properties and items to use instead. TCN7JM22:10, 20 May 2013 (UTC)
The things is that the items should not be empty. "type:county, located in South Dakota" is clearly enough to guess that something is a county of South Dakota, but it does not tell us what a county of South Dakota is, and that is the job of a "county of South Dakota" item. --Zolo (talk) 06:23, 21 May 2013 (UTC)
The job of an item, is not to explain anything but to link an explanation in form of interwikilinks, and there is nothing to link here because it is just not significant enough to justify a Wikipedia article. If the differences of counties of US-states would be included in Wikipedia, it would be in form of a segment inside of an existing article at best. --Sixsi6ma (talk) 10:12, 21 May 2013 (UTC)
Uh do you really believe that "The job of an item, is not to explain anything but to link an explanation in form of interwikilinks" ? If so, you miss a good part of what Wikidata is about. --Zolo (talk) 11:34, 21 May 2013 (UTC)
Please tell what counties of South Dakota have in common besides being counties of South Dakota. Right now county of South Dakota (Q12037308) doesn't have any statements beyond that. If it did, it would be easier to see a need for the item. Right now I cannot see a need. Byrial (talk) 12:00, 21 May 2013 (UTC)
I do not know for South Dakota, so I take California :): it is governed by a "board of supervisors" (whose powers are determined by Californian law) and it has the ability to raise taxes (that is true in some other states, but to varying degrees, and it is determined by state, not federal, law). There are other specific features (see for instance wikisource:en:California Constitution/ARTICLE XI), but these one should be sufficient: that makes a county of California about as different from a county of Connecticut as two administrative subdivisions can get (conties of Connecticut have no power at all, they are just statistical units) --Zolo (talk) 14:45, 21 May 2013 (UTC)
Tech newsletter: Subscribe to receive the next editions
Latest Tech news from the Wikimedia technical community. Please inform other users about these changes.
Recent software changes
(Not all changes will affect you.)
The latest version of MediaWiki (version 1.22/wmf4) was added to non-Wikipedia wikis on May 13, and to the English Wikipedia (with a Wikidata software update) on May 20. It will be updated on all other Wikipedia sites on May 22. [5][6]
A software update will perhaps result in temporary issues with images. Please report any problems you notice. [7]
MediaWiki recognizes links in twelve new schemes. Users can now link to SSH, XMPP and Bitcoin directly from wikicode. [8]
The UploadWizard on Commons now shows links to the old upload form in 55 languages (bug 33513). [14]
Future software changes
The next version of MediaWiki (version 1.22/wmf5) will be added to Wikimedia sites starting on May 27. [15]
An updated version of Notifications, with new features and fewer bugs, will be added to the English Wikipedia on May 23. [16]
The final version of the "single user login" (which allows people to use the same username on different Wikimedia wikis) is moved to August 2013. The software will automatically rename some usernames. [17]
A new discussion system for MediaWiki, called "Flow", is under development. Wikimedia designers need your help to inform other users, test the prototype and discuss the interface. [18].
The Wikimedia Foundation is hiring people to act as links between software developers and users for VisualEditor. [19]
Important note: This is the first edition of the Tech News weekly summaries, which help you monitor recent software changes likely to impact you and your fellow Wikimedians.
If you want to continue to receive the next issues every week, please subscribe to the newsletter. You can subscribe your personal talk page and a community page like this one. The newsletter can be translated into your language.
See WD:Notability. US counties, along with their political attributions are defined at the state level, so I would say it meets both criterion 2 and criterion 3. Of course, adding other claims to the item would make sense. --Zolo (talk) 18:21, 14 May 2013 (UTC)
One could interpret the third paragraph of WD:N that way but this is hardly viable because the data is not atomized and thereby violates database principles. --Sixsi6ma (talk) 18:38, 14 May 2013 (UTC)
What does it mean that the data is not atomized, and which principles are violated?
Just a quick front-page reminder that there are a huge number of properties that need reviewing. More opinions will mean better refined properties: --Tobias1984 (talk) 11:45, 22 May 2013 (UTC)
I tried to using new tool, so I tried to check and saving the setting, but it doesn't work now. What happened?--DangSunM (talk) 16:04, 22 May 2013 (UTC)
I mean that we can get country from division. For example Boyarka (Q891175) has P131 and P17, but we can get country if we have only P131 as (if will be full implementation of WD in en-wiki). So claim P17 in this item is redundant.--Ahonc (talk) 22:18, 23 May 2013 (UTC)
Would be nice not to autowatch pages which were successfully merged and subsequently deleted. Not sure if that's possible or not, since it appears that we are actually editing each page. --Izno (talk) 00:49, 23 May 2013 (UTC)
Alternatively to the above, you could stop redirecting us to the merged into page from the merged page. --Izno (talk) 02:23, 23 May 2013 (UTC)
My Firefox v20 on Windows 7 64 bit was choking on a fair number of moves. It was somewhat intermittent, but seemed roughly correlated to whether there were claims that were strings. Can you look into that?
Second feature change: Possibly, multiple item merging? Could do something like a comma separated input. --Izno (talk) 02:23, 23 May 2013 (UTC)
Multiple item merging was goal of merge of from the beginning of development and all of its base functions is supporting it but it is not supported through the UI. I am a but busy till Monday (I must prepare my self for an exam :P) but I think Ricordisamoa can implement it simply by the way that you suggested or a more superior way (using multiple Wikidata entityselector). –ebraminiotalk07:49, 23 May 2013 (UTC)
Issue with the implementation of the review score property
You're going to want to click and view the larger version at Commons...
Hey everyone. If you work with properties, please take a look at the image on the right. Below the black line that cuts it (kind of) in half, several different reviewers' scores are all listed together as qualifier of the same value (8.5/10) because all of the different reviews scored the game the same. This is really problematic, and I think that we need to nip it in the bud as quick as we can, because what is actually going on there is that three separate data points are getting mushed together, costing accuracy for the sake of speed of entry. With the three reviews sharing the same value, adding in the platform qualifier becomes difficult (how do you know which review it applies to?), and other possible future qualifiers, such as the name of the reviewer (most review sites have several), would also be difficult to add in.
What needs to be done is that anytime (for any property) that two different sources give the same value, they are listed as two separate values, which you can see in the circled portion of the top half of the image to the right.
Please let's not get into destructive bad habits. It happens to be that in this case it's going on in the review scores property, but it could happen on any number of others. Let's keep our data clean and useful. Thanks a bunch! Sven ManguardWha?06:27, 23 May 2013 (UTC)
Comment I am not sure that "What needs to be done is that anytime (for any property) that two different sources give the same value, they are listed as two separate values", at least the requires further thought and discussion. Note that the software is designed to allow several sources by statements (and several statements within each of these sources). In your example, we need separate statements not because the sources are different, but because the real meaning is (or equivalently, because the should have different qualifiers). I am not sure that it has any necessary connection to the number of source. The same source can compile several critical reviews, and conversely the same review can be provided at several different places. - Zolo (talk) 07:33, 23 May 2013 (UTC)
Dynasties and Royal houses
What would be the best property for claiming the house to which a person belongs?
Just spotted a presentation from Google I/O about their Freebase project. This is their project to turn the information in wikipedia into a database. Some similarities to wikidata but a lot of differences too. One thing they don't seem to worry about is fact checking the wikipedia information. Filceolaire (talk) 20:08, 18 May 2013 (UTC)
They have several programmers working on the development, they have servers and ressources to handle large amount of data, they have less contraints than Wikidata (relation between wikipedia article and wikidata item),... Already now their interface is quite better. The only thing which can do the difference in favor of Wikidata is reliability through referencing. Snipre (talk) 08:58, 19 May 2013 (UTC)
Freebase is already several years old, it seems that Google took it over recently. If you believe that freebase is superior to WikiData, then change your bet ;-) WikiData is (for me at least) at first a tool to manage data we can use in the encyclopaedia, and not a goal by itself. Both can develop independently, and you'll never know where their roads may cross or merge. Edoderoo (talk) 10:53, 19 May 2013 (UTC)
First, freebase is old, of course we can learn from freebase but you can't use freebase in Wikipedia and freebase can use Wikis as a source (with wikidate even easier) but it is only about aggregation wikidata is a tool for Wikipedia, and thats makes wikidata strong - less data rott... --FischX (talk) 11:06, 19 May 2013 (UTC)
I don't find Freebases interface to be better. In fact it is quite poor, IMO. Having said that, it doesn't appear to be of Google's creation, they tend to have interfaces which are similar to what we have on wikidata. Danrok (talk) 17:36, 19 May 2013 (UTC)
To me Freebase looks like it is a just a huge bloated copy of every Amazon and online retailer page that ever existed. Most of the information is music, film and if a certain printer has a scanner. Every science item I looked at was just a poor copy of the Wikipedia infobox with no additional and easily obtainable information added. --Tobias1984 (talk) 17:46, 19 May 2013 (UTC)
I'd say, they're already benefiting from the imporoved interwiki model on wikipedia which is most likely used to build search indexes, etc. Danrok (talk) 17:11, 24 May 2013 (UTC)
Problem with property proposal and creation
This is mainly a personal opinion but I think we have to discuss about a more optimal way for property creation procedure.
Most of the proposals and some property creations are made without any global overview of object description. This leads to trials-and-errors process for the creation of property sets for the different items. We really need to encourage contributors to spend more time to prepare a whole and if possible complete list of properties. Snipre (talk) 18:24, 21 May 2013 (UTC)
Are you referring to any specific area of properties? I mean such as hierarchical properties, qualifiers, or something else? Danrok (talk) 23:17, 21 May 2013 (UTC)
Maybe you could prepare a sample proposal to illustrate your point. Just bear in mind that only three datatypes are currently available and users will actually have to figure out how to use the properties for entry/triage/value and consistency checking/retrieval. -- Docu at 06:16, 22 May 2013 (UTC)
Even if you don't have all datatypes, you can do a simple list of all properties you need to describe one item and don't do that on the properties proposal pages because you can't have a global overview with the current proposal template. If you want an example of mapping see chemical properties list or book properties list. When somebody wants to add proposals this kind of lists avoids redundant proposal because everything in there even common properties shered between different fields can be added.
My opinion is that few persons have a clear idea how a specific item can be described, what are the main properties which have to be proposed first and those which can be added later. People are just putting right now proposals when they have a idea, without any preparation or discussion with others contributors. In one word there is not collaboration. Snipre (talk) 09:00, 22 May 2013 (UTC)
Comment. It may be nice to think more systematically, but is difficult to get the big picture of how properties work with one another, or how the same property can be generalized or applied to other fields. Creating properties for real often makes things clearer. I do not think it is such a bad thing if some of them need to be deleted afterwards. Wikidata is still immature, and we may need to play around with things for some time. It is not very difficult for a bot to fix things - though we obviously need better tools to track property usage in Wikipedias. --Zolo (talk) 08:19, 24 May 2013 (UTC)
Trial and error is one of the best ways to learn, but we where maybe to early with activating phase II on Wikipedia. My opinion today is that we should have waited until all (important) datatypes and Lua-tools where availible. -- Lavallen (block) 08:35, 24 May 2013 (UTC)
Issues with new gadgets
Due to the ongoing issues with new gadgets (disrupting the user interface with broken JS, security issues, ...), I've now created an AbuseFilter (1) which warns admins on enabling a new gadget. It shows the the following notice: MediaWiki:Abusefilter-new-gadget. I hope you agree with this step and the action taken. - Hoo man (talk) 19:35, 21 May 2013 (UTC)
Why not just use an editnotice? We don't need admins showing up in the abuselog. πr2 (t • c)01:04, 24 May 2013 (UTC)
Because edit notices don't interrupt the workflow (by requiring another submit), they easily can (and will) be ignored. IMO is to important to have it being ignored or overlooked - Hoo man (talk) 08:57, 24 May 2013 (UTC)
I think I've made something stupid.
I'm sorry to bother this page with my troubles; but I found no "help desk" kind of page.
This is the first time I tried to add a link to a particular newly created page to an existing item in what I felt was the most natural way; i. e., I located the appropriate item on d:, and tried to add the information about the new iw-sister directly on that page. This was frustrated. I'm afraid I have corrupted the underlying source text in some way in my attempts; vide infra.
The item is Q9727604; it already contains 14 iw-sisters; I tried to add fo:Bólkur:Jóturdýr. (You can follow my frustrated attempts in the item history.) Finally, i did succeed to add something somewhere in connection with the list (I think), but it is invisible.
I gave up, and tried another approach; going back to the category page on fowp, I clicked the Add links alternative. It turned out that there was no way to enter the fact that the link to the page was to be added to item Q9727604 directly. On the other hand, I had found the page by means of one of the older sister articles, and remembered that, and could enter its name and language. Your decoder told me that an item already existed for that item (namely Q9727604; big news), and asked if I really wanted to add the link anyhow. I confirmed.
The decoder dialogue reported "an unexpected error". I tried a number of times, with the same result. My suspicion is that the text string I succeeded to enter (in my second edit; see the item history) still is around in that page, but in an inappropriate manner, and that the hidden source page thus is ill-formatted from the point of view of the dialogue decoder.
As I said, I'm sorry for the trouble I've caused. Probably, someone with the right to "look behind the scene" needs to fix this, directly in the source file. Possibly, there should also be a warning somewhere visible for people like me, who believe ourselves to be experienced enough to do what we always do; i. e., to first collect all relevant information, and then to go to the appropriate place for to add it there. If there really is no way to add the links of a new page from within d: itself, there should be a clear warning about this, I think. JoergenB (talk) 14:37, 23 May 2013 (UTC)
No we have to be sorry because we have no good tutorial how to use wikidata. To add an languagelink you have to klick the little add link below all the other languagelinks. The second attempt you did should have done the trick so maybe that is a bug.--Saehrimnir (talk) 14:43, 24 May 2013 (UTC)
Because work is for a piece of art. While a specific apple pie could be seen as a piece of art, apple pie is a category much like novel. —★PοωερZtalk14:31, 24 May 2013 (UTC)
It is just one possible classification system of one authority control organization. While it is IMHO feasible to bot-add it to many articles (besides i do think it is only helpful for items which are considered by this system ,i.e. having also an GND-ID), we all should think about a how we could create a more specific classification system (e.g., a broad use of "instance of" Property:P31). This is much more beneficial than argueing about the limitations of GND-Type. The GND-Type was defined with a completely different usage in mind. FelixReimann (talk) 15:06, 24 May 2013 (UTC)
Hi, there is a mix up of the generic term midden with a specific archaeological term en:shell midden, which is mostly called de:Køkkenmøddinger in Europe, because there the equivalent feature got discovered by danish archaeologists first. Please try to sort out the two different meanings. TIA and rgds --17:33, 24 May 2013 (UTC)
I didn't notice, that en-WP does not discriminate between a midden and the archaeological term. In all languages, where Køkkenmøddinger is used as article-name, the articles describe exclusively the archaeological term, not "regular" middens. Would it be helpful to split the en-WP article in two? rgds --H-stt (talk) 18:40, 24 May 2013 (UTC)
Fictional characters notability
Are all fictional characters of notable work will be notable even if there is no dedicated article or only section exist? I think such items will be useful at least for works translated on different languages or adopted multiple times. For example, for Property:P453. Also could be included in work item as characters property to automate lists creations. --EugeneZelenko (talk) 14:00, 18 May 2013 (UTC)
I think it's pretty obvious that the answer is no but it's not clear where we want to draw the line. Some film credits list fictional characters known only as Bob, young woman, bus driver and so on. Creating a new item with the label Bob every time some film character named Bob steps in front of a camera is undesirable. (if only because it pollutes searches which is particularly problematic because of the currently awful search engine) For starters, I think we could agree that if character X has no Wikipedia article and no redirect to a Wikipedia article, then character X does not deserve an item. Pichpich (talk) 22:00, 18 May 2013 (UTC)
I think it might depend on how much info there is about the character. If a book spends a dozen pages describing a character, it might deserve an item to keep track of all that data. -- Ypnypn (talk) 03:14, 21 May 2013 (UTC)
I agree that search pollution is a problem, however, I think there is a technical solution to it: order same-label items by number of statements. This would ensure that items about one-scene characters named "Bob" are at the bottom of the list. Also, there is a discussion about this in wd:Project_chat#Jurors_1.E2.80.9312. Silver hr (talk) 22:27, 24 May 2013 (UTC)
Translation help needed
Hello everyone. As the result of a request for property deletion, I am in the process of depreciating Property:P46 in favor of Property:P6. Originally, P46 was for the head of the national level government and P6 was for local governments, however now that they are being combined and P46 is being deleted, the current English label for P6 is "head of government" and the current description is "chief administrator of a town, city, municipality, country, or other governmental body".
It would be greatly appreciated if you could alter the label, description, and aliases for Property:P6 in the languages you speak to reflect this change.
I'm just see the item Q12857403, which list the documentation pages of "Template:Link FA". I don't think this item is very useful. Some others opinions ? --Nouill (talk) 13:47, 25 May 2013 (UTC)
I guess such tools as "Whatlinkshere" works, but that is maybe all in the main namespace...
The api looks very different on this project compared with other, so I think the awb-developers have to make many changes to make the software work here. My opinion is that they are welcome! -- Lavallen (block) 15:56, 25 May 2013 (UTC)
Read-only mode is working fine. Before making edit I see the source text of Wikidata item (it's text, don't you know?), but AWB can't save the change. Infovarius (talk) 18:36, 25 May 2013 (UTC)
The first and third are not links to modules, they are only links to documentation, they can be deleted if you ask me! -- Lavallen (block) 17:17, 25 May 2013 (UTC)
I really hope someone is working on a tool to help merging of items. It is really annoying to do. I just increased my contribution counter by 42 to make one merge! And it was just links, labels and descriptions. Yesterday I had another one, where I in addition to this also moved 5 or 6 statements with sources. It can take long time, and is an error-prone process. Please, if somebody can make some sort of tool to help, please do! With annoyed regards, Byrial (talk) 21:45, 20 May 2013 (UTC)
You don't need to these edits one by one, if you have "autoEdit" gadget enabled. But I agree, that it would be really helpful to have some tool to make merging faster and easier. --Stryn (talk) 21:53, 20 May 2013 (UTC)
Yes. I really need help because I am not very familiar with Wikidata API. My script currently is supporting moving sitelinks/labels/descriptions but sometimes it will make a new item! Also its UI and functionality really needs improvement. –ebraminiotalk23:13, 21 May 2013 (UTC)
Concerning the "Move" tool, would it be possible that it moves labels and description at the same time as the corresponding language link ? the moving of labels and description is painful, especially because you need to remove each one before adding it to the other item, in "foreign" languages (i.e. not your work language)…
Thank you for your efforts! I tried User:Ebraminio/merge.js to merge Q8522711 to Q8976320. It seems that it moved links, labels and descriptions OK, but then it continued to display "Please wait..." for minutes (and is still doing it in another browser tab). There is 2 statements, which are not moved. Byrial (talk) 16:02, 22 May 2013 (UTC)
In the two first test, I did not select "Request deletion for this item on RfD". This time for merging Q8575603 to Q8986978 I did. It still doesn't stop after movinf items, labels and descriptions. and doesn't request deletion. Byrial (talk) 16:26, 22 May 2013 (UTC)
It seems it is not possible to move two or more claims at once (with one edittoken) but for other items that you linked, it is working now so, of-course, thanks. –ebraminiotalk17:41, 22 May 2013 (UTC)
Thank you again ebraminio and Ricordisamoa. Note that references should not be moved blindly. If an identical claim (main property and all qualifiers) is not present at the receiving item, everything including the references should be copied. But if an identical claim is present at the receiving item, all references at the obsolete item which not are at the receiving item should be added to the existing claim. Byrial (talk) 22:51, 22 May 2013 (UTC)
I have now used this many times, and like it very much. But it will not merge Q9908366 and Q6769634. It removes the lonely link and label from Q9908366, and then nothing more, just a non stopping "Please wait ...". I tried 4 times after reverting the changes to Q9908366 so it is reproducible. NB: If you are not debugging merge.js, please do not merge the items as I want the debuggers to have the test case. Thank you. Byrial (talk) 18:33, 24 May 2013 (UTC)
I'm trying use User:Ebraminio/merge.js but it's not working in Opera... After clicking tab button text "Merge.js has been started. Now you can focus your browser on the other item and refresh the page." popups but on the next page the same text popups! Infovarius (talk) 18:41, 25 May 2013 (UTC)
I'm doing Python-aided, semi-supervised mass-deletions of items merged and emptied by SamoaBot and Rezabot.
I already mark such deletions as such, but should those deletions be done by admin-bots only? Is this use of the sysop rights legitimate? Or would you prefer SamoaBot/oth. being specifically "sysopped"? --Ricordisamoa06:27, 25 May 2013 (UTC)
For convenience, I report that both Hazard-Bot and HaroldBot weren't approved as admin-bots.
That said, I really think this task is fairly different from those, because of the very strict checks before deletions. --Ricordisamoa06:50, 25 May 2013 (UTC)
If we should have adminbots, I would prefer accounts who do not have so many other "normal" bottasks. It would make it easier to follow the logs. I had an Adminbot (Lavallen2) on Wikipedia, and it was separate from the other bots. -- Lavallen (block) 07:27, 25 May 2013 (UTC)
If the code is good and regularly updated if policies/criteria change etc. I see no problems with adminbots. Regarding to the logs, the deletion log is separated from the others. Thus, I don't see a problem with using the same bot account for this task either. Regards, Vogonetalk13:25, 25 May 2013 (UTC)
I have no objections for a user which is both a good bot operator and an administrator to run an adminbot for well-defined tasks requiring admin status. But I would prefer to have a separate account for admin-tasks only. If the bot should misbehave during some non-admin task, it is best to have no more user rights than required for task. Byrial (talk) 21:16, 25 May 2013 (UTC)
I think the majority of the questions posted there are answered by WD:VG TF as linked above. As for your qualifiers question, we might be able to do that when the TimeValue type is finally rolled out (supposedly a week or two from now). --Izno (talk) 15:19, 26 May 2013 (UTC)
Oh, thanks, I was not aware of this page (though I did look around). Looks like the perfect place indeed. Thanks for the pointer! Jean-Frédéric (talk) 19:48, 26 May 2013 (UTC)
Data inclusion by labels is now available on Wikipedias and time datatype is getting closer
Heya folks :)
I just wanted to let you know that it is now possible to include data from Wikidata using the property's label (not just the ID). So in essence this means that you can for example use {{#property:continent}} instead of {{#property:P30}} if you don't want to remember the ID there. Both of these would return "Europe" if used in the article about Spain for example.
In related good news: The time datatype has progressed very well and we expect to be able to deploy it next week. However it'd be awesome if you could help test it on the demo system to make sure we have not missed any major issues. Help with translations on translatewiki.net would also be most excellent.
The time datatype looks great. A few issues, though:
The demo doesn't seem to have a way to go more specific than one day. Is this planned for a later version, or a separate datatype, or not at all? (Or have I just not figured out how to use it?)
The demo allows for dates that didn't actually exist (ie February 30). Is this deliberate? If so, I'm not sure it's a good idea.
Which calendar was used to input the data is stored, apparently. While this makes some sense for calendars that don't match up perfectly with the Gregorian calendar, I don't see why it's needed for calendars like the Julian calendar.
Good news! In French, there is a display issue for the time datatype: it shows "février 15, 1900" while it should be "15 février 1900". Ayack (talk) 07:38, 23 May 2013 (UTC)
There is an similar problem to the french one in Icelandic too, as the date should be shown in the format: "day. month year". So, the dates on Q4 in the demo repo should be 31. febrúar 1900 and 9. mars 1814, respectively.--Snaevar (talk) 11:35, 23 May 2013 (UTC)
I do not care very much that the same problem is also in Swedish. It looks like this:
There's problem with the Finnish date also. "huhtikuu 24, 1967" (April 24, 1967) should be "24. huhtikuuta 1967". Notice -ta ending after every month. --Stryn (talk) 12:46, 23 May 2013 (UTC)
Hey :) Thanks for the feedback. Here's the replies:
More specific than day is planned but not implemented yet.
Days that don't exist are recalculated and matched with the existing date. That's the best we could come up with for now.
Calendar system needs to be saved because we need to know which system it was saved in and which one it is supposed to be shown in. More systems will be supported in the future.
Buggy precision dropdown is being worked on.
Incorrect display of dates in differente languages is being worked on.
"timezone" stands for the timezone (useful later when we can enter hours for example),
"before" and "after" will later be used to allow entering a range
"precision" corresponds to month, year, decade and so on
Do you have any idea of how long time it will take until this datatype can be used as a "range"? That sounds to me like a much more interesting option than using both "from" and "until"-properties. And will there be any option to have an "open end" for such things as "John Doe" king of "Farfaraway" 2001-
As far as I understand it it is not supposed to be used as a range but rather to say that a specific date is inside a range but we don't know the exact date. I will try to clarify this though. (Might take a few days because of the hackathon in Amsterdam.) --Lydia Pintscher (WMDE) (talk) 14:06, 23 May 2013 (UTC)
If you enter "January 4" the system understands it as the month January of the year 4 CE. This is not at all what most users would expect. Could the display make it clearer, perhaps by displaying it as "January, 4" or even "January, 4 CE"? -- Ypnypn (talk) 14:35, 23 May 2013 (UTC)
Do you plan to support other calendar than the Julian and Gregorian? how about Era based date like for example japanese era calendar? --Napoleon.tan (talk) 16:48, 23 May 2013 (UTC)
For Ukrainian and Russian languages displaying is wrong too (should be 24 квітня 1967 and 24 апреля 1967 instead of квітень 24, 1967 and апрель 24, 1967).--Ahonc (talk) 22:28, 23 May 2013 (UTC)
it seems the maximum that can be stored in a date is about a billion years; for cosmology, that might be a bit small.
if I enter 1,000,000,000 and save, it will be displayed as "in 1 billion years". If I edit again, the actual text of the field will be "in 1 billion years" which the edit widget will not recognize as a valid value.
for me the horizontal dial thingie to select precision/calendar was not intuitive. When I first saw the Gregorian ▾ ▸ Julian thingie, I thought Julian is the default, and I need to click on the horizontal arrow to set the new value. Once you have a dropdown for selecting a value, users will expect additional interface elements to have a different purpose; the duplication can be confusing.
What does anyone think about implementing pending changes protection for, say, articles that are a recurring target of vandalism, but the vandalism is not heavy enough to qualify for semi-protection. I suspect this will not receive a lot of support, but I may as well throw the possibility out here. --JakobScream aboutthe things I've broken23:15, 25 May 2013 (UTC)
I'm not sure Pending Changes could even be implemented on Wikidata's mainspace, since it's so different from other Wikimedia projects, but irregardless I'm opposed to it, as I dislike the idea of Pending Changes to begin with. Sven ManguardWha?23:21, 25 May 2013 (UTC)
I'm skeptical (as a supporter of pending changes/flagged revs). I'm not sure that those pages shouldn't just be semi'd and be done with it. --Izno (talk) 23:27, 25 May 2013 (UTC)
I do support flagged revs for big Wikipedias as well, but I guess semi-protection is better for Wikidata. The community is simply too small to look over so many items and mark them all as patrolled. Vogonetalk23:55, 25 May 2013 (UTC)
FlaggedRevs would need much reworking to suite Wikidata, and I don't think that would be a developer priority. I could see why we could use it, since our information will affect all Wikipedias, but I don't think it's happening any time soon.--Jasper Deng (talk) 00:06, 26 May 2013 (UTC)
Honestly, it'll be easier to use semi-protection and individual watchlists... we don't have enough reviewers to make pending changes work. Ajraddatz (Talk) 04:47, 26 May 2013 (UTC)
I agree, also for the reason that, as long as a pending change has not been "reviewed", the "old" version is still used (see what happens on wrong AC on de wikipedia) - there are constraint violation (VIAF/ISNI), and the correction of the source not being reviewed, the suppression of the constraint violation is without effect, because it comes back from the unreviewed source :(( --Hsarrazin (talk) 08:00, 26 May 2013 (UTC)
We do not currently have enough manpower to handle pending changes. We even started to get RfD backlogs, and pending changes take much more time if done properly.--Ymblanter (talk) 19:14, 26 May 2013 (UTC)
Yes the session ended hours ago ;p I have added a note to the bot accounts that were created to the session prompting them to apply for approval is they want to continue to run. I has also added a note to 2 ip address user pages that some edits escaped one from the hackathon session so we know why the ips were making bot edits in the future! ·Add§hore·Talk To Me!13:05, 26 May 2013 (UTC)
Has this been talked about yet? Has it been done on wikidata yet? Should requests such as this be made alongside other bot requests? Should we instead have a separate flag for api high limits? ·Add§hore·Talk To Me!11:37, 26 May 2013 (UTC)
Since the bot flag is easy to get I propose to give it also to readonly bot accounts. Is theire an actual case where this flag is needed for readonly? --Pyfisch (talk) 12:50, 26 May 2013 (UTC)
I had a request today at the hackathon. I am guessing it would be worth writing a request in the same way on the bot requests page and simply not requiring any test edits (as there will be no edits). Then the community and a crat can quickly review and flag. ·Add§hore·Talk To Me!13:03, 26 May 2013 (UTC)
What would be the benefit for Wikidata/Wikimedia? Normally, there are the database dumps for this. -- Docu at 14:22, 26 May 2013 (UTC)
This. Especially since we have incremental dumps, there really isn't a need for high query rate w/ no editing. But if someone comes up with a reasonable use, I don't see why we shouldn't give them a bot flag. Legoktm (talk) 17:57, 26 May 2013 (UTC)
The trick (that I’ve just learnt during splitting Q13397636 and Q63100) is to delete the link first at the entry where it is used, and then add it to the place where you want it to be. I’ve just done that for your case, and now we can indeed wait for the deletion of Q5551359 while all articles about Q136613 display correct interwikis. --Spider (talk) 12:04, 27 May 2013 (UTC)
A merge is performed by following the instructions at Help:Merge (removed the link from one item, add it to the other, request the deletion of any empty item created through this process). There is also a gadget that can be activated in your preferences. Del♉sion23(talk)17:21, 27 May 2013 (UTC)
Suggestion: Eliminator
There are thousands of items deleted in one day. I propose to enable the eliminator flag (users who can delete pages) on Wikidata. Eliminator flag is enabled in Japanese, Russian, Spanish and Portuguese Wikipedia. see Q10862160.--GZWDer (talk) 04:01, 26 May 2013 (UTC)
Oppose because adminship on Wikidata is fairly easy to obtain and the primary reason for requests for administrator access here tends to be deletions.--Jasper Deng (talk) 04:09, 26 May 2013 (UTC)
Oppose per Jasper Deng. Most of the sysops on here requested the right to delete items, myself included. TCN7JM04:24, 26 May 2013 (UTC)
Comment I think the number of deletion requests will go down eventually anyway, but if it doesn't I consider this to be a valid option. —★PοωερZtalk08:42, 26 May 2013 (UTC)
Comment I'd like to take the opportunity to encourage users to apply for adminship. Particularly those who regularly put in requests to RfD. We need all hands on deck at this point with hundreds of deletion requests being posted every day. Del♉sion23(talk)17:07, 26 May 2013 (UTC)
I have protected Q1231 and Q1246 for a period of one month due to in effect, edit warring. If both (or one) users engages in this activity on hose items then blocks may be needed instead of protection. John F. Lewis (talk) 20:09, 27 May 2013 (UTC)
Hockey
Hi, I'm asking someone to take a look at these two items: Q1622659 and Q11218525. Me and User:Infovarius have had been little edit war, and I don't want to continue it, so I'm here to ask someone else to look those items, and especially fi-wiki and el-wiki links. In my opinion these two links are disambiguation pages, and they should be linked to Q11218525. Thanks. --Stryn (talk) 20:55, 14 May 2013 (UTC)
They both seem to be disambiguation pages to me. On neither wiki does there seem to be a page talking about the family of sports that is hockey. FrigidNinja21:04, 14 May 2013 (UTC)
I believe that there are "topic disambigs" which describes term from specific topic unless they have disambig-template. Here we have such situation for el and fi links. If you look at them you'll see that these are per se small articles (lists) about a family of sports. And so is the hockey (Q1622659). I don't see a reason (except formal one) why they can be outside. Infovarius (talk) 17:45, 27 May 2013 (UTC)
Well... I think hockey (Q1622659) is for articles (disambiguation page is not an article), whereas Hockey (Q11218525) is for disambiguation pages (article can't be a disambiguation page). And both pages, fi:Hockey and el:Χόκε are disambiguation pages. For clarifying that fi-wiki page is a disambiguation page, I've added there also one non-sport related link. --Stryn (talk) 18:24, 27 May 2013 (UTC)
As told in the project glossary; in future, new features will be added for differentiating different classes among statements (ranks) and among site links (attached badges). Why not use something like that for differentiating among aliases? We can differentiate different aliases according to their types: different spellings, wrong but dominantly common spellings, redirecting pages, synonyms, acronyms, abbreviations, etc. This can be done by making use of different colors. دوستدار ایران بزرگ (talk) 20:07, 27 May 2013 (UTC)
Property proposal : collaboration with
I did not find the right page to do the proposition (too many intricated Properties pages)…
For People, I would suggest a "Collaboration with" property… for items like Q5933887 and Q5112818 which could simplify the treatment of Q12422250 -
This way, for single persons who regularly (or for a time) worked with another identified person, it would be possible to create a link, without having a problematic "two items in one" like Q12422250 - it could be used for all collaborations that are not "formalized" as an "organization" (i.e. a firm or a society). (ex : Fred Astaire & Ginger Rogers, but also collaborative writers, or comic strip authors, who often work as "scenarist/draughtsman")
Hi there does anyone know why wikidata isn't licensed CC-by-SA, considering the majority of the data is ripped from wikipedia articles. Emj (talk) 08:53, 26 May 2013 (UTC)
Yes, quite all data are taken from WP, but it is actually difficult to figure out a suitable license for, e.g.:
entity type = person; sex = male; occupation = painter; VIAF = 12345678
The amusing part about facts is that they can't be copyrighted (at least in the United States), whether or not they are attributed to some person or organization. :) --Izno (talk) 15:48, 26 May 2013 (UTC)
I'm active in OSM and we recently made the change from CC-by-SA to a database specific license, mapdata is also just data. But we still need to adhere to CC-by-SA. And yes if you take data from something that is CC-by-SA licensed then the share alike should follow with the data. (There are lots of legalities here). And the US doesn't matter much if you want to use the data anywhere else, especially if you want to distribute it as CC-0 when it can't be distributed as such in EU. Emj (talk) 15:57, 26 May 2013 (UTC)
Either way then, this is not the place to bring this up. From my point of view, a fact (the sky is blue) is not necessarily data (and I suspect those 'legalities' would recognize that). Shrug. I would suggest you find the contact us page to bug WMDE/WM about this. :) --Izno (talk) 16:12, 26 May 2013 (UTC)
"sky is blue" cannot be copyrighted where I live, true. But a database with statistics of the exact color of the sky each day in a year is copyrighted in 15 years where I live. Often it is enough if I can "attribute" the source, but I cannot do that yet. -- Lavallen (block) 16:20, 26 May 2013 (UTC)
I agree ; in France either, data (facts) cannot be copyrighted, which is normal because they are "facts", not "mind creations"… the entire database can be copyrighted, but certainly not the data it contains, as these are "objective facts" - imagine if name of places or people could be "copyrighted" (even CC-by-SA) - nobody could "use" them any more, which would make them impossible to "use" ;), and therefore "useless" Template:LOL --Hsarrazin (talk) 00:25, 28 May 2013 (UTC)
I think Lavallen did understand this, but I hope you also realize that interwiki links and infoboxes are not facts but a databases of facts, and collections of facts enjoy a 15 year protection from copyright law.. I'm not saying that you can not create entries in a database and linking to Wikipedia articles, I'm just saying if you copy those facts en masse from Wikipedia your database is subject to Copyright law. Emj (talk) 12:58, 28 May 2013 (UTC)
Merge.js now is added on Wikidata gadgets
Hi. I added merge.js on Wikidata gadgets. It is not complete yet, it can have bug, and you must check if merge is done well manually (file new bugs here) but IMO its functionality is important and vital for users :) –ebraminiotalk18:40, 26 May 2013 (UTC)
Can you add a selector to select the direction of merge? Item, now have a lot of links, so is better if we can select which item delete. --ValterVB (talk) 19:30, 26 May 2013 (UTC)
I know, but if the higher Q have 50 or 100 link to other item (ex. Christy Cabanne ) and lower Q have only 1 link, I prefere delete lower Q so I mustn't replace 50 or 100 link. --ValterVB (talk) 21:58, 26 May 2013 (UTC)
I agree with ValterVB, that it would be more practical to use the higher number in some cases. Especially if that item is used a value for properties in other items. It could save thousands of updates of other items, and I don't really see any arguments for using the lower number. Byrial (talk) 02:38, 27 May 2013 (UTC)
Selecting lower Qid as the destination is added by Ricordisamoa to the script so I let him if he wants disable it or not but I think it would be nice if there will be an option for target selecting strategy (first entered item (currently only), lower Qid, largest item serialized size, more linked item) –ebraminiotalk08:21, 27 May 2013 (UTC)
But real problem is on links to item. I think a bot must be used for moving links anyway (and target selecting strategy is just making the tool complicated). –ebraminiotalk08:38, 27 May 2013 (UTC)
Accept my thanks also...but it is taking a load of time to merge item with another and request the empty page for deletion. Is it normal? After fully developed will this time decrease?--Vyom25 (talk) 16:48, 27 May 2013 (UTC)
Now works well. But what to do in case of edit conflict while requesting for deletion? It doesn't allow to go for a second time as deletion request allow. It only shows error:edit conflict.--Vyom25 (talk) 17:35, 27 May 2013 (UTC)
I liked the "browse to the right item and click on the Merge button" system, that worked at the end of last week… why did you removed it ? it was simple, and no use to copy/paste the number of the item… was it too difficult to maintain ?
It can also be used for links to websites in infoboxes associated with organizations and anything else that has a website. Filceolaire (talk) 13:05, 28 May 2013 (UTC)
Can we create this with a string datatype for now; it really is important that we start to do more to record sources.
Alternatively can we have a generic comment property with string datatype which can have source info which can be transferred to other properties when these are created? Filceolaire (talk) 22:11, 28 May 2013 (UTC)
I would say no because it is stupid to do twice the same work. And there is no emergency to provide data as fast as possible: for a lot of item the list of properties to create are not yet developped. If you want to prepare the data importation better work with a bot with a definition of future tasks to perform once datatypes will be available. Snipre (talk) 08:32, 29 May 2013 (UTC)
Logos
Hello there. I recently created items such as this one for a logo. I have a few questions to ask about logo-based pages.
Are such pages appropriate for Wikidata?
How should these pages be named, and what claims would you suggest to use?
I have only created pages for current logos, however historical ones exist on various Wikipedias - should these be made into items? Again, how would one title an item like this?
See the discussion above on fair use. If we decide to only link to free licensed media then these links to fair use logos should not be included in Wikidata. Instead we should link to logos on Commons.
If we decide to allow fair use logos then the logos can be uploaded to Wikidata and this page of links to logos on other wikipedias is not needed; we just link to the version uploaded locally. Filceolaire (talk) 22:41, 28 May 2013 (UTC)
Sorry but I don't see the need of item creation for image: we have a datatype to link the images with the item. Why importing commons structure in wikidata ? And this is stupid because this concept assumes there is only one picture per language: there are more than one picture for some different languagee and no picture in some languages and finally most images don't need to be specified in a language to be used in a that language. Snipre (talk) 08:41, 29 May 2013 (UTC)File stored on wikipedias not on commons. Snipre (talk) 15:52, 29 May 2013 (UTC)
Since the RfC linked to above finished with a result of "no consensus" allowing such items to remain (for now at least), I would like to ask the above questions again (first one excepted of course). Thank you. Malpass93 (talk) 15:03, 29 May 2013 (UTC)
I think that's because the portuguese word for "Moldova" is "Moldávia", the name of the principality in english ("Moldavia"), except for the accent. But it's a guess... Jbribeiro1 (talk) 21:35, 28 May 2013 (UTC)
While correcting AC constraint violations, I found at least 2 articles that were objective duplicates on en (I guess there must be others on other projects too)…
What would be the correct thing to do, in addition to signalling the duplicate on the concerned project ? do we keep the dupe "until" it is corrected on the original project ? (I personally don't know the subject enough to perform a merge on the wp, especially in a foreign language). Is there a place to list those dupes, and therefore be able to check back on them from time to time ? is there a specific operation to perform on them ?
Pinging WD:IC may be a possibility. ALternatively, bringing a particular language's duplicates up on the equivalent language's project chat page might work also. If you know the correct merge templates on the projects in question, that's a third option.
the simple addition to list of merges can be very "slow", since there are articles that wait to be merged since 2006 on en ;) --Hsarrazin (talk) 19:47, 29 May 2013 (UTC)
Account creation and login redesigns
After months of testing, we're finally ready to enable the new designs for account creation and login. We plan on doing this today (May 29) around 23:00 UTC. If you're intersted in the background, there is documentation about why we did this and how we tested it.
As we announced on the blog a while back, you can try out the new look here before it's launched. (See the blog post for instructions.) If you see any lingering translation issues, please either fix them on translatewiki.net (where the volunteer translation for software is done). I am happy to help with any local customizations you think you might need, so please don't hesitate to reply here with any questions or requests.
Not all Wikimedia projects allow the upload of media under fair use. Particularly, Commons doesn't. Would it make sense to allow the upload of fair use files (I'm thinking covers of books or music albums, posters of movies, etc.) to Wikidata? Otherwise, what would we use if, for instance, we add an entry for a book that doesn't have an article on any of the Wikipedias that allow fair use media to be uploaded? --Waldir (talk) 18:18, 28 May 2013 (UTC)
Too bad. I was hoping Wikidata could eventually provide the data storage for a proper wiki-like universal database of book metadata. The alternative, OpenLibrary, seems to need some usability developments to become that. Perhaps I'll use FreeBase and later stuff can hopefully be imported to Wikidata. --Waldir (talk) 18:59, 28 May 2013 (UTC)
Indeed, that seems to imply that all published books pass WD:N. Is this interpretation agreed by the Wikidata community, or do some editors have a different interpretation of #2 regarding books? --Waldir (talk) 23:02, 29 May 2013 (UTC)
I don't see any use for fair use images on Wikidata... Besides, you are doing this the wrong way. An Exemption Doctrine Policy should be written first, then it should be proposed. If that gets accepted, then we can follow that by allowing local uploads. Plus, if you are suggesting what I think you are - adding local fair use images to items, then that is not going to work as expected anyway.--Snaevar (talk) 19:32, 28 May 2013 (UTC)
All that said, it seems to me to defeat the purpose of creating free information, and in fact, I suspect that if we went and looked at why Commons doesn't accept fair use imagery and data files, we would find many arguments against doing so here. --Izno (talk) 21:16, 28 May 2013 (UTC)
Fair use only applies in the USA. Some other countries have no equivalent right to reuse copyright images. Given that we want wikidata information to be reusable anywhere, it would be better if we didn't use 'fair use' images. We should wait for free licensed versions to become available or until fair use gets incorporated into an international treaty (even if we have to wait years). Filceolaire (talk) 22:34, 28 May 2013 (UTC)
The main reason why commons does not accept fair use imagery is that they are not allowed to do so, per foundation:Resolution:Licensing policy. More specificly, in the foundations licencing policy, there is this quote: "All projects are expected to host only content which is under a Free Content License, or which is otherwise free as recognized by the 'Definition of Free Cultural Works' as referenced above. In addition, with the exception of Wikimedia Commons, each project community may develop and adopt an EDP." So, as commons may not create an EDP, they cannot allow fair use content.
Fair use originates in the US, but other countries also allow fair use - those are Israel, Poland, South Korea and Hungary.--Snaevar (talk) 12:57, 29 May 2013 (UTC)
Commons is the project for media. I don't think Wikidata should be used to bypass Commons' policies. Fair use depends on the context in which the material is presented, while Wikidata AFAIU is context agnostic. - Soulkeeper (talk) 16:49, 29 May 2013 (UTC)
Getting the article name and not just the label
In order to link correctly at the local wiki, you need the page name in addition to the label; otherwise you risk linking to a disambiguation page (I.e. [[{{#property:P000}}]] returns [[Man Manson]] which links to a disambiguation page, rather than [[Man Manson (some guy)]], which is the link to the person we want). How is this accomplished? --Njardarlogar (talk) 05:10, 30 May 2013 (UTC)
If I am not mistaken, the table is just a leftover, after all violations have been fixed, see the original report: [20]. and subsequent manual removal of fixed items: [21] -- Make (talk) 11:00, 30 May 2013 (UTC) – PS: I removed any leftovers to make it clear that there is nothing to fix at the moment. -- Make (talk) 11:05, 30 May 2013 (UTC)
I've added more to this, discussing how we should deal with academic qualifications.
United Federation of Planets
I don't think that United Federation of Planets should be allowed for the country of citizenship property. It is currently used in many Star Trek related items, added by User:Shisma. I believe there should be an effort to remove this as it is not a valid entry. The property should be reserved for real people with citizenship of real countries. Del♉sion23(talk) 13:10, 18 May 2013 (UTC)
There are also problems with where old citizenship law (where you have citizenship of a city) and ancient countries (such as Ancient Egypt) fit in too.. Del♉sion23(talk)13:31, 18 May 2013 (UTC)
I think the problem is more P107 (P107) - it is organization (Q43229) and should be something like "fictional Organisation" the rest is fine, if you query fictional persons in a fictional country you should get a list of fictional inhabitants - thats fine. --FischX (talk) 13:33, 18 May 2013 (UTC)
I changed my opinion, it is completely wrong, it is not in Paris and not on Earth it is in a fictional version of Paris and the Earth that only refers to the real one. --FischX (talk) 13:42, 18 May 2013 (UTC)
For me that does not sound like a good solution, should everybody who makes a Query define "is fictional" = false? (and boolean types really do not fit for Wikidata) I thought thats GND for to define the general scope? --FischX (talk) 13:56, 18 May 2013 (UTC)
Why would it be beneficial to duplicate all properties for fictional entities? Seems like a waste. Also, if we set up different entities for each "fictional France", that would prevent things like automated compiling of w:Category:Fictional French people and such. Splitting everything to separate fictional entities would make about as much sense as having "former" versions of each property, in my opinion. --Yair rand (talk) 19:31, 19 May 2013 (UTC)
Yes, progress is the increase in accuracy. Wikidata is progress, and therefore there should be accuracy (fictional, real, mathematical, virtual, etc.). But without the microscope not see any bacteria or small parts of the object. Fictional/Real=microscope. Otherwise, you can all (person, place, events and) just to name 1 ID (Object). Fractaler (talk) 12:48, 20 May 2013 (UTC)
The fact is that there exist (in a sense) fictional things as well as real things. Fictional things are in the scope of Wikidata. What you're suggesting seems to be that every property should have a fictional counterpart just so that people who query Wikidata don't have to be aware that there exist items about fictional things and that they may get them in their query results unless they specifically exclude them. To me, that doesn't seem reasonable. Silver hr (talk) 22:17, 24 May 2013 (UTC)
"My two cents": concerning fictional things, we need to expand the GND ontology. See my comment to the discussion of the property is fictional. --Paperoastro (talk) 07:20, 28 May 2013 (UTC)
The GND is under the authority of the German National Library so it's not our place to modify it. And in any case, I'm sure we can come up with a solution without needing the GND at all. Silver hr (talk) 20:05, 30 May 2013 (UTC)
Obviously I didn't mean we have to modify GND, but I think it is a good starting point of what we should do here in Wikidata. But if you have any proposal, sure we can discuss it. ;-) --Paperoastro (talk) 20:28, 30 May 2013 (UTC)
racing, subclass of?
At the moment, racing Q878123 is a subclass of tournament Q500834. But, subclass of sport needs to be worked in somewhere, so that motorsport Q5367 comes under sport.
I'm not a domain expert, but going by Wikipedia I've made some changes. In motorsport (Q5367) I've changed "subclass of: racing" to "subclass of: sport" since not all motorsport is racing. In racing (Q878123) I've changed "subclass of: tournament" to "subclass of: competition" since not all racing is a tournament--a race can be between 2 competitors and a tournament implies a largeish number of competitors. If you want to connect motorsport to racing, I suggest you create a "motor racing" item (there is one now, but it's for a disambiguation page) and make it a subclass of both motorsport and racing. Silver hr (talk) 23:22, 24 May 2013 (UTC)
I put "racing" as a subclass of "tournament" because "racing" refer to articles called "race" in other languages, and "tournament" refers to "competition" in other languages. In contrast, the item "competition" (Q476300) is often a disambiguation page, since it refers to the concept in biology, sociology and other fields. In other words, the term "tournament" is used in English as a synonym of competition.
I think "racing" should be reverted to a subclass of "tournament", and "tournament" should be a subclass of "event". --NaBUru38 (talk) 02:27, 30 May 2013 (UTC)
Ok, I read some Wikipedia articles from the item "tournament" (Q500834), and I found that four of them were titled "competition", matching with generic definitions "game that results in a winner". Actually, three of them are titled "sports competition", but the articles don't seem to exclude other types of games (chess, poker, etc).
So, I've moved those four articles to a new item called "competition". Now "racing / race" is a subclass of "competition". Now, several items on competitions that aren't tournaments must be fixed. Are you ok with that? --NaBUru38 (talk) 02:52, 30 May 2013 (UTC)
I don't know how well-aligned the meanings of the various articles in different languages are so I wasn't aware of anything wrong. The separate item you made for the narrower meaning of competitive sports/game event (sports competition (Q13406554)) seems OK to me. Silver hr (talk) 21:54, 30 May 2013 (UTC)
The Dutch Wikipedia had on its own more than 14.000 interwikiconflicts. I have created weeks ago on nl-wiki a project page where all those interwiki conflicts are mentioned and users started to clean up those conflicts. nl:Wikipedia:Interwikiconflicten_oplossen
Thanks to a botowner I was able to have such list, but this should have been made easy with a tool! + for every Wikipedia!
Besides interwikiconflicts there are also a lot of pages on which users added one interwiki with the creation of the page, but after years it appears that no bot has ever put the interwiki to that page on the other language version + if there were interwikis on that page in another language that those interwikis wern't placed on the newly created page by a bot.
I also notice that if interwikis were connected between pages on several Wikipedias, that not on every language variant all interwikis had been placed by bot, but only some of them...
This has as result that with the moving of interwikis from the local articles to Wikidata, that if the bot is focussed on a certain project - which does not have all the interwikis - the bot also doesn't move all the interwikis from pages in another language but only moved the ones which were there on the focus project.
A lot of bots have/had difficulties with synonyms of namespaces. On other language versions of Wikipedia, the template namespace for example has besides the local name also the generic "Template" name. If someone added an interwiki with the non-local namespace, the bots have ignored them. This also counted for changes in the namespace name on a wiki.
I almost fully cleaned the template namespace from many left interwikis. I think I will continue with the category namespace next. I noticed that users from other Wikipedias also want to clean up their articles and other namespaces from local interwiki's, but they miss the tools!
On a lot of projects the templates for infoboxes and others have sub pages like /doc where interwikis are added. Mostly the interwikis are already on Wikidata, but still are the interwikis also local on the /doc page. Users on various projects need a tool to know where this is the case and/or a bot is needed which is able to remove all these interwikis from these subpages if the core page already has these interwikis on Wikidata.
On a lot of projects there are permanently projected pages which have interwikis on them. These should also be removed from these pages and moved to Wikidata. The local communities need a tool to know which projected pages still have interwikis that can be removed from these pages.
I also notice that a lot of island groups of interwikis are on Wikidata. An island group of interwikis means that a certain subject has two items on Wikidata (with two groups of interwikis) while it should have only one item. We need a tool which can suggest which two items may be the same.
Also many pages do not have any interwikis, nor locally, nor in Wikidata, while there are articles about that same subject in other languages. Communities need tools to detect those articles to be able to connect those pages to those on other language Wikipedias.
Some years ago we had a user who had created a tool which suggested for categories a possible interwiki, if the category was like Category:<subject in country>. What the tool did was, it checked the interwikis of the categories the category was in, compared the names, checked for the existing of that category and then suggested it to the user who had to check and decide.
Good read... A general problem faced by us from Gujarati wiki is of duplicate items. See this list. It was created from database dumps by User:Byrial. It is helpful. I use merge tool created by User:ebraminio and User:Ricordi Samoa. That is very helpful. I am sure other wikis also face one or the other glitch.--Vyom25 (talk) 17:44, 31 May 2013 (UTC)
Oppose. In infoboxes specific person is much more useful. Infovarius (talk) 06:15, 30 April 2013 (UTC)
Support I agree with the principle "no redundant data", we just have to be careful in the cases when several parallel systems of division applies to put in in the smallest (available) unit within every system. Also: do we already have a way to query needed data from the available data, or is it still a planned feature? The help pages didn't help me to much (yet)...--Šlomo (talk) 10:39, 1 May 2013 (UTC)
Deleted the item. John F. Lewis (talk) 16:46, 2 May 2013 (UTC)
Neutral First we need better categories like mentioned. Some of the allready stated go hand in hand and can not get split. Conny (talk) 15:42, 1 May 2013 (UTC).
Weak oppose per Izno. --Ricordisamoa 22:28, 7 May 2013 (UTC)
AutomaticStrikeout 20:49, 13 May 2013 (UTC)
Weak support I don't use this feature, and don't care much of it, but someone could find it useful. --Ricordisamoa 04:37, 14 May 2013 (UTC)
Comment I am not sure that "What needs to be done is that anytime (for any property) that two different sources give the same value, they are listed as two separate values", at least the requires further thought and discussion. Note that the software is designed to allow several sources by statements (and several statements within each of these sources). In your example, we need separate statements not because the sources are different, but because the real meaning is (or equivalently, because the should have different qualifiers). I am not sure that it has any necessary connection to the number of source. The same source can compile several critical reviews, and conversely the same review can be provided at several different places. - Zolo (talk) 07:33, 23 May 2013 (UTC)
