Wikidata:Project chat

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

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



Move sitelink?[edit]

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

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

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

We're reading here ;-) There is also Wikidata:Contact the development team. We're working on improving the interface changes we made at the moment. As for the move gadget: Best check the talk page of the gadget and talk to the person who wrote it. --Lydia Pintscher (WMDE) (talk) 07:07, 14 October 2014 (UTC)
I (the creator of the gadget) thought that moving it into Wikibase itself will be much easier than having to create another hack to inject all the [move] buttons. Therefore I created bugzilla:72019. -- Bene* talk 07:47, 14 October 2014 (UTC)
Thank you both. I would like to point out that the move gadget is not only useful for people who want to move sitelinks. It is also advantageous for people who want to check the changes on the items on their watchlist. The gadget leaves an edit comment with a link to the new item. If sitelinks have been moved 'manually', you don't see why they disappeared on the old items.
Last week, when I wanted to move 2 links, I forgot to press 'save' when deleting the links on the old item. Therefore adding them on the new item resulted in an error. I spent 10-15 minutes in new tries. Bever (talk) 07:23, 21 October 2014 (UTC)

Suggested interface change[edit]

The new edit interface is horribly slow, but it would be nice to have the save/cancel link at the bottom, instead of having to scroll all the way up to the top. The edit link at the top is fine, as is the add link at the bottom, but neither are very clear as to what you are saving, or which section you are editing. With the old interface the links were right next to the item you were editing and it was clearer what you were going to do. 76.24.193.7 00:45, 12 October 2014 (UTC)

For more than I year I am asking users to add their newly written articles to Wikidata. That appears to be successful. However, in the past week I get more and more reactions from users who are no longer able to add site links of their newly written articles. They do not understand any longer how to add or save this on pages. Romaine (talk) 02:06, 12 October 2014 (UTC)
Not surprised. There is no obvious link to enable the magic edit phenomena. The edit/add/save/cancel need to be inside a highlighted (colored) box. An add link at the bottom would be very helpful, so that you can skip the "edit" step, and get into the edit functionality by clicking "add", which is intuitively obvious. And you could really make sure that people added links if there was a link on new pages where it says "Languages" to "Add Wikidata link" if it was a new article, but I am not sure how you would direct anyone to find a corresponding page, although maybe just telling people to search for it would work. This would need to only appear for a page in article space. 76.24.193.7 03:34, 12 October 2014 (UTC)
My recommendation is to scrap the new UI as a bad idea. It is horribly slow to watch 150 entries close before it gets to the one you added. I am sure it works fine with articles that are only in 3 languages, but it is a given that the goal is to have every article, well at least 100,000 of them, in every language, and the idea of adding a page to one that has 250 other entries is a nightmare. 76.24.193.7 06:12, 12 October 2014 (UTC)
Also, if you have multiple tabs open and switch to a different tab, the save aborts. It waits a while for you to come back, and if you do not, it aborts the save. It insists that you watch the little boxes closing. 76.24.193.7 08:20, 12 October 2014 (UTC)
How slow is the new UI? It just took me 20 minutes to add one link. And I still have 20 more to add. 76.24.193.7 03:08, 13 October 2014 (UTC)
And it took 2 hours and 41 minutes to add them, about 3 minutes for each one. The idea that anyone but a vandal would ever have any reason to edit all of the links is preposterous. How long should that task have taken? 10 minutes tops. And guess what? If you turn off javascript it does take 10 minutes - you can not edit links but it only takes 10 seconds instead of three minutes to add each link.
The new user interface just needs to be scrapped. It is not clear what the edit link is going to do - and 9/10 times you do not want to edit a link, but want to add a link, and there are add links all over the page, just not one in the box down at the bottom for a new link. When you do click edit, a question mark appears to explain what it does, but why was that not there next to the edit link? So you have to scroll down to see if there is a link, scroll all the way back up to the top to click edit wait 15 seconds for anything to happen (most people will have given up and gone back to doing something else after 8 seconds), scroll all the way to the bottom to click add, wait another 15 seconds, add the entry, scroll all the way up to the top to click save, wait about 30 seconds (if you leave the page it will not save). Elapsed time: 3 minutes. 76.24.193.7 18:14, 13 October 2014 (UTC)
I agree, the new interface is really a PITA for changing a link to another item, when there are 2 items entangled… before, it was possible to remove a link in item 1, then paste it in item 2 - then remove another link and paste it... etc.
now, you need to remove all links and save and go to item 2 and add… and you have a big chance of forgetting a link, or you do it one at a time, and it takes… hours… :(
as for adding new links from a site, it's now quicker to create a new item (even knowing it already exists), and then merge it in the existing item… which, I guess, is not considered the best solution :)
would it be possible to activate or de-activate new interface in prefs, supposing some people really prefer the new one ? --Hsarrazin (talk) 21:08, 14 October 2014 (UTC)
We are working on making the current one better this sprint and next. The next tasks are fixing the edit conflict issue and making the edit link float so you don't have to scroll so much. We'll also be adding a empty line for a new sitelink by default so you don't have to click add in addition. See http://sb.wmflabs.org/t/wikidata-developers/2014-10-14/ for the current sprint. --Lydia Pintscher (WMDE) (talk) 09:10, 15 October 2014 (UTC)
That is preposterous to create a dummy item and then merge it, but I doubt it is faster than the 10 seconds that it takes to add a new language by just turning off javascript. 76.24.193.7 15:57, 15 October 2014 (UTC)
From my understanding there is no dummy items being made. Please ensure you correctly understand what you are complaining about in future. John F. Lewis (talk) 16:00, 15 October 2014 (UTC)
As I used the word "dummy", I can explain what I was referring to: "it's now quicker to create a new item (even knowing it already exists)". The new item is a "dummy", because it is just used as a placeholder to store the wiki information so that it can be merged. But all of the above is moot as long as I can simply turn off javascript and quickly add items. But why should I have to do that? Why should the interface essentially not work with javascript? And how many others who want to add something know that essentially the only practical way to do that is by shutting off javascript? 76.24.193.7 22:08, 16 October 2014 (UTC)
well, many people (and bots) create items from sister project links, without bothering to search whether the item already exists - I did not tell that I was doing it, just that it was quicker, considering the GUI, now… :)
and it's much better to merge 2 items, than to just move a link, leaving a blank item, that needs to be removed afterwards ;) --Hsarrazin (talk) 23:16, 16 October 2014 (UTC)
Then the instructions need to be more clear, and it needs to be easier to perform a merge. As it is, all you see is a brief error notice that flashes on the screen which may or may not be there long enough to click on to see what caused the error. All I really care about is getting a link in the right place. How it gets there is not important to me. And I will never get back the 2 1/2 hours that I wasted adding 20 links when it should have taken 10 minutes, and would have, if I had known about shutting off javascript to make the interface work properly. 76.24.193.7 23:54, 16 October 2014 (UTC)
I am also having a hard time seeing any value to creating a duplicate entry that is useless. If you want to create a wikidata link yes a bot or anyone can just create a new one, but it is useless, unless you are certain that none of the other 286 wikis have an article on that subject, because it does not link the wiki from any of the articles in the other wikis, and less than useless, because even though there actually is an article in that wiki on the subject, the fact that it is not linked properly tells me that there is not, and all I do is waste more time, creating the article, and then after I have linked that article, find out that there is an article in that wiki, and have to change the article that I created to a redirect, and edit the interwiki link, which of course I can not do because the other article goes to its own dummy (yes there is that word again) wikidata page. All of that time would be saved if in creating the wikidata link it was to the right place. And half of the time would have been saved if the article was created with no wikidata link, instead of to its own "dummy" wikidata page. 76.24.193.7 00:14, 17 October 2014 (UTC)
I'm adding myself to the list of users bewildered by the new interface. Removing the Save/Cancel buttons is not very intuitive, nor is the placement of the Edit link. Inserting a new language is painfully slow when adding it by typing text. It is a bit faster when just pasting a text from memory. I'm crossing my fingers that a solution is on its way.--Paracel63 (talk) 11:36, 17 October 2014 (UTC)
Would anyone care to walk me through how to merge Q16037178 (Q16037178) with Alaska (Q797), not logged in, and not using Javascript? 76.24.193.7 14:07, 17 October 2014 (UTC)
try Special:MergeItems --Pasleim (talk) 14:21, 17 October 2014 (UTC)
No go. "Failed to merge items, please resolve any conflicts first.
Error: Conflicting labels for language sa." But Help:Merge says to do exactly what I had been doing (but it requires javascript), and then adding {{Delete}} to the page that you merged from. "A merge can be done either automatically or manually by moving sitelinks and statements into one item, and then requesting the deletion of the obsolete item(s)." 76.24.193.7 14:37, 17 October 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────But now how do I go back and delete the half dozen or more pages that I have merged? I see no way to edit the page to add the delete template. See invalid ID (Q16042576). 76.24.193.7 14:48, 17 October 2014 (UTC)

You can't merge Q16037178 (Q16037178) with Alaska (Q797). The problem is that Alaska (Q797) has already a link to sawiki and it's not possible to add a second sitelink to the same wiki. That means you have to merge in sawiki the articles sa:अलास्‍का and sa:अलास्का. For items you have already successfully merged, you can put a request for deletion on WD:RFD. The template {{Delete}} should only be used for non-item pages. --Pasleim (talk) 15:12, 17 October 2014 (UTC)
Not any more. I deleted the link to the dis page on sawiki from Q797 and tried it again, but it still gave the same error. My edit was deleted. The second page is the more developed page. I thought the first one was a dis page, but it might not be. 76.24.193.7 15:37, 17 October 2014 (UTC)

Two identical properties?[edit]

What is the difference between birth name (monolingual text) (P1477) and name in native language (P1559)?--Shlomo (talk) 08:36, 12 October 2014 (UTC)

birth name (monolingual text) (P1477) refers to for example someone's maiden name, or the name they were born with before they were adopted (or went into witness protection). It is also used for example for Barack Obama. Bill Gates and Bill Clinton, though, use birth name (Deprecated) (P513). name in native language (P1559) refers to for example if someone immigrates to an English speaking country and changes their name to a more Anglicized name. This is pretty common, and sometimes happened, for example, at Ellis Island simply because the immigration officer did not understand the name or the spelling of the name that someone had. The word "monolingual" in P1477 implies that there is no change in the language, for example, Smith to Robbins, and the words "native language" in P1559 implies that the name was changed from one language to another. For example Schmid to Smith, but more commonly to remove letters with accent marks or any non-English letters. 76.24.193.7 00:41, 13 October 2014 (UTC)
Does it mean that birth name (monolingual text) (P1477) should be only used for the very first variant of the name after the birth (not many people have a name in the moment of the birth...) and only when a later change of the name in the same language occured? And name in native language (P1559) should be used only for the "current" (What does it actually mean? Last known?) name and only when the person speaks this language at a native-speaker level and only when the person has had a name in another language before? First, this is is not clear from the descriptions of the properties, and second, this concept doesn't seem very useful. What if a person changed his/her name several times? What if we can't figure out which languages at which level does/did the person speak? What if a person who has a name in native language (P1559) statement changes his/her name again in the same language? Etc. etc. Wouldn't be easier to have one "full name" multilingual (or even monolingual in the meantime) property and use the qualifiers to show that this is the "birth" name (succeeds (P1365) set to novalue), the current name (succeeded by (P1366) set to novalue) a.s.o.?--Shlomo (talk) 09:31, 13 October 2014 (UTC)
name in native language (P1559) is probably most useful for users with non Latin scripts. For the Bill Gates example mentioned, this would be:
Have a look at it.--- Jura 10:48, 13 October 2014 (UTC)
I don't question the need of a full name monolingual property (IMHO a multilingual one would be more suitable, though). I just asked about the reason, why we have two of them and given the answer above I proposed reducing it to one property using qualifiers. I don't mind being it the name in native language (P1559), if we only cancel the strict requirement that it must be the "current" name in the "native/native equivalent" language of it's bearer.--Shlomo (talk) 16:28, 13 October 2014 (UTC)
I am not sure there is any benefit in combining two fundamentally different properties. 76.24.193.7 18:29, 13 October 2014 (UTC)
I agree. Birth name is the first name a person has, before marige and other name changes. /ℇsquilo 06:15, 14 October 2014 (UTC)
I still can't see what makes the "birth name" so different from all other names the person had during his/her lifetime except it is the first one in a row. We don't have properties for "first place of residence", "first nationality", "first school attended", "first husband" etc. either. But if there's a consensus that we need an extra property for a "birth name", let it be so. Let birth name (monolingual text) (P1477) be the "birth name" and name in native language (P1559) any full name of a person supported by sources no matter if current or abandoned, in any language no matter if and at what level spoken by the person in question (that's what qualifiers and rank are for).--Shlomo (talk) 08:52, 14 October 2014 (UTC)
@Shlomo The "birth name" is generally official - the one written on passport if the person never (officially) changed his/her name - contrarily to all pseudos a person uses... birth name is the name the people was registered at birth… contrarily to all other names, that can be (more or less, depending on country) freely used.
birth name (monolingual text) (P1477) is the contrary of pseudonym (P742), while name in native language (P1559) is to be used for cross-alphabet namings… russian/chinese, etc. — this is not at all the same use, even if birth name (monolingual text) (P1477) has been used in place of name in native language (P1559) before its creation :)
but I agree… name in native language (P1559) should not be monolingual - it should be string as it has only one language to receive… normally…
if you look at Mark Twain (Q7245) from a russian pov (ru link), you'll see that they display the name Марк Твен and the P1559 : Mark Twain, and the P1477 : Сэмюэл Лэнгхорн Клеменс (in russian), since it's monolingual… ;) - it would be exactly the same (reversed) for a Russian writer in en or fr or de… --Hsarrazin (talk) 20:29, 14 October 2014 (UTC)
If it should be an opposit of "pseudonym", then it should be named "official name", not "birth name" and an accent should be put on the officiality (whatever does it mean before 19th century...) of the name, not on the fact that it was the first name after person's birth. Anyway, it seems that your conception of these two properties is quite different from the one described above by 76.24.193.7. That should be cleared before two different robots with different conceptions start mass adding contradicting statements using these properties.
Alas, I don't understand what you mean by "cross-alphabet namings". Neither do I understand what is your problem with Mark Twain (Q7245): For P1477 I see two statements: the English one and the Russian one added by you... Of course both without any source, in full accordance with local habit... Are you referring to the Wikidata item here or to some other Wikimedia project using the data?
And about the string datatype: It should be used for sequences of characters not associated with any language, like alphanumerical identifiers, codes etc. Since names of person's are always associated with some language, we should use mono- or multilingual text datatype for them.--Shlomo (talk) 22:15, 14 October 2014 (UTC)
Ok, strike the part about the string type : I did not clearly understand the change of type, and re-read the use of types… but this type is so recently introduced, that I was still under the understanding of the previously used property :) --Hsarrazin (talk) 08:37, 18 October 2014 (UTC)
Official name is less useful. It would work for someone who had never changed their name, or someone who had been knighted, like Paul McCartney (Sir James Paul McCartney) but commonly used a nickname. An actor is more thought of as having a real name than an official name. And any time you change your name, the new one becomes your new official name - all of your names are official names, just at different times. Sharon Stone's name is "Sharon Yvonne Stone", there is currently no property used to indicate that. Bob Hope was born "Leslie Townes Hope", and uses birth name (Deprecated) (P513) for that, but also given name (P735) for his stage first name, Bob, which is incorrect, because a given name is only the first name that you were given at birth, so it should be "Leslie" or "Leslie Townes". A "given name" is a name "given" to you at birth, as opposed to your last name, that you inherit, and not a name that you give yourself. Bob Hope is a stage name, and "In 1929, Hope informally changed his first name to 'Bob'", so he never officially changed his name, but simply used Bob Hope as a stage name. Martin Sheen also uses P513, but not his son, Charlie Sheen, which does not have the property yet. Deprecated is not really a very good word to use, unless they have actually changed their name to something else (officially, not like Bob Hope). 76.24.193.7 03:53, 17 October 2014 (UTC)
a thought I just tonight, about why the "birth nam" is so different from all other names the person had during his/her lifetime : and see that 76.24.193.7 had the same above : the "birth name" is "objective" relatively to a person, contrary ot all other names : it was not chosen by the person, and can be considered as "permanent reference" :) , whilst all other names are the result of choices : nicknames, wedding, legal change of name, moving from a country to another… --Hsarrazin (talk) 08:32, 18 October 2014 (UTC)

Complex query[edit]

How would I go about finding a list of all biographies (instance of=human) which only exist on the Welsh (cy) Wikipedia? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:20, 14 October 2014 (UTC)

@Pigsonthewing: I'm not sure, but you might be able to do it with ToolScript. But since you ask, here is a list made using the latest SQL dump and old fashioned Python:

 – The preceding unsigned comment was added by Haplology (talk • contribs).

@Haplology: That's very useful. thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:56, 15 October 2014 (UTC)
@Pigsonthewing: If you want a dynamically generated (and updated) list, you can get a rough approximation using the Wikidata Query API. You can't ask it for "no other wikis", but you can get it to look for links to cywiki and then cut out any with links to a given set of wikis.
CLAIM[31:5] AND LINK[cywiki] AND NOLINK[enwiki,frwiki,dewiki,eswiki,itwiki,ocwiki,ruwiki,gawiki,glwiki,gvwiki,nlwiki,svwiki,arwiki,ptwiki,brwiki,tlwiki] (autolist link)
There will be a couple with links to wikis I haven't spotted, but it'll be easy enough to add them to the list and rerun it. Andrew Gray (talk) 17:08, 19 October 2014 (UTC)

Two new badges[edit]

Two new badges: Featured list and recommended articles - are now available. Thanks to everybody who helped creating them.--Ymblanter (talk) 07:23, 15 October 2014 (UTC)

Mediawiki help needed[edit]

A related question to experts. In the Russian Wikivoyage, where I am one of the admins, FA's and GA's (stars and guides) from other Wikivoyages are shown on the left sidebar in the same way as they are shown in Wikipedia, even though we did not edit mediawiki for that. Can somebody explain me how we can modify mediawiki so that recommended articles are also shown (say as bluestars)? Thanks in advance.--Ymblanter (talk) 18:38, 15 October 2014 (UTC)

Probably m:Wikidata/Development/Badges#Requests_for_different_icons is what you are looking for. --Stryn (talk) 20:16, 15 October 2014 (UTC)
The default icon for the client was forgotten. Hoo is working on it right now. Should show up today or tomorrow. --Lydia Pintscher (WMDE) (talk) 20:20, 15 October 2014 (UTC)
Thanks to both of you.--Ymblanter (talk) 20:31, 15 October 2014 (UTC)

Populated places, administrative districts, states and territories, by year[edit]

In the English Wikipedia there are categories for en:Category:Populated places by year of establishment and en:Category:States and territories by year of establishment, such as en:Category:Populated places established in 1976 and en:Category:States and territories established in 1976.

In the French Wikipedia there is fr:Catégorie:Division administrative par date de fondation (which literally is just "Category:Administrative division by date of foundation") such as fr:Catégorie:Division administrative fondée en 1976. Some years of these French "administrative division"-categories are linked to "populated places" and some are linked to "states and territories". I would like to clear this up, so my question is, to which category should the French categories be linked? Or maybe it is so distinct that French should be linked to neither? - FakirNL (talk) 12:31, 15 October 2014 (UTC)

P.S. The Esperanto category eo:Kategorio:Administraj unuoj laŭ fondodato should probably follow French if consensus is reached.
in fact, the French categories are the sum of both… so I don't see how it could be linked to one OR the other…
another solution would be to propose a modification to fr ? good luck :D --Hsarrazin (talk) 23:23, 16 October 2014 (UTC)
Delinking sounds like best solution as of now. Anyone else? - FakirNL (talk) 13:15, 17 October 2014 (UTC)
another solution would be to propose a modification to en?  :D --Infovarius (talk) 03:58, 18 October 2014 (UTC)
Modification to EN, to ES, LA, NN, NO, SCO, SV, TR and several others. Sounds like a great plan! 718smiley.svg - FakirNL (talk) 11:09, 18 October 2014 (UTC)

Astronomical objects by year the same as asteroids by year?[edit]

In quite some language projects, astronomical objects are categorized by year of discovery. Examples:

and some others. But in Spanish and Latin Wikipedia, they have a very similar category that only allows asteroids (so, for example, no moons), they are like:

Are these categories similar enough to be linked together (as they are in about 127 cases), or is the difference so fundamental that Spanish and Latin are not supposed to be linked to the rest (as they are in about 44 cases now)? - FakirNL (talk) 13:12, 15 October 2014 (UTC)

P.S. Russian Wikipedia has both, so ru:Категория:Астрономические объекты, открытые в 1866 году (astronomical objects) and subcategory ru:Категория:Астероиды, открытые в 1866 году (asteroids). This would be an argument for splitting up the WD-items. - FakirNL (talk) 13:17, 15 October 2014 (UTC)
I'm starting to split off the items in one for "astronomical objects" (with English, French, Italian, Norwegian and Russian) and one for "asteroids" (with Spanish, Latin and Russian). - FakirNL (talk) 16:36, 18 October 2014 (UTC)

"The time allocated for running scripts has expired."[edit]

Hello, I created one middle size report. Error "The time allocated for running scripts has expired." occurs on it often. I created optimized versions of {{Q}}, {{P}}, Module:Wikidata ({{Ql}}, {{Pl}}, Module:Labels). Effect is a little. I can split the report to many pages or insert labels statically. But these ways are not desired. Can I do something more before contacting to development team? — Ivan A. Krestinin (talk) 19:25, 15 October 2014 (UTC)

We're currently working on optimizing the lookup of labels. I hope this will also speed this up but I am not entirely sure. The bug for that is bugzilla:71169. It is in the current sprint. --Lydia Pintscher (WMDE) (talk) 20:23, 15 October 2014 (UTC)

Source code for JSON dumps?[edit]

Where is the source code used to produce the JSON dumps at http://dumps.wikimedia.org/other/wikidata ? I'm having some problems decompressing the gzip, and I would like to how the gzip is created. Jefft0 (talk)

What's the issue you are seeing? @Hoo man: can maybe help with that. --Lydia Pintscher (WMDE) (talk) 14:07, 16 October 2014 (UTC)
I'm trying to use the open source DotNetZip library to read the JSON gzip file, but it fails. If I use the Linux command line to gunzip and gzip again, then DotNetZip is able to read it. I want to file a bug report but I can't refer them to a 3 gigabyte zip file. So I wanted to use the same tools to produce a small sample file which may have the same problem. (I don't think the problem is with the file size, but with the compression algorithm.) Do I contact @Hoo man: directly? Jefft0 (talk)
Did you had a look at dotnetzip issues? Seems to be a problem of the library you are using. --Succu (talk) 21:22, 16 October 2014 (UTC)
Hi, the gzipped json dump you can download consists of a few gzip archives which are simply concatenated (that is because we create the dump using multiple processes and then merge the end results). That is a well supported feature of gzip... if it doesn't work with your gzip implementation I'd suggest to use gnu gzip to unpack the file. Cheers, Hoo man (talk) 21:59, 16 October 2014 (UTC)

Constraint violations and referencing - need your input[edit]

Hey :)

Our experience with the team of HPI students working on the entity suggester was very good so we decided to take on another team of 6 students from there. I'm very happy about that. They'll be working with us for 6 months. The overall topic they will be working on is data quality and trust. It splits into 3 large areas:

  • improving constraint violation reports and expanding them
  • making it possible to check against 3rd party databases
  • making referencing data more user friendly to encourage more references

That's what we have so far. More planning and brainstorming will happen over the next weeks.

I started 2 pages. It'd be awesome if you could provide your input for them on the current situations and what you'd like to see there:

Cheers --Lydia Pintscher (WMDE) (talk) 14:04, 16 October 2014 (UTC)

Discussion about statements on properties[edit]

Hi, does anyone know if some discussion was started somewhere about which statements should be added to properties, once ongoing development Statement on properties is deployed? -- LaddΩ chat ;) 22:34, 16 October 2014 (UTC)

The list of proposed properties for statements on properties is at Wikidata:Property_proposal/Pending/4. This links back to a discussion archived at Wikidata:Project_chat/Archive/2013/10#Property_Metadata. On bugzilla:49554 Lydia stated last April that this feature was nearly ready to roll out so we might see it soon. Filceolaire (talk) 22:00, 17 October 2014 (UTC)

In addition to the properties listed there I think we also need an 'inverse property' property to identify the inverse property of the current property. If this links back to the current property then it is a symmetric property (like 'sibling').
We also need to identify properties like 'subclass of' or 'is in the administrative terrritorial entity' where if A subclass of:B and B subclass of:C then A subclass of:C as distinct from properties where this doesn't apply like 'parent of'. Filceolaire (talk) 22:15, 17 October 2014 (UTC)

NEED WIKI MAIL/CHAT[edit]

without write something, i think you know what i mean  – The preceding unsigned comment was added by Jeksonrjg (talk • contribs). 01:11, 17 October 2014‎

There is a link at the top to the IRC channel for this wiki, if you have not set an e-mail address for your account you will not be able to e-mail anyone. 76.24.193.7 03:17, 17 October 2014 (UTC)

New UI is very bad[edit]

The new UI is very bad. There are a lot of additional clicks necessary and the buttons are far away on long pages so you have to scroll very often. --Fomafix (talk) 08:12, 17 October 2014 (UTC)

As I already explained further up: We're working on improvements. This is just a temporary state. Expect it to become better with the next deployment and the one after that. --Lydia Pintscher (WMDE) (talk) 08:20, 17 October 2014 (UTC)
What's up with not just admitting that it is a disaster and rolling it back to the state that worked? 76.24.193.7 13:23, 17 October 2014 (UTC)

Listed structures[edit]

In the UK, historic structures ("monuments"; including but not limited to buildings, telephone boxes, war memorials, statues, urinals, bridges) can be "listed". I recently changed the labels on Grade II* listed building (Q15700831) and Grade II listed building (Q15700834) from "Grade [x] listed building" to "Grade [x] listed structure". I have been reverted. We now again have items like Statue of Edward Jenner (Q18228702) described as instances of "buildings". The labels should be changed back to use the more generic word "structure". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:55, 17 October 2014 (UTC)

You should write this comment on items discission page at least too.--Oursana (talk) 14:52, 17 October 2014 (UTC)

Authority control gadget[edit]

I have had the "Authority control" gadget enabled for several weeks, but have just realised that it is not working, even on a new computer. Can anyone help, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:28, 17 October 2014 (UTC)

I have the same problem, it hasn't been working in a long time... when I need to see the link I append "?debug=1" to the url, but that is not very user-friendly... --Micru (talk) 23:13, 17 October 2014 (UTC)
Nice trick! Possibly someone more familiar with MediaWiki:Gadget-AuthorityControl.js might have a look. Item Q47484 can be used for testing, it has a fair number of authority control links. -- LaddΩ chat ;) 15:16, 18 October 2014 (UTC)
@Pigsonthewing: working fine for me and gives the right wikilinks. And to clarify, the linking gadget, and magnus's tool with a similar name are both functioning for me.  — billinghurst sDrewth 04:07, 20 October 2014 (UTC)

Alternative uses of the monolingual text datatype?[edit]

There is a specific need to link with Wikisource index pages, it is not possible to do it through sitelinks, since they link to the text itself, so I was wondering if it might be suitable to use a monolingual text to link with the Index: page. More info here: Wikidata_talk:Wikisource#Index_pages_and_text_quality--Micru (talk) 23:09, 17 October 2014 (UTC)

Edit existing wikipedia links[edit]

Is there any possibility to edit an existing wikipedia link without using API-calls/client side scripts? In pure HTML there is only a "Add" link, but no link to edit the data field. (some weeks ago there was a edit-link to a special: page to edit/modify existing entries. this edit link vanish).--Wdwd (talk) 14:33, 18 October 2014 (UTC)

Currently the User Interface requires Javascript to edit links. You can add links without Javascript, but not remove or edit them now. But if you list here the edit that you want made, someone will be able to make it for you. 76.24.193.7 06:30, 21 October 2014 (UTC)

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

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

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

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

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

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

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

I believe there is a need to distinguish US-english from British-english in some occations to avoid confusion ("football" is a very good example). The same need probably exists for Brazilian vs. Portugese portugese. As a matter of fact we do distinguish between Nynorsk (Q25164) (nn) and Bokmål (Q25167) (nb). /ℇsquilo 12:35, 20 October 2014 (UTC)
No it isn't. In Australia there are five types of football — Australian Rules, Rugby League, Rugby Union, Soccer, Gridiron; and all played by footballers — and depending your state and persuasion will depend on which is your priority football, oh and Rugby Sevens. Then take New Zealand, South Africa, Samoa, Fiji, Papua New Guinea, where else would you like that don't have their own variations of en-xx. False realities. Cover all bases, and make sure that your explanations cover it.  — billinghurst sDrewth 13:13, 20 October 2014 (UTC)
A property to indicate en-US, en-BR, en-CA, en-AU, en-NZ (is there also an en-India?) is valuable, but what name is used for the namespace is unimportant and can be in any flavor of English. If there is a subject that is native to one flavor, that is the one that should be used, but otherwise it is really just arbitrary. 76.24.193.7 04:52, 21 October 2014 (UTC)
For football, the full name 'association football' could be used to avoid confusion. ('Soccer' would be a bad choice because this word is mostly used in countries where it isn't the favourite sport.) Of course 'en' should apply to all main variants of English. Bever (talk) 07:32, 21 October 2014 (UTC)

It doesn't let me delete data from Q16162716, please help.[edit]

Hi,

I'm trying to add an interlink between the article "Hard Rock Sofa" in the English Wikipedia and "HardRockSofa" in the Russian one. The former has a data page of Q18156495 where there is the English article and the Korean one already added there. When I tried to add the Russian article manually, it refused my edit pointing out to Q16162716. But when I went there to remove the Russian article from there to put it in the 495, it also refused my edit to remove because of something like "inappropriate action". Please help, because before it was much much easier to simply add the language brackets at the end of articles to get the proper interlinks.

Thanks, Spaceinvadersaresmokinggrass (talk) 07:44, 19 October 2014 (UTC)

@Spaceinvadersaresmokinggrass: I see that you found the "Merge" tool. I think that the tool does four things: First, it adds all the data to the surviving item; second, it clears the data in the doomed item; third, it marks the doomed item as "merged"; fourth, it adds the page to "Wikidata:Requests for deletions". It looks like the first and second actions happened, but the third and fourth didn't. I don't know why. Maybe it thinks that you are too new on Wikidata to mark the item for merging. (But that would be silly: A lot of users from other wikis would come to Wikidata to do this.) Earlier this year, the merge tool had some bug that was causing things like this; but that software bug was fixed. Since all the data was removed from Q16162716, you can go to Wikidata:Requests for deletions and add a new request for Q16162716, with something like "merged into Q18156495" as the reason. --Closeapple (talk) 09:11, 19 October 2014 (UTC)
Or even better: set the merge.js tool to redirect the source item to the target item. Lymantria (talk) 10:47, 19 October 2014 (UTC)
Having just recently done a bunch of merges, I can say that the merge tool was useless. I had to delete the item from where I was moving it from, and there is a trick do doing that (our new UI sucks). You click edit, you click remove, you click save - and you are not done - you will see a second save appear, and you have to click that one too. Only when you see edit again are you done. Then you can go to the merge to page and add in the item. Then as a final step you have to go to RFD and make a list of the pages that are no longer in use so that they can be deleted. Since they do no harm, it is easier to wait until you are done, and do a bulk request if you are doing more than one page. I have one pending now that I have not bothered to list so that I can combine it as a bulk request after I finish the project that I am working on, which requires a lot of merges (translating an image into 137 languages). 76.24.193.7 05:04, 21 October 2014 (UTC)

VIAF and "no value"[edit]

I would appreciate any further comment about the ability to have "no value" set for VIAF identifier (P214), or other means to help achieve the outcome for maintenance. If you have comment it would be appreciated at Property talk:P214#Managing a "no value" statement. Thanks.  — billinghurst sDrewth 04:51, 20 October 2014 (UTC)

Sometimes a relevant person has no own dataset. For example: you might be looking for an author with the name of "Michael Smith". As ist is a very common name, the cataloges might summarize the works of several persons with the same name of Michael Smith including the Michael Smith you are looking for. You might omit the property VIAF identifier (P214), however other users my be searching the database over and over again or link to the wrong dataset, which includes many people (and create occasionaly a constraint violation, if the same VIAF is linked to another Michael Smith allready). By placing VIAF identifier (P214) + no value, you can indicate, that you have made a search and found no appropriate value. The same applies to every other database you´d normally expect a dataset to be present. But please do not create VIAF identifier (P214) + no value for 3rd league football players, as usualy such people have no own data set in GND, VIAF.... and most probably never will have. Its the same with tennis players + a database that is designed for football players. --Giftzwerg 88 (talk) 17:33, 20 October 2014 (UTC)
Yes, I know that, and that is why I asked for comment at the talk page where you can see the context. At this stage there is a constraint on P214 that does not allow "no value", which means we have no tracking abiity. I am not proposing for every identifier, just this one that is becoming the default/central identifier.  — billinghurst sDrewth 00:53, 21 October 2014 (UTC)

Should people be human (Q5) or person (Q215627)?[edit]

Should instance of (P31) describe the people as human (Q5), like Jura1 is pushing ahead, or person (Q215627), like the Template:Constraint:Person is demanding?--Shlomo (talk) 08:50, 20 October 2014 (UTC)

First of all a Template cannot demand anything, the people behind it are the ones that might want to push that change. "Person" is an abstract term, and when anyone is stating "instance of:person" they are referring only to the abstract component (personhood) that humans share with others beings (real or imagined). Generally it is more useful to instantiate concepts that convey meaningful information to the reader. In this case for beings with a clear physical presence it is more relevant to use "instance of:human", since that concept refers to purely physical entities to which the constraints "sex, place of birth, and date of birth" will always be valid. The same cannot be said for instances of "person", which may or may not have these qualities. Summing up: there can be both a "Template:Constraint:Person" and a "Template:Constraint:Human", but the second one will be more relevant and it will be more useful. Btw, I replaced "<human> subclass of <person>", for "<human> manifestation of <person>" which might help to clarify this distinction.--Micru (talk) 09:39, 20 October 2014 (UTC)
@Shlomo: Thank you for your work on Wikidata and your four thousands contributions.
When you see a constraint, you can examine the items used to respect this constraint to see how it works.
For example here, any instance of or subclass of person validates this something (I hope manifestation too, or we need to change our system).
The goal is to have a hierarchical tree.
Let's look to the person constraint. It fills the goal to have a being with a date of birth, a place of birth, a gender. It's currently mainly used by human (Q5) but also by fictional character (Q95074). And in a speculative future, it could also be used for IA and non human beings. We so have an agnostic notion of person, fulfilling any need we have or could have in the future. And currently, we mainly use human (Q5) and fictional character (Q95074) to sort persons.
Please also note there are currently more than one million items with the instance of (P31) : human (Q5) claim.
If you wish to explore how more complex Wikidata mechanisms works like properties and items relationship, you could maybe try a participation to a new project to improve data on a new kind of items not yet well described, that would allow you to see a little how things work on this point of view. That will get you a stronger knowledge of the project and so you will be able to offer better proposals. Don't also hesitate to create an user page to explain your goal and activity here. --Dereckson (talk) 13:49, 20 October 2014 (UTC)
Thanks for explanation. If I now understand it right, the really and undoubtedly existing people can (even should) have instance of (P31) human (Q5) (because it's more specific for them) and the constraints demanding the items to be person (Q215627) won't report a violence, since it is a subclass. And the eventual question whether the constraint defined for a particular property shouldn't better demand a human (Q5) than a person (Q215627) let's discuss at the property discussion page...--Shlomo (talk) 14:40, 20 October 2014 (UTC)
Yes. Note that as well as {fictional character (Q95074) we also have biblical character ( Q14943515) and legendary character ( Q16934977) for cases where there is some doubt as to whether a character is or is not fictional. I would say that we should not, in practice, be using instance of (P31):person (Q215627) for any people. we should always use one of it's subclasses. Filceolaire (talk) 17:38, 20 October 2014 (UTC)

website account on (P553)[edit]

Regarding website account on (P553), should we list an account if the website lists it as a verified account? And with Facebook, do we only list accounts or can pages be added too? --AmaryllisGardener talk 15:50, 20 October 2014 (UTC)

Here is my personal practice filling these properties. I personally use the official person/corporate/organization website to add these links, so instead to apply a rule "only accepted Twitter verified accounts", I use the rule "use a trustable source for the websites account". Doing that, I added Facebook pages (which are a lot more frequent than regular accounts for Wikidate notable items' subjects). --Dereckson (talk) 16:53, 20 October 2014 (UTC)

Left (Q3556716)[edit]

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

It looks fine to me. A wikipedia page is a concept, and if the concept is the same in a different language, then it does not matter what it is called in that language. It is a little bit odd to have something be the opposite of a disambiguation page, but what they did is choose the disambiguation page that is for the opposite of the subject that is being distinguished. 76.24.193.7 06:27, 21 October 2014 (UTC)
In my opinion, we should definitely split this item. The linked disam pages do not only deal with the direction but also with music albums called "Left", people with last name "Links" or "Ezkerra" or a wind with name شمال (north) --Pasleim (talk) 07:50, 21 October 2014 (UTC)
Yes, it should be splitted, but there should be a way to present all this similar disambiguation pages (or a link to a list of them), near to the "Languages" list on the sidebars of all this disambiguation pages to the Wikipedia readers. Maybe the Wikidata items should populate a item group for Translations of Left. --Diwas (talk) 11:34, 21 October 2014 (UTC)
Surely you are joking. That is what a "disambiguation" page is. Disambiguation is not just a big word that means "put a squiggly fork template here". It means "this title has more than one use in this language", and the fact that it means different collections of things in different languages is completely irrelevant. 76.24.193.7 13:50, 21 October 2014 (UTC)
The fork list (of items) should not be putted on the disambiguation pages, but (as one? link) near to the languages list. A (link to a) list of some discrete items, but not a mess on disambiguation pages and not a mess in one item. --Diwas (talk) 23:16, 21 October 2014 (UTC)
IMHO Wikidata:WikiProject Disambiguation pages/guidelines is too strict, but still this is an example of a disambiguation page that should be split. Lymantria (talk) 15:15, 21 October 2014 (UTC)
Speaking of "too strict", why is this a requirement? "The item should only contain links to Wikipedia disambiguation pages with the exact same spelling" How can we dictate what each Wikipedia wants to put on their disambiguation page? Why should we exclude one just because they think it is important to add items that are not spelled exactly the same? 76.24.193.7 16:31, 21 October 2014 (UTC)
For me, it is too strict too, but the same spelling is not a requirement for each listet element of the disambiguation page, but only for the title of the disambiguation page. But we will never get consensus for each grade of variance, if it should be splittet or not. And (maybe in the future) one language version will contain two disambiguation pages for two different spellings, and then the previous one item will going to be splitted. Then it will be helpful to have a short fork list of this two different but similar items. --Diwas (talk) 23:54, 21 October 2014 (UTC)
I must not be understanding what you are saying. To use the Left page as an example, it is very likely only spelled "Left" in English. There is a br dis page, but it was not Kleiz, but Kleiz (disheñvelout), and that has been corrected. Since many languages are sensitive to variables, the fact that the de page includes both Links and Linke or that the el page uses αριστερά and Αριστεράς disqualifying them from being called a dis page here is absurd, and obviously that guideline needs to be revised, as it is pathetically false that all of the things listed have to be spelled the same as in the title of the disambiguation page. 76.24.193.7 21:02, 22 October 2014 (UTC)
Yes is necessary to split item --ValterVB (talk) 18:03, 21 October 2014 (UTC) ps brwiki isn't a disambiguation page.
The Wikipedias tend to describe different variants or aspects of the general concept of 'left' (or izquierda, or whatever) in separate articles. Like political left, left-handedness etc. Hence the majority of articles which are mentioned on these disambiguation pages are for different aspects of the same. Is Bretonic the only language to have an article on the general concept at all? There is a good reason to link these pages, such links are helpful for readers interested in other languages.
Although there is a 'guideline' which suggests that this item should be split, why should this guideline be implemented in every case? What is the harm if we leave it as it is, as long as there are no interwiki conflicts? Bever (talk) 01:17, 22 October 2014 (UTC)
Disambiguation pages either can be aggregated by label or by concept. Most of them are by label, but in this case the label is so close to the concept that it might make sense to leave it like that. Some exceptions are needed to make a rule, right? :) --Micru (talk) 08:52, 22 October 2014 (UTC)
Pages like br:Kleiz are a good reason to have an additional way to link similar but different items. We should not mix it with disambiguation pages in the disambiguation pages item, but should give it an own item and link that in an item (one level higher) for pages (lists, disambiguation pages, articles) about the general concept. --Diwas (talk) 12:30, 22 October 2014 (UTC)
br:Kleiz was not a dis page, but was a page that describes left and several other uses of Kleiz. A disambiguation page can not have any content other than a minimal description. Once content is added, it is a page about that content and no longer a disambiguation page. It was removed and placed in the left (position) page, and replaced with the br:Kleiz (disheñvelout) page, which is a dis page. 76.24.193.7 21:59, 22 October 2014 (UTC)
I would agree with keeping this item unsplit if only the "concept" left gave reason to make the disambiguation. But now both spelling (e.g.: German and Dutch have a browser "Links" among their linked pages) and concept do and that does make it messy. Now we have to make a decision: Merge Links (Q11984152) into Left (Q3556716)? How about Sinister (Q10668323), because of the Latin link, or even Left (Q10316880)? To solve this mess splitting is needed. Lymantria (talk) 17:03, 22 October 2014 (UTC)
I have split the item.--GZWDer (talk) 05:50, 23 October 2014 (UTC)

Language column[edit]

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

I can confirm the issue with the value being displayed in English once entering one and filed a bug for this. Thank you for reporting this. We are also aware of the loading time issue and working on it. Aude (talk) 22:12, 22 October 2014 (UTC)

BIG problem with date adding[edit]

I just tried to add dates of birth and death on Q2831659, but got The time value is malformed after typing the date in the property as usual (in French)... impossible to validate it… the field now accepts only English format or xxxx-mm-dd format :(

what happened ? --Hsarrazin (talk) 12:53, 22 October 2014 (UTC)

+1 yes, i got the same problem, adding timedata to film or band article. Layout is german but only accept is english. And all text i insert is known in german but shown in english. --Crazy1880 (talk) 15:10, 22 October 2014 (UTC)
moreover, all references (sources) are now displayed in English, instead of interface language…  :( --Hsarrazin (talk) 17:06, 22 October 2014 (UTC)
same with me editing in German :(--Oursana (talk) 18:15, 22 October 2014 (UTC)

type of[edit]

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

Steak burger (Q18338265) subclass of (P279) something. --Diwas (talk) 19:17, 22 October 2014 (UTC)
Thanks, but does that work instead of instance of? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:10, 22 October 2014 (UTC)
Yes, instead of instance of. There are tons of steak burgers, and there are subclasses of it, like the Burger King Sirloin Steak sandwiches or like all steak burgers you eat ever, but the one you bite maybe tomorrow is an instance of Steak burger (Q18338265) and an instance of the subclass of your own steak burgers. --Diwas (talk) 23:12, 22 October 2014 (UTC)

WMF grant proposal including Wikidata outreach[edit]

Wikimedia DC has submitted a grant proposal to the Wikimedia Foundation to cover some of its program costs for the fiscal year, including planned outreach around Wikidata. See meta:Grants:PEG/WM_US-DC/Projects_2015#Civic technology outreach. Please feel free to comment on the grant proposal. Thank you, Harej (talk) 21:17, 22 October 2014 (UTC)