Wikidata:Project chat/Archive/2014/10

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

How to propose a new language within Wikidata

As far as I know the preconditions to add a language to Wikidata are much lower than to add a new Wikimedia project in such a language - as far as I know a ISO language code is already enough. However it seems there is no place where to ask for a new language - several months ago I tried to ask for Northern Thai language (Q565110) (ISO code nod) at Meta:Talk:Language committee which was ignored and later archived by a bot, another user tried to ask for Cape Verdean creole (Q35963) at Meta:Requests for new languages/Wikidata Cape Verdean Creole with effectively the same result. Is there any established place to propose languages for Wikidata? Does it really have to go through the long bureaucratic language committee process, though IIRC there already was a decision that every language is eligible for Wikidata. Ahoerstemeier (talk) 12:55, 30 September 2014 (UTC)

User:GerardM had proposed some months ago in the Language Committee that all languages with an ISO 639-3 code should be made eligible for Wikidata. It was agreed upon; and I had thought he would have taken the necessary steps? --MF-W 14:19, 30 September 2014 (UTC)

@Ahoerstemeier: Go to Wikidata:Contact_the_development_team or contact Lydia Pintscher (WMDE). Snipre (talk) 15:22, 30 September 2014 (UTC)

Yeah. The easiest way is to file a bug on bugs.wikimedia.org and then get someone from the language committee like Gerard to ok it there. --Lydia Pintscher (WMDE) (talk) 14:21, 1 October 2014 (UTC)

Too hard to cancel an edit now...

E.g. Template:@ (Q6133158), I've tried adding q:zh:Template:@, yup it's not exist, then clicked "cancel", I've waited for several minutes (and drank a cup of coffee), it's still "canceling"?! --Liuxinyu970226 (talk) 00:11, 1 October 2014 (UTC)

hhmm.. it takes some extra clicks to add an interwiki or edit a label today. Why? Michiel1972 (talk) 08:52, 1 October 2014 (UTC)

Aparently, a new interface, but adding extra clicks was possibly not a good idea--Ymblanter (talk) 10:07, 1 October 2014 (UTC)

Yea that is part of the move to the new interface. It is still being changed and we really have to fix the part where you have to scroll considerably more than before. --Lydia Pintscher (WMDE) (talk) 14:18, 1 October 2014 (UTC)

Just in case you still didn't notice, the "move" link for linked Wikipedia pages don't work.--Pere prlpz (talk) 18:25, 1 October 2014 (UTC)

Pere prlpz: Its a gadget, so see #problem with tools... --Succu (talk) 18:31, 1 October 2014 (UTC)

Qualifiers for labels

Qualifiers for labels were discussed sometime ago but still not implemented. Obvious application is date based qualifiers for places which changed names over time.

Other useful application is for providing declension for nouns for languages (Russian, Belarusian, Ukrainian, Polish, etc) which use them. Labels provide only nominative case. But categories which could be deduced from data may require other cases. For example, categories by places (born in, died in, alumni of, etc) or by person (works of, translation by). MediaWiki use GRAMMAR for such purposes.

EugeneZelenko (talk) 13:54, 24 September 2014 (UTC)

Labels should not get qualifiers - Labels are used for identification and display, not as part of the knowledge about the entities. A "name" property (maybe Property:P1448 fulfills your requirements) on the other hand could have such qualifiers, and there it would make a lot of sense.

Regarding declension, this will be covered by the Wiktionary & Wikidata proposal (no matter how it will look like in detail), and will still take a while.

Just my two cents, --Denny (talk) 15:05, 24 September 2014 (UTC)

@Denny: official name (P1448) doesn't cover translations, it is only for names issued and supported by entity itself. And we need some field that will hold different names in different languages AND for different times. -- Vlsergey (talk) 15:09, 24 September 2014 (UTC)

I believe that categories shall be direct-linked to items like using category for people born here (P1464) and category for people who died here (P1465) for places, not constructed on fly. For example, label can be changed at anytime and we will lost this category. But yes, we still need some way to get the "old name" of entity. Not sure shall be monolanguage or multilanguages field. -- Vlsergey (talk) 15:08, 24 September 2014 (UTC)

If official name or one of the other properties doesn't fit, yes, a new one should be made. @Vlsergey:, if you make a proposal let me know, and I will support it. --Denny (talk) 15:20, 24 September 2014 (UTC)

@Vlsergey: Same here, I would support a "name" or "natural language identifier" property with monolingual datatype to be used with qualifiers and with sources. A nice addition would be a bot to take the values of the statements using that property and to copy them as item labels too.--Micru (talk) 19:24, 24 September 2014 (UTC)

I don't think that it's good idea to create property for every something by place category (see en:Category:New York City with subcategories as example). --EugeneZelenko (talk) 13:49, 25 September 2014 (UTC)

Sorry Denny, I completely disagree. The use case is valid. Not showing the right label removes needed functionality from Wikidata. Thanks, GerardM (talk) 06:36, 2 October 2014 (UTC)

I'm not happy using labels, nor aliases, for former names. I was about to propose a "former names" property, when I saw this discussion. What do folks think about that option? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:48, 25 September 2014 (UTC)

May be I'm outdated :-), but do we have multiple language strings necessary for that? --EugeneZelenko (talk) 13:49, 25 September 2014 (UTC)

@Pigsonthewing: A "former name" is just a "name" that has an "end date". Therefore, a property "name" would be enough for cover all cases.--Micru (talk) 14:18, 25 September 2014 (UTC)

Andy I agree with Micru. Use the regular name properties with an end date. Make the current value the preferred value. Use qualifiers on each name to specify the given name, family name, prefix, suffix, language, start date, end date etc. for that name. Where an item has more than one official name (some cities have official names in more than one language) use additional values for that property. Create a new 'translation' property with multilingual datatype for informal/unofficial translations of that name. Filceolaire (talk) 22:53, 29 September 2014 (UTC)

See Wikidata:Property_proposal/Archive/16#name_.2F_name_.2F_nom_.2F_.D0.B8.D0.BC.D1.8F_.2F_in_wiktionary Filceolaire (talk) 22:56, 29 September 2014 (UTC)

Copyright and licensing of extracted facts

I'm trying to populate Stack Exchange tag (P1482) properly on as many entities as possible. As a first step, I want to seed the entity/tag links based on the Stack Overflow tag wikis on StackOveflow.com (example). From the May Stack Exchange data dump I have extracted a few thousand links to Wikipedia articles found in the Stack Overflow tag wikis. I've manually reviewed them to ensure an approximate one-to-one relationship between the tags and the Wikipedia articles. I'm very confident in the quality of the links, and now I want to add them to WikiData using User:StackerBot. However, now I'm concerned about licensing/copyright issues.

The Stack Exchange data in totality is CC-by-SA 3.0 licensed. WikiData is CC0/Public Domain. Would the nature of the extraction I've done (pulling out just the links to Wikipedia articles and converting them to WikiData entities) be transformative enough to permit me to use the fair use exemption to publish the derived data under the public domain suitable for use in WikiData? Or do I need to seek special permission from Stack Exchange? Or do I just have to fill this property out manually? (I've asked this question over on Meta.StackExchange, but haven't gotten an answer) --Bskaggs (talk) 13:12, 29 September 2014 (UTC)

StackOverflow is an US website. As there is no database sui generis right in United States, you don't have to worry about data extract.

Furthermore, there are precedents telling facts aren't copyrighted in the US: see for example Nester's Map 86 Guide Corp. v. Hagstrom Map Co., 796 F. Supp. 729, 733, 23 U.S.P.Q.2d 1749 (E.D.N.Y. 1992),

Finally, you don't do a mass copyrightdata extraction, you match StackOverflow tags and Wikidata items. This is a reference catalog work, not an extraction of the content of SO database.

--Dereckson (talk) 14:39, 29 September 2014 (UTC)

Is there an Help page explaining the licensing concepts applicable to WD, especially for massive import from other DB? Last time I checked, I couldn't find one.

On my side, I have been sitting on a csv file giving the full list of shares border with (P47) between French municipalities. I got that from the French OSM team a while ago, and when I checked the OSM license, it explicitely stated that data reuse had to be under the same license (here). So AFAICU, massive import to a CC0 license is not possible.

Any advice? --LBE (talk) 17:15, 29 September 2014 (UTC)

See here. Filceolaire (talk) 18:07, 29 September 2014 (UTC)

Is this a mandatory read & comply for anyone who gets a bot flag? Because as far as I can see, this puts a lot of the import work which is done here out of bounds.

I fixed my message below: I wanted to use the expression "mass data extraction". --Dereckson (talk) 09:38, 2 October 2014 (UTC)

LBE, in France, like in the others EU contries, you have a droit sui generis des bases de données, so you can't do mass extraction as long as the person doesn't relicense the data in CC0 or doesn't explicitly waive this intellectual property right (copyright isn't waivable in EU, but sui generis database right is).

In France, public agencies and organizations typically won't do it upon request, it must come from political decisions taken at ministry level. So you're stuck and should find another source to do that. --Dereckson (talk) 09:44, 2 October 2014 (UTC)

Area served by a radio station

Is there an existing property that can be used to identify the area served by a radio station? We have place served by airport (P931) for airports and primary destinations (P1302) for roads but I couldn't find anything for radio stations/TV stations/Satellite TV stations. Filceolaire (talk) 18:09, 1 October 2014 (UTC)

@Filceolaire: I would say this one: licensed to broadcast to (P1408).--Micru (talk) 15:57, 2 October 2014 (UTC)

How to deal with translations of creative works?

I have a creative work originaly witten in one language and later translated into other languages. Sometimes the new version justifies a seperate item, e.g. all major Translations and editions of the Bible. In many cases it's no more than a standard novel, play or song translated within a few years into another language without any major differences from the source, someting that a wikipedia in any language would just mention in the parent erticle and not create a seperate article for. The question is do I just add the language name under language of work (or name) (P407) or can should I add qualifers for ISBN, translator, publisher, date etc. like I did in The Informationist (Q7742011) or is this an "overkill"? DGtal (talk) 11:09, 2 October 2014 (UTC)

• There two different questions: how to handle translations and how to handle interwiki to that translations. From my point of view any translation should be separate item, either book translation or movie translation. In addition, there are translations and publications. Each publication would need a separate item as well, if multiple publications exists (but you can use single item as long as only single publication per language exists, as per most of movies). Using single item for all translations and original item will create a mess in data and it would be very hard to manage them. And even if some would like to have several translations in the same item, it should be not like language[property], but claim[language] structure. -- Vlsergey (talk) 11:48, 2 October 2014 (UTC)

  Part of the question is what good comes out of a seperate item for a book translation if the interwiki is on the original item. You get an item with no articles linked. DGtal (talk) 12:17, 2 October 2014 (UTC)

  Well, you need some kind of agreement either to link all Wikipedia article to original item or somehow fetch interwiki from original item and it's translations. -- Vlsergey (talk) 13:21, 2 October 2014 (UTC)

@DGtal: See Help:Sources Snipre (talk) 13:09, 2 October 2014 (UTC)

Unbalanced marks

Hello, I just made a report on labels that they are not balanced in certain characters like "(" and ")" and you can find it here. usually it's an error in Wikipedia's side but we can report the error to the local languages. Amir (talk) 20:05, 2 October 2014 (UTC)

new constrain "period" for items

Examples of usage could be found here:

• Talk:Q2184
• Talk:Q15180

Currently analyzes place of birth (P19)+date of birth (P569), place of death (P20)+date of death (P570), country of citizenship (P27)+date of birth (P569)/date of death (P570), but other properties could be added as well. Feel free to try and report mistakes. -- Vlsergey (talk) 04:43, 3 October 2014 (UTC)

Title

New Property title (P1476) has been created to replace (OBSOLETE) title (use P1476, "title") (P357). I want to change the labels on these properties to indicate that P357 is deprecated but I can't edit the property labels. Is there some new permission I need to edit property labels? where can I go to get this user right? Filceolaire (talk) 15:09, 1 October 2014 (UTC)

It's a bug, not a new user right. see Wikidata:Contact_the_development_team#Empty_labels_and_descriptions --Pasleim (talk) 15:24, 1 October 2014 (UTC)

Are you sure it was P2476? The page doesn't work for me. --Stryn (talk) 15:13, 2 October 2014 (UTC)

Fixed - it's P1476. 86.6.111.107 15:35, 3 October 2014 (UTC)

Help needed

I am unable to link any pages to wikidata since yesterday. Cannot see the "add" button on "any" pages. Please help.--Kanags (talk) 11:15, 2 October 2014 (UTC)

@Kanags: - Did you try a different browser or deactivating plugins? - Tobias1984 (talk) 09:03, 3 October 2014 (UTC)

Tried the other browsers too. But from the edit button I can now activate the "Add" button.--Kanags (talk) 09:15, 3 October 2014 (UTC)

New interface - save button inactive after an alert has been displayed

I was unscrambling Wikipedia links between Q1642648 and Q2976556, moving a number of links from the first item to the second. As the move gadget isn't available any more, for each wikilink I manually delete it from its former item and add a new line in the new item. At some point, I hit Enter while editing the new item, which correctly displays a conflict alert as I have not yet saved my edits (removals) on the old item, so far so good.

Problem is, after I dutifully save my removals from the old item, there is no way to save the new item. The save link is blue, but after clicking it the Wikipedia section remains grey and is never saved. Even more of a problem, when I tried to open the unsaved page in a new tab and add all links again from scratch, the unsaved links in the "frozen" tab are visible but cannot be selected and copy/pasted, which is problematic when they are in alphabets I can't type such as Hebrew or Chinese.

Do you see any way to fix that? (I am a Wikidata administrator and my display language is French, it this makes any difference.) Copied at Paper cuts Place Clichy (talk) 13:22, 2 October 2014 (UTC)

I'm not administrator and my display language is Catalan, but I'm experiencing the same issue, so status and language don't seem to make any difference.--Pere prlpz (talk) 14:57, 2 October 2014 (UTC)

I got the same problem last night. Hope someone fixes this problem soon. My display language is Swedish.--Paracel63 (talk) 17:08, 2 October 2014 (UTC)

I'm really missing the options to move/delete links one by one. --- Jura 20:59, 2 October 2014 (UTC)

If you want this issue corrected, please add your username at Wikidata:Paper cuts#New interface - save button inactive after an alert has been displayed. Place Clichy (talk) 07:58, 3 October 2014 (UTC)

problem with tools...

Since yesterday I've had problems with some tools interface...

For example, now Wikidata usefuls displays in the bottom-left of the item (not the screen), and I have to drag and drop it back in top-right for every item, which is not really convenient...

I checked, there has been no change on this script since 8th of september, so I guess it's something with a general update or modif of GUI.

Is it possible to fix it, please ? --Hsarrazin (talk) 12:43, 1 October 2014 (UTC)

I have been noticing this problem as well, so...confirmed problem. I have also noticed that some userscript has stopped working, such as the WEF: Person (however the WEF: Links still works... :/ ) (t) Josve05a (c) 13:11, 1 October 2014 (UTC)

Yeah sorry. A few things changed in the UI as part of the move to the new UI. That probably broke some of the gadgets relying on them :( If you need help fixing any of them let me know please. --Lydia Pintscher (WMDE) (talk) 14:20, 1 October 2014 (UTC)

other tools missing :

• the one that allows to display images in a small popup (CommonsMedia I think), - back this morning --Hsarrazin (talk) 07:40, 4 October 2014 (UTC)
• altlabels which can add label from labels existing in other languages,
• User:Magnus_Manske/authority_control.js, which launches, but does not find existing items in VIAF... - fixed

it would be nice if they could be fixed - I'm only using scripts, can't understand how they work ;) --Hsarrazin (talk) 21:01, 3 October 2014 (UTC)

Creating tables with Wikidata - Directory of politicians

Dear all,

I am quite new in the wiki's world but I would like to develop a project that bring together the public contact details of all the politicians (address, email, Facebook, Twitter, etc).

The idea would be to have a table that could be updated by the community and readable both by humans and computers (if you want to do an extract or so) and liked to an external website. I already extracted the data from the European Parliament website and it looks like: First name / Last name / Position / Nationality / Party / Email / Address / Social networks / Assistants / Committees

And I wondering if Wikidata would be the best place do so? Can we create tables in or with Wikidata? Because as far as I understood, an item is only a label and a single description. But as indicated above I need a label and several fields.

And Wikidata doesn’t suit for the purpose, which Wiki project is the most appropriated?

Thanks and cheers.

Antonin

Most of that data would be great to have on Wikidata, perhaps with the exception of email addresses. Wikidata items have much more than just labels and descriptions. Please take a look at this item, for an example: Barack Obama (Q76). Plenty of data can be included on politicians, in the "Statements" section. --Yair rand (talk) 16:13, 1 October 2014 (UTC)

Once the data is entered as statements on each politicians item it can then be extracted into a table using a query. Except that the tool to create a table using a query is a part that is still being developed and is not available yet. It will come - there are too many ways it will be useful for it to be left for long. Once the data is in wikidata it can also be imported into infoboxes on all the wikipedia pages for that politician. Tools are being developed which will let people edit the info from the wikipedia page which should help keep the info up to date. Filceolaire (talk) 17:51, 1 October 2014 (UTC)

Thank you all for your answers and the guidance. I guess I didn’t knew all the possibilities of Wikidata and I’m glad it is feasible as it definitely looks the right tool to do it.

Is that possible to add directly data from a table to Wikidata? Because I have around 20000 entries (just for the European Parliament) and that would be too long to do it manually.

Where should I ask for help from the wiki community? Because that will be great to have a some people interested by the project and who could help me 1/to organize the data in the right way and 2/to include them into Wikidata.

About the extraction, I already talk previously with someone from Wikimedia and he told me that once we will have the data and the project, we might ask to develop new tools play with the data. (And about the email, it is the public email from the website so it shouldn’t be an issue I hope)

Thanks you again. --Pixelimpact (talk) 14:29, 2 October 2014 (UTC)

@Pixelimpact: Re: Is that possible to add directly data from a table to Wikidata?: you might want to use the QuickStatements tool. QuickStatements has its own format which is explained in the documentation so you may have to reformat your table, but once you do that, if you are using a common spreadsheet application like Excel you can copy and paste the table into your browser and add statements directly from there. --Haplology (talk) 01:49, 3 October 2014 (UTC)

@Haplology: Thanks! I'm trying to understand how it works exactly because it is not very easy for a beginner so far :)Pixelimpact (talk) 17:39, 4 October 2014 (UTC)

Ethylene

Question: de:Ethen is a featured article and marked as such in the Wikidata, but it does not show up as featured in the other Wikis. Any idea why? -- Linksfuss (talk) 20:19, 3 October 2014 (UTC)

Was there some sort of change to "label" in this week's code update?

I went to use User:Magnus Manske/authority control.js and its search function now fails to find the label when it runs a search (there are no apparent changes to his script). So I am asking here what changes may have occurred so I see if I can make a simple update to Magnus's script or whether I need to find someone to do some more detailed analysis of the issue. Thanks.  â€” billinghurst sDrewth 00:58, 4 October 2014 (UTC)

 Done  â€” billinghurst sDrewth 13:16, 4 October 2014 (UTC)

Merge impossible because of pedia dupe...

Bernhardus Varenius (Q60215) and Bernhardus Varenius (Q2898700) are the same person, but because of a dupe problem on frwiki, they cannot be merged as long as the frwiki articles have not been merged.... - and this is a quite frequent case :)

how is it possible to mark this on the item that should be deleted once the merge can be completed (higher ID) ? I remember a tag, or a template, I saw somewhere, but cannot find it...

Thank you for your help... --Hsarrazin (talk) 10:19, 4 October 2014 (UTC)

"instance of Wikimedia duplicated page" and "is said to be the same as [...]" - Brya (talk) 11:30, 4 October 2014 (UTC)

@Hsarrazin: I've merged the items on fr. to solve the issue. --Dereckson (talk) 11:57, 4 October 2014 (UTC)

@Brya : Thank you... I'll note it :)

@Dereckson - thank you for solving it, but I also needed the previous answer ;) --Hsarrazin (talk) 12:05, 4 October 2014 (UTC)

Fixed with redirect. --ValterVB (talk) 12:10, 4 October 2014 (UTC)

Non items deletion: dedicated page or template use

Matěj Suchánek informed me currently:

• Wikidata:Requests for deletion is for items only
• for any other page, the {{Delete}} template is to be used

On the French Wikipedia, there is a page dedicated for speedy deletions, fr:Wikipédia:Demande de suppression immédiate. This allows a better tracking and transparency of such requests. A template also exists, but is mainly provided for convenience for people from other projects familiar with the en.wikipedia delete template.

The advantage of a speedy deletion dedicated page (which could be Requests for deletion directly, or through a split, Wikidata:Requests for deletion/items and Wikidata:Requests for deletion/misc) is a better transparency, possibility of tracking and check by the community as large. For example, it appears in the watchlist.

It's also more coherent to offer a coherent system for every namespace.

What are your thoughts on this matter? --Dereckson (talk) 10:57, 4 October 2014 (UTC)

Wikinews interwiki

Guys (incl. JAn Dudík), so far i saw no summary neither consensus in the previous discussion about linking wikinews categories, so, please, asking you last time -- let the projects decide how they would work with wikidata. Do not move their categories links to wikipedia categories. Either you put other projects goals over your imaginary problems with bots or other projects would turn away from wikidata. It is very serious issue here, do we provide service to other projects like they need; or other projects like Wikinews would consider Wikidata as unfriendly project that they shall not go along with. -- Vlsergey (talk) 21:31, 29 September 2014 (UTC)

+ @FriedrickMILBarbarossa:. -- Vlsergey (talk) 12:51, 6 October 2014 (UTC)

ISBNs for translated books

I've added ISBN to Q16601597. Since translated versions of the book has different ISBN (property:P212 and/or property:P957) from original, I supplied it with qualifier "Language". Also, I've tried to play with priorities for that {#property} claims which want original ISBN got only it. If I do something wrong (I feel like this), please correct me. Ignatus (talk) 17:22, 5 October 2014 (UTC)

author

Please don't add profession:author to writers, in russian it looks ridiculous. Thanks. --Olga^@ 08:05, 3 October 2014 (UTC)

@Drakosha999: Can you translate what is so ridiculous about it? -Tobias1984 (talk) 09:04, 3 October 2014 (UTC)

Just fix the Russian translation.--Ymblanter (talk) 12:13, 3 October 2014 (UTC)

I don't know how, author is author also in russian, but we use it for author of innovation, patent, not for writers. For writing scientist or explorers it is ok, but for writers of fiction, writer and author for same person looks strage.--Olga^@ 13:21, 3 October 2014 (UTC)

I am pretty sure it is ok to say in Russian that Leo Tolstoy is the author of Anna Karenina. Writer is not very good either, since it can be a journalist, and journalists are usually not labeled as writes. May be we need some more input from speakers of various languages.--Ymblanter (talk) 13:57, 3 October 2014 (UTC)

This a probably a big language mess. I think we should stay simple and use a generic property for the act of creation, except if it introduce an ambiguity, for example the composer of a song and the writer of a text do not really do something essentially different : they create something new. Maybe we can even merge with some other concepts like the invention of anything new. We has a discussion about the person who first found a mathematical proof of a theorem or someone who conjectured something. The nature of the item of the created object pretty much gives us the word to use in any language. TomT0m ^(talk) 15:30, 3 October 2014 (UTC)

@TomT0m : I agree with you, for a function regarding a work : Creator, like on commons, is right... like author (P50) and creator (P170) that could be merged... and perhaps also illustrator (P110), composer (P86), performer (P175), director (P57) (I probably miss some others), that could be merged in a generic creator/author property, with function qualifier... ;) --Hsarrazin (talk) 09:31, 4 October 2014 (UTC)

but to define the occupation (P106) of a person, it's a little "too synthetic" :),

@Drakosha999 : I also agree with you, regarding the double claim "author" & "writer" - in French too, it seems "bizarre" :D - seems redundant…

perhaps, author (Q482980) should be used only for "non-professional" writers… like diplomats, militaries, etc. who wrote an article... --Hsarrazin (talk) 20:45, 3 October 2014 (UTC)

In German we have Schriftsteller writer (Q36180) for professional writers like Tolstoy. We use Autor author (Q482980) as a very general term for all kinds of written texts like scientific literature, articles in Newspapers, writers of Wikipedia, journalists etc. Everybody that creates texts is an Autor, so Schritsteller is subclass of Autor.

Perhaps it is a good idea to look over the lables and wikilinks of author (Q482980) and writer (Q36180). /ℇsquilo 12:02, 4 October 2014 (UTC)

It doesn't make any sense ontologically, either, as currently writer (Q36180) is a subclass of author (Q482980), (that is, all instances of the former are also instances of the latter) so stating both as an occupation is redundant.

I think this is a problem with English specifically, in that if you say someone is "an author", and don't qualify it, it's assumed they write for a living - that is they practise literature (which for us means they are a writer (Q36180)). You wouldn't use a more general author (Q482980) (someone who writes anything) as a profession. You'd have to be more specific -Moogsi (talk) 18:55, 4 October 2014 (UTC)

The definition is not stringent across languages. In Swedish author (Q482980) (författare) is a person who write books while writer (Q36180) (skribent) is a person who write texts. /ℇsquilo 10:03, 6 October 2014 (UTC)

• In Russian автор (author) can be of any creative work - author of book, author of melody, author of invention, author of sculpture. So writer is a subclass of author. I already removed some time ago redundant claims "author" when there exists some subclasses already. --Infovarius (talk) 14:29, 7 October 2014 (UTC)

"member of" vs. "part of" for families

Hi all! Should I use "member of" or "part of" for families? I was looking at the Wikidata:Database reports/Constraint violations/P463 in the case of Jan Wierix Q18152431 who was a member of the Wierix family Q7999178. Thx, Jane023 (talk) 09:42, 4 October 2014 (UTC)

I'm also wondering about this... --Hsarrazin (talk) 10:20, 4 October 2014 (UTC)

Well, since member of seems better English, I am sticking with that one until further notice. Should I put this somewhere where it can be found later? It can always be found by clicking "What links here" on items that are about families. Jane023 (talk) 07:03, 7 October 2014 (UTC)

Better English does not always mean better Wikidata structure :) but "part of" is supposed to be transitive: if Jan Wierix's head is part of Jan Wierix, and Jan Wierix is part of the Wierix family, then the head of Jan Wierix is part of the Wierix family. As it does not seem to make sense, I'd say use "member". --Zolo (talk) 09:25, 7 October 2014 (UTC)

Deleted items but used

Exist some lists of deleted items but used? --ValterVB (talk) 12:12, 4 October 2014 (UTC)

For a static list, I have prepared a query and its results. For a dynamic list, Special:WantedPages is something close to that (though it contains non-item pages, too). whym (talk) 04:53, 5 October 2014 (UTC)

@Whym: Thanks for the static list. For Special:WantedPages I already saw, but isn't update: «Updates for this page are currently disabled. Data here will not presently be refreshed.». --ValterVB (talk) 19:59, 6 October 2014 (UTC)

Temporary protection of Q183 (Germany)

Hello Wikidata people,

There is currently a set of severe bugs (bugzilla:71519 being the most sallient) which cause recent revisions of the Q183 (Germany) item to cause crashes in Mediawiki and prevents editing of pages and items linking to this one, breaks watchlists, as well as cause serious operational impact on the site. Because of this, we have temporarily reverted to an old version of the item that is known to not cause the issue, and superprotected the page against accidental edits. This is only a temporary measure, and as soon as the bug is fixed or a workaround is found, we'll (of course) restore editing to the item.

It's possible that slightly more recent revisions of the item would also be correct; if there is we might be able to test if that revision is safe and revert to it – but if it's reasonable to wait for a few days until the issue is corrected, it would be the safest course of action. MPelletier (WMF) (talk) 22:26, 5 October 2014 (UTC)

I tried going back to a newer (bigger) version, but sadly this caused trouble again, so we (for now) have to stick with the revision the item is on. - Hoo man (talk) 22:47, 5 October 2014 (UTC)

What is "too big"? Is $wgMaxArticleSize enforced? Is AbuseFilter able to prevent edits? --Nemo 07:27, 6 October 2014 (UTC)

1. I don't know.
2. No. Define "article size" for a Wikidata item.
3. Yes, but the point of (super) protection is that it's more efficient performance-wise and in the case of super protection, can't be undone by admins.--Jasper Deng (talk) 07:58, 6 October 2014 (UTC)

I do not even know whether an admin could protect the article before it was superprotected, due to the same issues. I tried opening it several days ago, and I could not. If I can not open an item, I possibly can not protect it.--Ymblanter (talk) 09:37, 6 October 2014 (UTC)

I have also noted that very large items (that is items with many claims) take very long time to load, are difficult to edit and sometimes causes the browser och the script-engine to crash. Mostly occuring for countries and major cities. /ℇsquilo 09:54, 6 October 2014 (UTC)

I have a prediction: the following items will create problems in near future: Q72 �(475 091), Q17939676 �(455 529, wat?), Q40030 �(436 935), Q40430 �(367 320), Q15499 (350 180). A couple of rhetorical questions (to developers team?):

1. How come saving an Wikipedia article parses the whole item in memory? Doesn't Wikibase Client have some fast Q->label local cache? Q->sitelink cache?
2. What will happens as soon as some item will have 1Mb size? 2Mb? 5Mb? Where shall we put claims as soon as article size limit is reached?
3. What will happens as soon as bugzilla:47930 is resolved and single article will display not 10s, but 100s of items on single page?

-- Vlsergey (talk) 10:08, 6 October 2014 (UTC)

Perhaps it is time to clean this kind of items:

• what is the difference between member of (P463), instance of (P31) and part of (P361) ? Because when we see part of (P361): European Union (Q458), instance of (P31): member state of the European Union (Q185441) and member of (P463): European Union (Q458), we can say that we have a problem of redundancy
• Are we so stupid that we have to have both claims instance of (P31): state (Q7275) and instance of (P31): sovereign state (Q3624078) in the same item ? Sovereign state is not a state ?
• what do we need to have the full list of contains administrative territorial entity (P150) ? We can retrieve that list using the reverse property
• what do we need to have the full list of head of state (P35) ? We can retrieve that list using a reverse query
• what do we need to have the full list of head of government (P6) ? We can retrieve that list using a reverse query

The problem is not the size of the items but the manner to store data using a wikipedian approach: everything should be in an unique item instead of using a database approach where lists are always the result of a query.

Reverse properties are a stupid thing: they just increase the size of the database without improving the database. Snipre (talk) 12:49, 6 October 2014 (UTC)

@Snipre: resolving those example will reduce size for sure, but still there are some things like population (P1082), female population (P1539), male population (P1540), i.e. table data. Table data will only grow. -- Vlsergey (talk) 13:06, 6 October 2014 (UTC)

@Vlsergey: We have to fix problem one after one: table data implies a new datatype (headers+data in a format allowing rows and columns structure). A selected format can be used in the string datatype which will be parsed in lua to create tables but again this is currently not the main problem: the current problem is size of items due to redundancy data. Snipre (talk) 13:56, 6 October 2014 (UTC)

Re Vlsergey: 1. I was wondering about the same thing. 3. bug 47930 covers arbitary access on all wmf projects that wikidata supports and won´t be marked as fixed until all of those projects have arbitary access. Wikidata does have arbitary access (through lua, not parser functions) and in the case where an single article displays hundreds of items you will get an timeout error. 10 items on a single page however is managable.--Snaevar (talk) 12:59, 6 October 2014 (UTC)

@Snipre: How we can do a reverse query on Wikipedia side? --ValterVB (talk) 19:47, 6 October 2014 (UTC)

@ValterVB: For the case of the head of government you query all persons having position held (P39) = President of Germany (Q25223) to get the list and for the current person holding the position you use the qualifier start time (P580) to filter the list.

From WP side, use lua models. For example you can already do a lot of filtering using module:Wikidata so you can create other modules to extract data and to put them in the right format. 141.6.11.21 11:20, 7 October 2014 (UTC)

No, you can't. There is no query functions in LUA client (neither in Wikidata Repo itself), so making reverse query (or any other type of query) is currently impossible from templates or LUA (unless you are using some caching bots or other hacks). -- Vlsergey (talk) 12:45, 7 October 2014 (UTC)

Need help splitting item

The item armored warfare (Q568312) needs to be split into "Armoured warfare" and "Armoured troops". However, for most languages I can not determine if the article is about warfare or troops. German, Swedish, Danish and Norwegian are clearly about armoured troops while English, Netherlands and Catalan are about armoured warfare. For the rest, I have no idea. /ℇsquilo 15:53, 6 October 2014 (UTC)

Russian and Polish are for troops.--Ymblanter (talk) 12:40, 7 October 2014 (UTC)

The French article, i.e. Guerre blindée, is about warfare. --AFBorchert (talk) 17:45, 7 October 2014 (UTC)

Thank you both of you! Since Танковые войÑ?ка (russian) are about armoured troops I assume that the similary spelled bulgarian, belarus and ukrainian articles also are about troops. They are now moved to armoured troops (Q18198588). /ℇsquilo 11:24, 8 October 2014 (UTC)

unable to change entries while logged in

I'm somehow no longer able to change Wikidata entries while logged in. When I click the "edit" link for site links, only a small vertical bar appears:

It affects both Firefox and Internet Explorer, and changing skins does not solve the issue. The form does work when I'm logged out. Anyone else experiencing this? --Ixfd64 (talk) 23:34, 6 October 2014 (UTC)

Does the JavaScript console (Firefox: Ctrl+Shift+K, assure that the "JS" button is activated in the console) report you any problems? --YMS (talk) 09:13, 7 October 2014 (UTC)

This is intended, the save button for all entries you can edit there is above the site link section now. Cheers, Hoo man (talk) 22:20, 7 October 2014 (UTC)

It is supposed to be a "[Save]" button where there is just a "|" in the screenshot above. /ℇsquilo 06:21, 8 October 2014 (UTC)

"[save|cancel]". --Stryn (talk) 06:31, 8 October 2014 (UTC)

Living style

for Mystic (Q18195859) or vegetarian which property do you suggest? I check and we don't have property for living style.As you know Mystic (Q18195859) is not religious topic and it is common. Yamaha5 (talk) 05:35, 8 October 2014 (UTC)

You could propose a property. I was also thinking that we need something like "self-identifies as". -Tobias1984 (talk) 07:20, 8 October 2014 (UTC)

instance of (P31)+mystic (Q12328016)--Giftzwerg 88 (talk) 15:40, 8 October 2014 (UTC)

Wikipedia inclusion examples

Naive question here. This page says that infobox inclusion from Wikidata is now available on all Wikipedias. I can see the interlanguage links everywhere, but can someone point me to examples on English Wikipedia where infobox inclusion is in fact used? Cheers, Andrew Su (talk) 17:01, 8 October 2014 (UTC)

Category:Templates using data from Wikidata (Q11985372) Matěj Suchánek (talk) 17:20, 8 October 2014 (UTC)

Things appear to be a bit slow in this respect, and English Wikipedia does not seem to be a leader. I think data are more heavily used in Russian. In some other languages, it may be mostly used for simple, non controversial things like authority control links or geographic coordinates (ca 14 000 pages in French and 7000 in Catalan). --Zolo (talk) 21:02, 8 October 2014 (UTC)

Standardizing statements for award received (P166)

We currently have at least three different ways of stating that someone has been awarded a Nobel Prize (Q7191). Comments are welcome at Property talk:P166#Standardizing_statements. Danmichaelo (talk) 13:00, 9 October 2014 (UTC)

Calligrapher

I want to add Calligrapher as occupation to people's Item but Calligrapher at local wikis is redirect to Calligraphy so it doesn't have Item. what should i do? I have this problem for many occupationsYamaha5 (talk) 08:10, 7 October 2014 (UTC)

Check if another language has this item as occupation, if so add an label for your language. If not, create the occupation as a new item (thus without sitelinks) and add sufficient labels so other users can find it also. Michiel1972 (talk) 08:40, 7 October 2014 (UTC)

I think the French wiki has an item about the occupation (calligrapher (Q3303330)). Michiel1972 (talk) 08:46, 7 October 2014 (UTC)

Thanks I added claims and labels to calligrapher (Q3303330)Yamaha5 (talk) 08:50, 7 October 2014 (UTC)

There is another item about about the occupation: calligrapher (Q17487834) --Pasleim (talk) 08:51, 7 October 2014 (UTC)

@User:Michiel1972 How about "Literary" ? I checked in Persian and English wikipediaYamaha5 (talk) 08:56, 7 October 2014 (UTC)

Actually "maître-écrivain" appears to be a subclass of calligrapher, as it only applies to some French calligraphers from the 16th to the 18th century. The French general word would be "calligraphe".--Zolo (talk) 09:30, 7 October 2014 (UTC)

Should all occupations be separate items from their skills?

For example, should be have:

• teaching and teacher
• accounting and accountant
• lion taming and lion tamer
• race car driving and race car driver

Right now, we usually just have one or the other. Kaldari (talk) 00:46, 8 October 2014 (UTC)

The trend is certainly going in the direction of separate items for a field and the corresponding occupation. There are already more than 1500 professions with their own item. Pichpich (talk) 02:32, 8 October 2014 (UTC)

We should not use the occupation for the skill, nor the other way around (item classification issues etc.). Occupation items are needed given that we use occupation (P106), and have properties like SOC Occupation Code (2010) (P919). Not sure we always need an item for the skill though. "Race car driver" is useful, racing car mechanic exists, but I am not sure "race car driving" and "race car repair" are needed. --Zolo (talk) 12:22, 8 October 2014 (UTC)

@Pichpich, Zolo: The down side of splitting them is that it will break lots of interlanguage links. For example, I just split off hatmaker from hatmaking. It looks like most of the interlanguage links from hatmaking actually belong in hatmaker. Thus the English article hatmaking will eventually be left with no interlanguage links, even though "hatmaker" redirects to "hatmaking" there. Kaldari (talk) 23:15, 8 October 2014 (UTC)

@Kaldari: Ultimately, the solution has to be to allow site-linking to redirects, with a badge saying that they are redirects. Site-linking to redirects would solve a lot of problems. Jheald (talk) 23:38, 8 October 2014 (UTC)

Filed Bugzilla: 71859 to request that. Kaldari (talk) 00:13, 9 October 2014 (UTC)

Occupation can link to a fairly general item with 'field of work' used to focus on the particular aspect that applies in each case. So we can have 'occupation:driver', field of work:car racing' instead of 'race car driver'. Filceolaire (talk) 20:27, 9 October 2014 (UTC)

Best practices for ontology of cities

Currently, city items on Wikidata seem to follow a bewildering array of practices:

• continent: <continent>; country: <country>; is in the administrative territorial entity: <state>, <county>
• country: <country>; is in the administrative territorial entity: <state>, <county>
• country: <country>; is in the administrative territorial entity: <county>
• country: <country>; is in the administrative territorial entity: <state>
• is in the administrative territorial entity: <state>, <county>
• is in the administrative territorial entity: <county>
• is in the administrative territorial entity: <state>
• country: <country>;

Questions:

1. Is every city supposed to have a country claim (even if it also has a claim to a smaller territorial entity)? This seems to be common practice currently.
2. Should 'is in the administrative territorial entity' be limited to only the smallest entity the city belongs to or all of the entities it belongs to?
3. Is there an existing city item that demonstrates best practices?

I'm currently working on some Wikidata-related software for MediaWiki and we're considering adding cities as one of the types of items it would handle, but we need to have a better idea of best practices before we implement it. I took a look at Wikidata:WikiProject Political geography, but the advice there just made me more confused. Kaldari (talk) 00:35, 9 October 2014 (UTC)

For 1, I am pretty sure the answer is yes. For 2, I am afraid there is no consensus, though I will not be able to find where it has been discussed.--Ymblanter (talk) 09:45, 9 October 2014 (UTC)

This you certainly know.--Oursana (talk) 10:08, 9 October 2014 (UTC)

Yes, indeed, I have seen it, thanks. Do you know whether there were any discussions afterwards?--Ymblanter (talk) 10:34, 9 October 2014 (UTC)

On question 1 and 2 I would say yes. On question 3 no. /ℇsquilo 15:20, 9 October 2014 (UTC)

The problem, as I see it, is that for many cities there is no agreed definition for where the city extends to and what are it's limits, even where there is an administrative territorial entity called 'city'!

If an item does refer to a defined administrative territorial entity then it should always have an 'is in the administrative territorial entity' statement linking to the next larger entity. This might be a state or a country or a county. Filceolaire (talk) 19:32, 9 October 2014 (UTC)

That problem can be solved in two ways: By setting located in the administrative territorial entity (P131) to the smallest administrative territorial entity that the whole city fits into. Or by setting it to (a list of) all administrative territorial entity that the city extends into. I prefer the first way. For example: Stockholm (Q1754) should be in Stockholm County (Q104231). Not in Stockholm Municipality (Q506250) and Solna Municipality (Q109010) and Sundbyberg Municipality (Q972564) and ...

The first way also works regardless of whether the "city" is defined as an urban area or an administrative territorial entity. /ℇsquilo 06:38, 10 October 2014 (UTC)

subjects of things other than works?

I recently added a claim: the main subject (P921) of Nikos Kazantzakis Museum (Q4306167) is Nikos Kazantzakis (Q214622). But now I'm not sure if this is correct usage, or if main subject (P921) is intended only for the subject of works like novels, plays, etc., rather than museums. In cases where the subject is a broad one, field of work (P101) could be used instead, e.g. if a museum's subject is history, or marine science. But a biographical museum about a specific person seems more specific than a field of work or discipline in the sense of field of work (P101). --Delirium (talk) 16:33, 7 October 2014 (UTC)

I think it is possible to create an item "biographical museum", corresponding to Category:Biographical museums (Q8300534), and use it together with a qualifier of (P642), or to create a new property. Danneks (talk) 18:00, 7 October 2014 (UTC)

Thanks, that's a good idea; I've taken the first option, creating biographical museum (Q18215329) for this purpose. --Delirium (talk) 18:48, 10 October 2014 (UTC)

Other calendars

We have many items (articles) that their dates are in another calenders and converting them to en:Gregorian calendar is not precise.for example converting en:Islamic calendar or en:Solar_Hijri_calendar years or centuries without day and month is not possible. please add support for these calendars some of them are listed at here (At the right box#Non-Gregorian calendars) which mediawiki supporting themYamaha5 (talk) 06:50, 8 October 2014 (UTC)

I agree with Yamaha! The en:Solar_Hijri_calendar is necessary in PersianWiki as well as we often use en:Islamic calendar for our historical event's articles. As Yamaha said above converting these calenders haven't got refine results commonly. Thanks for your helping!--Ārash ツ� 07:37, 8 October 2014 (UTC)

Technically speaking AFAIK the Wikidata can accept other calenders beside the current ones (with just some few adjustments) as an input but what output is the best? Can we just show them in Wikidata and convert it to Gregorian? or it's better not to touch it? Converting it would be rather challenging in technical side. Amir (talk) 14:31, 8 October 2014 (UTC) @Ladsgroup: if they are convertible we convert them.For many cases we can not convert them for example:

• 1393 (Solar Hijri calendar) can be 2014 or 2015 Gregorian calendar
• 14th century (Solar Hijri calendar) can be 20th or 21th century Gregorian calendar

so we should show them as they are input. for example 1393 (Solar Hijri calendar) or 1393 SH

Yamaha5 (talk) 15:53, 8 October 2014 (UTC)

There is something called precision: October 8th, 2014 is exactly equal to Mehr 16th 1393. When the precision is set to 11 convert is exact but when the precision is something else (let's say 9) we would have lose some precision due to the convert, as simple as that. Amir (talk) 16:01, 8 October 2014 (UTC)

I Know about precision!

When sources at fa:طالب آملی mention his birth was at 994 (AH) without any precise day or month how do you want to convert it's year?

If we set 994/12/1 AH it will 1586/11/13 Gregorian

If we set 994/1/1 AH it will 1585/12/23! Gregorian

Which converted year should we select? 1586 or 1585?

You can test it at here. we have this problem with many people which their death or birth's time mentions only as century or year without day and monthYamaha5 (talk) 18:13, 8 October 2014 (UTC)

994 AH is a precision 9 date, 1585-86 is a precision 8 date but a valid date, Do you understand it? 20:15, 8 October 2014 (UTC)

precision 8 refers to decade! I checked here we should use before and after for range of time. it is possible with bot but not reachable from wikidata's UIYamaha5 (talk) 07:03, 9 October 2014 (UTC)

I also agree with Yamaha5. It is very much needed. Please kindly proceed. Regards, In fact (talk) 16:29, 10 October 2014 (UTC)

VlsergeyBot blocked

Since my bot is blocked it effectively means that ruwiki integration with Wikidata is stopped. In the following week my bot will gather all information from Wikidata and will put it in ruwiki articles back, which means ruwiki will not use wikidata as primary storage anymore. Thank you all, it was very interesting experience. -- Vlsergey (talk) 11:59, 10 October 2014 (UTC)

@Vlsergey: I know working with WD sometimes can be rough. Good luck & thanks for your efforts! --Kolja21 (talk) 13:53, 10 October 2014 (UTC)

Hey Vlsergey, I think rather than feeling that offended you could join the discussion on WD:AN and help to find the best solution for all of us. However, if you don't want to talk to us I still want to thank you very much for your work on the project. -- Bene* ^t_a^l_k 22:06, 10 October 2014 (UTC)

 Oppose WD is not only for u, it's for every wikimedians, then I gotta be the new caretaker of your RFDed lists. --Liuxinyu970226 (talk) 05:46, 11 October 2014 (UTC)

@Liuxinyu970226: It's not up to us to change a personal decision of his. We can only encourage him to change it but if he doesn't, we can't do much about it.--Jasper Deng (talk) 05:59, 11 October 2014 (UTC)

We have a pretty relaxed implementation of bot policy. Vlsergey decided to ignore this after repeated requests. Than your bot will be blocked. That's pretty much how it works on every Wikimedia project where I'm active. Users who leave with lot's of noise and slamming doors tend to come back just as quickly. Of course he (and his bot) is welcome to return, but if you want to be part of a community you have to respect it's rules and practices. Multichill (talk) 12:17, 11 October 2014 (UTC)

problem with kolabel

RIE (Q396582)(RIE) and Rie (Q7333047)(Rie) should have same korean label(리�) but I can't set proper label because of error: "Item Q396582 already has label "리�" associated with language code ko, using the same..." How can I solve this problem?--Konggaru (talk) 02:23, 12 October 2014 (UTC)

It can not go to two different places. These need to be sorted out. One is a name, Rie, the other is a disambiguation page. Some languages go to one, some to the other. 76.24.193.7 03:43, 12 October 2014 (UTC)

Fixed. Rie is the name, RIE the dis page. The Korean link went to the correct place. 76.24.193.7 04:07, 12 October 2014 (UTC)

Number of wikipedia's with list

Hi, Can I get a list of pages which has been created more than 30 languages? Or the list of wikidata-items which contain 30 wikipedia versions or more.☆★Sanjeev Kumar (talk) 09:10, 11 October 2014 (UTC)

Ok. Created a query and it's currently running. Result will be at this page. Have fun. Multichill (talk) 13:53, 11 October 2014 (UTC)

It's quite the list with 88200 items on it :-) Multichill (talk) 14:34, 11 October 2014 (UTC)

Very interesting, thanks a lot.--Ymblanter (talk) 15:51, 11 October 2014 (UTC)

Thanks a lot. It is very usefull for small wiki-projects.☆★Sanjeev Kumar (talk) 12:51, 12 October 2014 (UTC)

I did another query to find which of these items don't have a link to the Dutch Wikipedia. The result is about 11.000 items. Looks like templates and categories need to be filtered out to get to something useful. Of the normal articles on top of the list, the top one was deleted at the Dutch Wikipedia as cross Wiki spam (Huang Xianfan (Q5208) / nl:Huang_Xianfan). You can run this query for other Wikipedias too, just change the language code in the query. Multichill (talk) 13:11, 12 October 2014 (UTC)

Katharinenkirche, Oppenheim

I would like to add the above en article to the languages of Q1736086. --Gerda Arendt (talk) 12:24, 12 October 2014 (UTC)

 Done What was the problem? --ValterVB (talk) 12:31, 12 October 2014 (UTC)

Badge for featured portals

I think we also need a badge for featured portals. Btw, what is the status of Bugzilla:70268 and Bugzilla:70332? When we can use them? --Stryn (talk) 13:51, 10 October 2014 (UTC)

About the two open ones: It is on @Aude:'s todo list for the coming week. She's been too busy firefighting this week unfortunately to get it done. --Lydia Pintscher (WMDE) (talk) 20:26, 10 October 2014 (UTC)

Why not an alias of featured article (Q17437796)?! --Liuxinyu970226 (talk) 05:53, 11 October 2014 (UTC)

Well, then the sidebar on wiki would say "featured article" even if it's a portal. --Stryn (talk) 08:27, 11 October 2014 (UTC)

@Stryn: I have created an item for featured portals. It is featured portal (Q17580674).--GZWDer (talk) 14:00, 11 October 2014 (UTC)

Are there any objections left for this badge? If not I can file a bug report to get it done. --Lydia Pintscher (WMDE) (talk) 09:07, 15 October 2014 (UTC)

@Lydia Pintscher (WMDE): I filed bugzilla:73193 to request this badge. Orlodrim (talk) 13:24, 9 November 2014 (UTC)

Items to redirect

Hi everyone, I created a page with items which should probably be redirected. It contains about 4600 items. What should be we do with these items? Have a bot go over them and clean it up? Multichill (talk) 14:20, 12 October 2014 (UTC)

Yes, I think so. Lymantria (talk) 14:41, 12 October 2014 (UTC)

I agree but also I would expect a higher count. Matěj Suchánek (talk) 17:17, 12 October 2014 (UTC)

Perhaps because "rev_len < 300" does not filter larger merges? Lymantria (talk) 07:55, 13 October 2014 (UTC)

Related question: Is there an easy way for regular people to redirect items? The only way I see is through a gadget button on RfD... Ajraddatz (talk) 18:47, 13 October 2014 (UTC)

@Ajraddatz: The Merge gadget? Matěj Suchánek (talk) 20:04, 13 October 2014 (UTC)

The merge gadget is great and I can definitely recommend it for this. Andrew Gray (talk) 20:18, 13 October 2014 (UTC)

Hmm, for some reason I didn't think it could redirect... but it can. Thanks :-) Ajraddatz (talk) 21:23, 13 October 2014 (UTC)

@Ajraddatz, Matěj Suchánek, Andrew Gray: FYI: You can also use QuickStatements, though it currently have bug and thus some pages can not be redirected (@Magnus Manske:).--GZWDer (talk) 05:28, 14 October 2014 (UTC)

Thanks to the people helping out. If you copy my common.css you can see which ones are done and which ones still need to be done. Multichill (talk) 15:36, 14 October 2014 (UTC)

Two new badges

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

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)

"The time allocated for running scripts has expired."

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?

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

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:

• Wikidata:Referencing improvements input
• Wikidata:Constraint violation report input

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

NEED WIKI MAIL/CHAT

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)

Suggested interface change

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 Alaska (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 Alaska (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)

New UI is very bad

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

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)

Discussion about statements on properties

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)

Alternative uses of the monolingual text datatype?

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)

Two identical properties?

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

birth name (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 (OBSOLETE) birth name (use P1477) (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 (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 (replaces (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:

• Q5284?uselang=ru
• Q5284?uselang=zh

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 (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 (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 (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 (OBSOLETE) birth name (use P1477) (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)

Populated places, administrative districts, states and territories, by year

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! - FakirNL (talk) 11:09, 18 October 2014 (UTC)

Astronomical objects by year the same as asteroids by year?

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

• bosanski (bswiki): bs:Kategorija:Astronomski objekti otkriveni 1866.
• English (enwiki): en:Category:Astronomical objects discovered in 1866
• français (frwiki): fr:Catégorie:Objet céleste découvert en 1866
• italiano (itwiki): it:Categoria:Corpi celesti scoperti nel 1866
• norsk bokmÃ¥l (nowiki): no:Kategori:Himmellegemer oppdaget i 1866
• română (rowiki): ro:Categorie:Obiecte astronomice descoperite în 1866
• руÑ?Ñ?кий (ruwiki): ru:Ð?атегориÑ?:Ð?Ñ?трономичеÑ?кие обÑ?екты, открытые в 1866 году

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:

• español (eswiki): es:Categoría:Asteroides descubiertos en 1866
• Latina (lawiki): la:Categoria:Asteroides anno 1866 reperti.

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)

Complex query

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)

Authority control gadget

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)

Should people be human (Q5) or person (Q215627)?

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)

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)

Edit existing wikipedia links

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)

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

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"

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)

BIG problem with date adding

Tracked in Tracked in Bugzilla (?)
Bug 72393

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)

It looks like these api requests (formatting and parsing values) are not getting or using the language correctly. It's probably the same issue that affects both entering dates and formatting, and filed a bug for this. [1] Aude (talk) 13:41, 23 October 2014 (UTC)

WMF grant proposal including Wikidata outreach

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)

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

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 (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)

If the english speaking world can agree on one acceptable name for football (Q2736) that is all good and well. However, the need still exists for other words and other languages, particurlarly Brazilian vs. Portugese portugese. Should maritime pilot (Q475604) be named prático or piloto and should aviator (Q2095549) be named piloto or aviador? /ℇsquilo 06:41, 23 October 2014 (UTC)

Once again, the name is not particularly important - what is on the page is what is important, and a clear description. English Wikipedia frankly just lets whoever creates the page first use their flavor of English (and perhaps because there is a 5-8 hour time advantage, a relative majority are in en-BR). If Portuguese also has different variations, pt-PT, pt-BR, pt-somewhere else, it would, just like the flavors of english be useful to have a property that says "in pt-PT", or "in pt-BR" if the name used was in the other of those two variations. Chinese has resolved this issue by having different wikipedias for each, because the character set is different, but English and other languages (most others?) have chosen to avoid that unnecessary duplication, instead noting in each article the en-US, en-BR, en-AU spelling. 76.24.193.7 19:04, 23 October 2014 (UTC)

Commons AND Commonscat

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

You add Commons category on the WD item about the category, and the Commons page on the WD item about the page. Like this: Category:Paris (Q5626403) (Commons:Category:Paris) and this: Paris (Q90) (Commons:Paris). Hope this will help you. --Harmonia Amanda (talk) 16:53, 23 October 2014 (UTC)

@Herzi Pinki:. It's a known problem. See c:Commons:Structured_data/Short_introduction_to_Wikidata#Commons-Wikidata_sitelinks for some discussion. But yes, at the moment it means that Commons categories are not to be directly sitelinked to article-like Wikidata items.

What we may do soon, though, is to roll out a template to go on Commons categories, to link them to an article-like page on Reasonator (eg this for Paris), that would provide further wikilinks. But the identifier for the article-like item would probably need to be explicitly included as a parameter to the template, because it's not the same as the category-like item the category would naturally be linked to; and in any case most Commons categories don't have any category-like item.

For Commons galleries, we should be able to do something more sophisticated. A very very basic prototype for a Commons gallery header can be seen at d:Template:SimpleCommonsGalleryHeader/test. To implement this requires Phase 2 access to Wikidata to be enabled for Commons; an RfC to request this is now open on Commons. Jheald (talk) 12:57, 24 October 2014 (UTC)

Move sitelink?

Tracked in Tracked in Bugzilla (?)
Bug 72019

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* ^t_a^l_k 07:47, 14 October 2014 (UTC)

Thank you both. I would like to point out that the move gadget is not only useful for people who want to move sitelinks. It is also advantageous for people who want to check the changes on the items on their watchlist. The gadget leaves an edit comment with a link to the new item. If sitelinks have been moved 'manually', you don't see why they disappeared on the old items.

Last week, when I wanted to move 2 links, I forgot to press 'save' when deleting the links on the old item. Therefore adding them on the new item resulted in an error. I spent 10-15 minutes in new tries. Bever (talk) 07:23, 21 October 2014 (UTC)

On Bugzilla (where I cannot edit, as I am not registered there), John F. Lewis replied to Bene's proposal with 'In the core as a feature - yeah but likely to be obsoleted by plain merging?' I do not know what 'plain merging' is, but between the 'merge' tool and the 'move' tool there is a big difference. With merge, you move all information (all sitelinks, properties, labels etc.) to another item. With the move tool, you can move 1 sitelink if it is just placed on the wrong item, leaving the rest of the item as it is. Bever (talk) 06:08, 25 October 2014 (UTC)

Changing datatype

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

I can not even see any way to create a property, let alone set the datatype. Help:Data type describes the datatype but does not say how to change it. 76.24.193.7 06:01, 25 October 2014 (UTC)

It's not possible to change a datatype. The only way is to create a new property and delete the old one so you might first start a discussion at WD:PFD. --Pasleim (talk) 12:31, 25 October 2014 (UTC)

Can not edit (is this page protected?)

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

@Was a bee: Checked, it's not protected from what I see. I can't edit it either. --AmaryllisGardener ^talk 02:23, 25 October 2014 (UTC)

I cannot see what you are trying to add, but none of the Wikidata data pages have an edit tab at the top - I see all the usual edit links, and when I click on them they open as usual. 76.24.193.7 05:17, 25 October 2014 (UTC)

Thank you @AmaryllisGardener:, @76.24.193.7:. Now I can see edit links at that page. Hmm... mysterious phenomenon. But anyway, now it's ok. Thanks :D --Was a bee (talk) 07:31, 25 October 2014 (UTC)

Yes, it is a bizarre and unfamiliar user interface, very different from what anyone who is familiar with editing wikipedia is expecting. 76.24.193.7 12:11, 25 October 2014 (UTC)

LUA test to see if qualifier is used

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

Maybe something like:

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

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

That's already a bit more than I needed :-). Probably could have a more general function qualifierInUse(<some property>) than just returns True or False. Multichill (talk) 12:34, 25 October 2014 (UTC)

If you use it in wikitext, you can use {{#if: {{#invoke:}} | }}. I made a change to the code. Matěj Suchánek (talk) 13:01, 25 October 2014 (UTC)

Redirects cause bad merges

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

The problem was caused because a link was made to a redirect. Redirects can not have wikidata links, and it has been removed. There used to be an en article about the subject[2] but it was deleted and changed into a redirect. When that was done the wikidata link needed to be removed. 76.24.193.7 12:17, 25 October 2014 (UTC)

No, you are wrong. Redirects can have wikidata links, but for now adding them is quite non-obvious. This example shows that redirect link in an item is useful, because it helps to get specific information even if it is in the other article now. --Infovarius (talk) 14:10, 25 October 2014 (UTC)

I am going to need a link to something that says that. Redirects have always been prohibited, and for very good reason. 76.24.193.7 18:02, 25 October 2014 (UTC)

CF Wikidata:Notability "Note that a single Wikimedia page cannot have more than one sitelink in Wikidata and that a sitelink cannot point to a redirect." So you can not link to a redirect, and you can not link to a section of a page, because that would be two sitelinks to the same Wikimedia page. 76.24.193.7 18:19, 25 October 2014 (UTC)

That's the notability policy, not the linking policy. And could we have this discussion in one place and not, as at present, in at least three? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:13, 25 October 2014 (UTC)

All policies and guidelines inherently are consistent with each other, otherwise they are meaningless. The correct place to discuss this topic is here ("This page documents a Wikidata policy. It is a widely accepted standard that all editors should normally follow. Changes made to it should reflect consensus. When in doubt, discuss your idea on the project chat."). The correct place to discuss someone not following the policy is on their talk page, and the correct place to discuss an item that is repeatedly changed in violation of policy is on the talk page of the item that is being changed. So that is three topics, and three different appropriate places to discuss them. There is a fourth place this is being discussed Wikidata:Requests for comment/A need for a resolution regarding article moves and redirects, but the correct place is here, although this topic could be easily consolidated to the RFC page, to keep it in one place. 76.24.193.7 03:53, 26 October 2014 (UTC)

Sadly, you have ignored my suggestion that we have this discussion in one place and not in at least three (actually now five; you omitted User:Styko's talk page). I have just replied to a comment near-identical to your first point, which you made on my talk page. If you believe I have breached policy, take the matter to the admin notice board; then you can add another to your list. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 26 October 2014 (UTC)

What for? Breaching policy is not a blockable offence, unless it becomes persistent - newbies do it all the time. We do not take every little thing to the admin notice board, but only things that require the action of an admin. We discuss them on the users talk page. As to where this discussion is held, you are welcome to add "discussion moved to/continued at XXXX" on four of the five. 76.24.193.7 16:26, 26 October 2014 (UTC)

Monolingual text fields and Norwegian names

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

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

Prices and price indices

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

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

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

Meta RfCs on two new global groups

Hello all,

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

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

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

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

can not add reference

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

What is something you wish add? 76.24.193.7 16:53, 26 October 2014 (UTC)

I tried to add P170 to The servant girl (Q17334200), and the "save" was not a live link - is it looking for something else, other than "Willem van Odekercken"? The save link does becomes live if I put in a Q item. That particular painting though, is actually "attributed to Willem van Odekercken", if the google translation is correct, so is there a property for that? 76.24.193.7 18:56, 26 October 2014 (UTC)

I can confirm that there is an issue with Zürich (Q72). Reported it to Wikidata:Contact_the_development_team#Q72. The problem with The servant girl (Q17334200) is, that the property creator (P170) has data type "item" but there is no item about "Willem van Odekercken" yet. That means you have first to create an item about Willem before you can add it as a value. --Pasleim (talk) 20:11, 26 October 2014 (UTC)

Expedition leaders etc.

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

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

Impending deletion of Persondata template and associated metadata

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

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

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

I am not sure if it's enough to use labels and aliases to replace these templates. We need real name-properties. -- Innocent bystander (talk) 18:16, 23 October 2014 (UTC)

Can you elaborate? Are you referring to importing the NAME as a sortable name? The aliases can probably be imported as is. Kaldari (talk) 18:21, 23 October 2014 (UTC)

I have not been active here the last months, but properties for name, birthname etc should be created as soon as technically possible. And NAME/ALTERNATIVE NAMES should use such properties, to be able to add statements and sources. -- Innocent bystander (talk) 18:28, 23 October 2014 (UTC)

Regarding: "import this valuable collection of metadata before it gets deleted" - as far as I understand the outcome of the RfC in English Wikipedia, there's no danger that metadata will be deleted prematurely. No one wants to lose data, I suppose. The Persondata template in English Wikipedia can/will be deleted when it's really made obsolete by Wikidata, but not before. - Likewise, I think also the data from German Personendaten should be imported here, of course. Gestumblindi (talk) 20:53, 23 October 2014 (UTC)

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

Morning, I think it will be make sense to import the data for german Wikipedia, too. So I leave a text at the botrequest --Crazy1880 (talk) 05:31, 24 October 2014 (UTC)

Supplement to the text of Kaldari. The name is usually represented as follows: NAME = Property:P735, Property:P734. --Crazy1880 (talk) 05:43, 24 October 2014 (UTC)

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

Proposal posted; see Wikidata:Property proposal/Generic#Sort_key.

Jheald (talk • contribs • logs), Persondata DOES NOT contain sort value for names. The |name= is supposed to be surname, firstname. About 20% of the cases, it is entered wrong, usually firstname, surname. DEFAULSORT contains the sort value in all Biography articles. Sort value does not equal surname, firstname in alot of cases.

Examples:

Otto von Bismark... DEFAULTSORT:Bismark, Otto persondata |name=von Bismark, Otto.

Francisco da Costa Gomes... DEFAULTSORT:Gomez, Francisco persondata |name=da Costa Gomes, Francisco.

Bgwhite (talk) 00:55, 28 October 2014 (UTC)

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

I've replied there. I suggest we all agree to conduct discussion in one, not two, places. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:37, 24 October 2014 (UTC)

Link? Where is "there"? 76.24.193.7 17:26, 26 October 2014 (UTC)

Wikidata:Bot_requests#Import_Persondata_from_English_Wikipedia --Pasleim (talk) 17:37, 26 October 2014 (UTC)

Unused items

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

There is no policy that items must have at least one link. According to WD:N, also an item is accpeted if it is about a clearly identifiable conceptual or material entity or if it fulfills some structural need. --Pasleim (talk) 19:15, 26 October 2014 (UTC)

Thanks, I see that now. Not sure how I missed the words "at least one", especially because it is in bold. The item has a link to the commons image already, is that better than the link that was added? 76.24.193.7 20:50, 26 October 2014 (UTC)

Yes, to link to a commons image we should use the property image (P18). Adding a sitelink to a file is actually not allowed according to WD:N point 1.1 --Pasleim (talk) 10:15, 27 October 2014 (UTC)

type of

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

steak burger (Q18338265) subclass of (P279) something. --Diwas (talk) 19:17, 22 October 2014 (UTC)

Thanks, but does that work instead of instance of? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:10, 22 October 2014 (UTC)

Yes, instead of instance of. There are tons of steak burgers, and there are subclasses of it, like the Burger King Sirloin Steak sandwiches or like all steak burgers you eat ever, but the one you bite maybe tomorrow is an instance of steak burger (Q18338265) and an instance of the subclass of your own steak burgers. --Diwas (talk) 23:12, 22 October 2014 (UTC)

There is a nice tool for browsing subclasses, which can display, for example in this case, subclasses of "food product" as a tree or as a list. So many sausages!

Sometimes I have been confused about whether to call something an instance or a subclass. There's some explanation at Help:Basic membership properties, but I would really like a list of examples, and ideally parallel lists aligned by property, e.g. instances of human versus subclasses of human. --Haplology (talk) 09:29, 23 October 2014 (UTC)

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

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

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

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

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

1980 in France is not a real chronicle (Q185363), since it is just a title of an overview article created by wikipedians. So I would suggest to make an item Wikimedia year chronicle similar with Wikimedia history article (Q17524420). Michiel1972 (talk) 09:30, 24 October 2014 (UTC)

I created article about events in a specific year or time period (Q18340514). Michiel1972 (talk) 09:39, 24 October 2014 (UTC)

Thank you very much :) --Hsarrazin (talk) 20:01, 25 October 2014 (UTC)

@Hsarrazin, Michiel1972: Hi guys, I'm not sure about that. 1980 is a year, for sure. A wikipedia article about this year is something different. Yet we do not say the item about 1980 is a chronicle. It is an article about that year. I think the got the same for 1980 in France : it is an article about the events that took place in france in 1980, so the topic for the article is events in france in 1980. This is a subclass of events, I would also say, per help:classification that it is an instance of class of events in a year in a country, for example. TomT0m ^(talk) 09:38, 28 October 2014 (UTC)

TomT0m, I don't like the label either... I agree, "chronicle" is maybe not the best name, even if it matches the global meaning of chronicle, which means a regular narration of events, in chronological order...

the most important thing, to me, is to have a "clear concept" to link to... - its label and descriptions can be discussed - obviously, this item is a success : already 5375 of linked "year articles" - and not all by me ;) --Hsarrazin (talk) 10:33, 28 October 2014 (UTC)

@Hsarrazin: it's also imortant to be consistent project wide. When we say that Barrack Obama is an instance of human in a statement, it is accepted that <human> is a class of real world object, and that Barrack Obama belongs to it. When we write an article linked to this item (Obama's), we are not writing an article about Barrack Obama's biography. But there may be an item labelled <Barrack Obama's biography>. A different one. The Wikipedia article on the <Barrack Obama> may be a biography ! but it's not about Barrack Obama's biography external work ... I think that when we write an article about a year in some place, we face the same problem. The article may be a chronology, a journal of whatever, but the item he is linked to with instance of or subclass of must be about the topic, not referring to the form of the wikipedia article, which may be language dependant. Or we are not consistent in instance of (P31) and subclass of (P279) usage. The raw number of the item usage does not change really this and may really well be the work of only one user with the help of an automated tool. If we don't do that we lose a lot of the usefulness of structuring datas and go back to the old categories with no clear meaning :) TomT0m ^(talk) 11:38, 28 October 2014 (UTC)

@TomT0m:, whatever the language, these articles are yearly synthesis of a subject (country, sport, entertainment, etc.) - so, what P31 do you suggest to use ? :) --Hsarrazin (talk) 14:36, 28 October 2014 (UTC)

erroneous label in farsi (or arab) in en label

Hello,

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

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

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

Unreachable parts of online databases

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

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

Or 42410181. --Succu (talk) 13:30, 28 October 2014 (UTC)

Item Left (Q3556716) for disambiguation pages

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)

That was a bit pre-mature, and pretty odd to only have the criteria that everything on the page use the same spelling as the English word "Left". What you ended up with is linking two disambiguation pages that have no pages in common with each other. And a dozen disambiguation pages for left that have no indication that there is an English disambiguation page for left. If you are going to "split" it how about start by removing the only page that you left - the one that has nothing to do with left? Wikidata pages refer to meaning, not spelling. The word gift in Swedish means poison, you can not link it to a disambiguation page for the english word gift, for example, just because it is spelled the same. And you linked the fr entry with en Gauche, even though the two dis pages have no links about the same subject. Ditto for la - you just linked to the English dis word for Sinister because they are spelled the same and the two dis pages have no links in common. It is always only meaning that causes a link, never spelling. I suggest just reverting all of your edits and starting over in a more meaningful manner. I am beginning to see how someone would say that the new wikidata links are useless when people make choices like this in grouping pages. The inherent problem is that the old way only native speakers were dictating where links were going, here someone who knows nothing about the language is deciding. Looking at the table I see none of these that need to be removed. 76.24.193.7 08:38, 23 October 2014 (UTC)

Language	Page	Link1	Link2	Link3	Link4	Link5	Link6
ar	â€?(Ù?سار (توضÙ?Ø­	left (direction)	Left-wing politics	Suleiman ibn Yasar
br	Kleiz (disheñvelout)	left (direction)	chalk
de	Links	left and right (directions)	left (politics)	link(computer hyperlink)	Links (web browser)	golf course (links)	people and companies named link
el	ΑÏ?ιστεÏ?ά	left (politics)	left (direction)
en	Left	left (direction)	Left (album)	left (politics)	Left (Marxist)
es	Izquierda (desambiguación)	many political parties	left (direction)	left handed	left hand rule
eu	Ezkerra (argipena)	surname	left (politics)	left (direction)	left handed
fa	Ú†Ù¾	left handed	left (politics)	political party
fr	Gauche	left (politics)	political party	political movement	metallurgy (a "left" is a piece that is twisted)	clumsy	left (direction)
he	ש×?×?ל	left (direction)	left handed	left (politics)	Left Hand of Darkness (book)	wind from the left
ja	レフト	left fielder (baseball)	a volleyball term	left (politics)
la	Sinister	German political party	Italian political party
lb	Lénks	left (direction)	left (politics)	homosexual
nl	Links	left (direction)	left (politics)	left handed	Links (film)	Links (web browser)
ro	Stânga	left (direction)	left (politics)	political party	left handed	copyleft (a PD form of copyright)
zh	å·¦	left (direction)	left (politics)	surname	copyleft

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

My idea and reason is at User talk:YMS#Disambiguation page, and Wikidata:Project_chat/Archive/2013/11#Disambig_page_link.--GZWDer (talk) 10:01, 23 October 2014 (UTC)

That is a ridiculous idea. When we link wikidata pages for pages we link everything that has the same meaning. We do not link en:Gift with sv:Gift, because the words have different meanings. In Swedish Gift means poison. So we link en:Poison with sv:Gift. What we have to do is look at how the word is used on the disambiguation page, and link it to another disambiguation page with the same meaning. For example left, in English is a direction, but that same direction is called Gauche in French, so we link the en:Left dis page to the fr:Gauche page. It is meaningless to link the en:Gauche dis page to the fr:Gauche page, because none of the pages on either dis page are about the same subjects. In English, Gauche has a very different meaning than "left". When the disambiguation page guidelines talk about the same identical spelling, they mean on the wikipedia disambiguation page, so for example by our guideline, which is also absurd, we could not have any link at all to en:Left as per our guideline it is not a disambiguation page, because it includes items that are not spelled "Left", but instead includes "Left-wing politics". That is why that strict requirement is absurd. It does not mean that every item on the wikidata page has to be spelled the same in every language, which is even more absurd, but that is exactly what you have done. 76.24.193.7 10:37, 23 October 2014 (UTC)

FYI, it is possible from reading the discussion page that adopted that guideline, that is what the guideline says, and it was adopted with near unanimous support, with the comment, "IMO all articles on a one item have to be the same title. E.g. English disambiguation site "Yellow" should be Yellow in other wikis too, not translated name." That of course is ludicrous, as you can not tell someone that their disambiguation page for the color yellow can not be linked to every other disambiguation page for the color yellow, but you have to only link your disambiguation page for the color yellow for disambiguation pages in other languages that use a word that is spelled using the latin characters "Y E L L O W" even if that word has a totally different meaning in that language, such as, "a bath tub stopper". That idiocy has just been done in splitting this page, where "gauche" has been linked from the en word gauche to the fr word gauche, and since the word in English does not mean the same thing in English as it does in French, none of the links on the en page are the same as any of the links on the fr page. Another example is in Swedish "gift" means poison, so if that guideline was followed, a disambiguation page for sv "poison" would be linked to an en "gift" page, once again obviously with no links in common. Another preposterous statement appears in the discussion - "i. e., how can we tell which pages deal with the same item?" Why is that even a question? See the table above. There were some items on the linked pages that I could not identify because they go to red links, but it was not hard to generate the able and see what the links were. Just as a wikidata page for "Yellow Brick Road (song by Eminem)" is only going to have links to other language articles about that same subject, a wikitable page for the disambiguation page for "Yellow Brick Road" is going to have link to other disambiguation pages about the road in the Wizard of Oz, which of course has different translations in different language, as indicated on Yellow brick road (Q3444039), which right now has only 3 entries. And none of the others use the words "yellow brick road". But if there was a disambiguation page for any of them, they should all be linked to the other disambiguation pages. Right now Wikipedia is really only in English and a few other languages, and has not been "built out" into most of the other languages of the world, but when it does, the purpose of wikidata is to link all of the pages that are about the same subject, not pages that use the same spelling, which would be nonsense.

So instead of making hash of things, such as was done for the perfectly good page of "left as a direction or political direction disambiguation page" (fortunately some of the local wikis still use local interwiki links and not the totally useless links that are now provided), and making it into a "page of disambiguation pages on wikis that use a word that is spelled "left" using only latin characters with special characters such as accents or that are pronounced like the English word "left" but use characters that have a similar pronunciation, which is totally useless to anyone, as it is going to for most languages inherently going to be only a wikidata link to itself, totally making the entire wikidata project useless for any wikipedia disambiguation pages, I would suggest putting an immediate hold on implementing that aspect of the guideline, as it is sheer nonsense. 76.24.193.7 18:31, 23 October 2014 (UTC)

Yellow isn't «a disambiguation page for the color yellow» but a disambiguation page for the word Yellow. In disambiguation page you can found a movie of Cassavetas, a single of Coldplay, a manga of Makoto Tateno and in English also the color yellow. This is the use of disambiguation pages, if you join page with the same meaning you have a list that is another thing. --ValterVB (talk) 19:40, 23 October 2014 (UTC)

That is not useful. We always only have pages that are based on meaning, not on spelling, why would disambiguation be any different? How is it useful to line en:gift with sv:poison just because the word for "poison" is spelled "g-i-f-t" in Swedish? This is sheer stupidity to link disambiguation pages differently than every other type of page. 76.24.193.7 20:33, 23 October 2014 (UTC)

Disambiguation must be different because are very special pages, They have specific category, specific template and mediawiki software manage they with specific "magic word", there are some SPecial page like Special:DisambiguationPageLinks or Special:DisambiguationPages. They are necessary to guide user to the correct page. If I search Left I want something called Left, not something called Stânga so with disambiguation page I can select the page that I want. --ValterVB (talk) 21:03, 23 October 2014 (UTC)

Fortunately most of the disambiguation pages I have seen do not follow that absurdity, but instead in fact do use the meaning. For example, the disambiguation page for ja:yellow does not use one named "yellow", but instead groups all of the other uses of the color yellow, which in japanese is called "黄色", and by the guideline would not be included on the color yellow disambiguation page but would be on its own page, and be totally useless (a wikidata page is only useful if there is more than one wikipedia link on it). 76.24.193.7 20:56, 23 October 2014 (UTC)

Wikidata isn't only for Wikipedia projects. For no-latin alphabet, transcription is acceptable if don't exist the same word, but if exist we must link this (ex. A10 (Q228260) the japanese link is A10 in latin alphabet). --ValterVB (talk) 21:19, 23 October 2014 (UTC)

That does not address the issue that translations are important to use, and are much more important to use than either literal spelling (see the example of gift/poison) or transcription. For example, if some other language used a transcription of gift, but the same meaning as in Swedish, poison, instead of something that is given, it is not useful - the principle being that only meanings are important, never spelling. 76.24.193.7 02:02, 24 October 2014 (UTC)

Your principle that spelling is never important is not widespread in this community, as you can see by the accepted guideline on disambiguation pages. The problem with disambiguation pages and meanings/translations is that, per se, disambiguation pages cover homonyms in a language, of which often it is not clear what the "leading meaning" is. The set of homonyms differs from language to language. Therefore the wikidata-community chose to make spelling important in case of disambiguation pages. And it certainly turns out to be useful. Lymantria (talk) 11:38, 24 October 2014 (UTC)

Yes spelling can be important - but only for proper names. All that avoiding translations does is create Wikidata pages with only one entry, and when there are more than one, such as Left now, those two entries have nothing to do with each other (the Hebrew word for left has now been added, which of course is a violation of the guideline, unless it is pronounced "left"). Ditto for Gauche, which has been linked between fr and en, but since the words have different meanings, there are no pages on either dis page that are in common. Normally when you go to a disambiguation page, you find a list of the subjects that have a corresponding article in every language, which was how everyone created local interwiki links. Now we have en:gift dis linked to no:gift dis, but in Norwegian, "gift" means "poison", so the link is useless. The fact that other Homonyms exist in each language is simply not important. There can only be one Wikidata page for every page, so you just have to choose which page you are going to link it to (in de left is Links, so you can either make a link to a Wikidata page on people named Links, or the direction left, but not both), but you certainly are never going to link en:gauche with fr:gauche, or en:gift with no:gift, because they have different meanings in those languages. When you do look at the Wikidata pages for disambiguation pages, you will see that almost none of them follow the guideline, and instead use the translations to make the links. "Fixing" them, would be a disaster. 76.24.193.7 01:54, 25 October 2014 (UTC)

I would actually call it a flaw of Wikidata that you can not link to more than one page, because with local links you can, and of course if they are needed, local links can still be used, to avoid that limitation. These are the interwiki links that the German Links disambiguation page used, prior to migrating to Wikidata, and they link to the word in some languages meaning left, venstre, but include a link to the English page Venstre, which of course means neither left nor Links. 76.24.193.7 02:39, 25 October 2014 (UTC)

• cs:Venstre - left (politics)
• da:Venstre (flertydig) - left (politics) and left (direction)
• en:Venstre - left political parties named Venstre
• es:Venstre - left political parties named Venstre
• fr:Venstre - left political parties named Venstre
• it:Venstre - left political parties named Venstre
• lb:Lénks - left (politics), left (direction), and homosexual
• nl:Links - left (politics), left (direction), and items named "Links"
• nn:Venstre (fleirtyding) - left (politics) and left (direction)
• no:Venstre (andre betydninger) - left (politics) and left (direction)
• sv:Venstre - left (politics)

Of these I would call the en, es, fr, and it links incorrect, because none of the political parties on those pages are on the de:Links dis page. 76.24.193.7 02:39, 25 October 2014 (UTC)

FYI the idiocy of linking en:gift with no:gift (poison) predates Wikidata, and was placed on the en page in 2007. I am not particularly surprised that no one noticed the error, though. 76.24.193.7 02:54, 25 October 2014 (UTC)

I think the criticism of 76.24.193.7 is a good incentive to rethink some concepts on Wikidata and Wikipedia. Although disambiguation pages are primarily a tool for navigation when a user uses the search box, meanings do play a role when grouping links and information on them. The present guideline is too one-sided when ruling out this aspect.

On Wikipedia, I sometimes feel that the idea that disambiguation pages must not give any information (other than links) is in some cases too strict. It seems also that different versions of Wikipedia (and other Wikimedia projects) have different guidelines or practices regarding disambiguation pages, which can cause problems on Wikidata (interwiki conflicts).

76.24.193.7 also points at the reduction of useful interwiki links since the roll-out of Wikidata, which is not always in the interest of the end-user. In my opinion this is caused by some inherent conflicts in Wikidata, but they might be solvable. Bever (talk) 03:54, 25 October 2014 (UTC)

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

You know, many things can have several names, and these names often are some variations of the one one (e.g. synonims, or translations). So a list of "things known as X" easily can be a list of "things known as <translation of X>" in other language. --Infovarius (talk) 13:55, 25 October 2014 (UTC)

I don't really agree. That only really works to some degree if you only consider translations between two languages. Choosing one translation each of "X" from English into German ("Y") and French ("Z") for example, doesn't mean that "Y" and "Z" are also valid translations of each other. So translated interwiki links that might be somewhat valid on one language project could be mostly wrong in other languages. That's what we had in the past and it led to neverending changes of interwiki links because editors in other languages were constantly unhappy with the translations between the languages they knew, which in turn caused problems with the translation between other languages, and so on...

As I said above, those things known as "X" often have several equally valid translations in other languages. And each of those translations might have its own disambiguation page. E.g. en:Sphere (disambiguation): each of the things listed on that page could be translated as de:Kugel (Begriffsklärung) or de:Sphäre (Begriffsklärung). And in some cases (like works of art), the same name is used, so de:Sphere. And de:Kugel (Begriffsklärung) in turn could be translated as en:Sphere (disambiguation) or en:Ball (disambiguation). Or, depending on the context, even en:Kugel (disambiguation) or en:Bullet (disambiguation). And en:Ball (disambiguation) could be translated as either de:Ball (Begriffsklärung) or de:Kugel (Begriffsklärung). And so on... And that's just two languages. But we have to handle dozens of languages. There's simply no way to pick and choose just one translation out of several for each pair of languages and still maintain a matrix of valid translations between each and every language. Not to mention what happens when you have a disambig page title that's already taken from another language, e.g. en:Clair de Lune, en:Mondschein and en:Moonlight (disambiguation). --91.67.96.57 09:54, 26 October 2014 (UTC)

And all pages are simply links to "things known as X", where X uses different character sets and different characters in each language, for whatever the translation of X is in that language. Disambiguation pages are no different, with the exception that they also include items that are spelled that way in that language. But the only time that different language wikis can be linked to each other is if the meaning is the same on each page, not the spelling. Otherwise you inherently have only one or two links for every page, and 200 other pages that have that same meaning that are not linked to each other - but worse, you link words that are spelled the same but have different meanings, like en gauche with the french word for left, and the en word for gift with the no word for poison. Sure there are different thinks called Link, both in en and in de, but the de page is primarily for things meaning "left", not things named Link. We can always only have one wikidata page for each wikipedia page. Where there are more than one things you want to include, the advice is to merge the two wikidata pages, not split them. 76.24.193.7 02:44, 26 October 2014 (UTC)

You seem to confuse articles and disambiguation pages. Disambiguation pages are _not_ about a single primary meaning of a string of letters, that's what the articles are for. Interwiki links on articles are of course translated as the exact same thing often has different names in different languages. But disambiguation pages are strictly about things known by this specific string of letters, not about things named after the string of letter's primary meaning. So en:Yellow (disambiguation) is a list of things known as "y-e-l-l-o-w", but not necessarily a "list of things named after the color yellow". That's why it's linked to other lists of things known as "y-e-l-l-o-w" in other languages, not to things named after the local translations of the name of the color. Just like you wouldn't link a list of people with the surname Miller on the English Wikipedia to a German list of people with the surname Müller and a French list of people with the surname Meunier just because that's the literal translation of Miller. Interwiki links are for linking pages about the exact same thing on other projects. But a list of things called Gelb is not the same as a list of things called Yellow or Jaune or Amarillo. --91.67.96.57 09:54, 26 October 2014 (UTC)

The only time that different language wiki pages can be linked to each other is if the meaning is the same on each page, but the meaning of a disambiguation page is just the spelling of a simple search term. --Diwas (talk) 10:29, 26 October 2014 (UTC)

They link other items that are spelled the same because they have the same meaning, and because they have the same spelling. The en wiki dis page for Müller would have the same people on it as the fr, and de dis pages, because they are the same, and the pages for Meunier and Miller, although all three could also have a see also section for the other spellings. The different items for left are mostly because of items that have the meaning direction, either physical or political, and hence need to be linked to the other language wiki disambiguation pages with items about the direction left, either physical or political. Since gauche does not mean the same thing in en and fr, and gift does not mean the same thing in en and no, it makes no sense at all to link them. Disambiguation pages can only be linked if the words have the same meaning in each language, and the spelling/word(s) used, is irrelevant. 76.24.193.7 17:15, 26 October 2014 (UTC)

You suggest to split w:en:Gift (disambiguation) away from w:no:Gift (andre betydninger)"? But it means i. a. the same, the 1883 novel by Alexander Kielland. You suggest to split w:en:Gauche away from w:fr:Gauche? But it means i. a. the same, the Gauche conformation. --Diwas (talk) 19:35, 26 October 2014 (UTC)

The fr:gauche page is mostly about "left", the en:gauche page mostly about things named gauche, only three of which have fr articles, and none of those three are included on the fr gauche dis page. To be meaningful, the link needs to be to dis pages that primarily have links to the same things in each language, as was the case before the Left page was "split". As to gift, as bizarre as it seems, the connection is fine, because while in no, gift means poison and married (how lovely a connection), the pages are connected by the two novels named Gift. 76.24.193.7 20:38, 26 October 2014 (UTC)

Dear 76.24.193.7 You are right that each Wikidata item is about one concept or a class of associated items.

There are however two exceptions. Wikipedia Category pages get items even though they are usually about the same concept as another Wikidata item. We should probably combine Category wikidata items and the wikidata items covering the same concept.

The other exception is Disambiguation pages. These are about articles with similarly spelled names so Gift (english) shares a wikidata item with gift (german) and Links (english) shares a wikidata item with Links (german). If you want a list of leftist parties then that is an ordinary list, not a disambiguation page.

There is one exception have come across - one type of disambiguation page which may be considered a wikidata 'class'. These are disambiguation pages listing people with the same name. These can be a subclass of name and can be the target of 'Family name' or 'given name' statements. Filceolaire (talk) 22:07, 26 October 2014 (UTC)

A list of leftist parties would only appear on a disambiguation page if they shared a common word. The reason there are many left politics pages on the left dis page is that those particular items share the common word that means left in that language.

I would definitely not combine categories with pages, as they are different name spaces. The point though, about any link is that if you visit the page, it only makes sense it it makes sense to make a local interwiki link. When you look through history, you see that the left meaning disambiguation pages were linked to the other left meaning disambiguation pages, not to the spelled left disambiguation page, with the principle that to be a meaningful link to another language, the items on each page should also be linked, or at least some of them. But the problem of disambiguation pages containing multiple subjects is not unique to disambiguation pages. 76.24.193.7 23:11, 26 October 2014 (UTC)

The local interlikilinks had much interwiki conflicts, cause there are more than one meanings. – But the problem of disambiguation pages containing multiple subjects is not unique to disambiguation pages. Yes that is really true. --Diwas (talk) 09:35, 27 October 2014 (UTC)

How about requiring that a link to a disambiguation page go to the disambiguation page which has the most common pages, i.e. that are on the disambiguation page and link to each other. 76.24.193.7 03:37, 28 October 2014 (UTC)

You wrote: How can we dictate what each Wikipedia wants to put on their disambiguation page? that and the high count of languages is why there will be interwiki conflicts. Moreover you would have to check every month if some links in any language are new and the interwikilinks are to remap. The only way to get stable interwikilinks for all disambiguation pages are the title, not the meanings of the linked article pages. If we need connect disambiguation pages which have (or could have) many common pages, we need another way. --Diwas (talk) 11:19, 28 October 2014 (UTC)

There is nothing new about pages being out of date, and much less need to update, and reorganize wikidata items about disambiguation than it is to update wiki articles. I recently updated an article that was current as of 2007, and brought up to date the vi article on the ebola outbreak that was current as of August, but I would not like to force items about disambiguation articles to not include the logical articles. 76.24.193.7 01:43, 29 October 2014 (UTC)

To update an article, you need only one language and only one reference. To update an item about most-common-links disambiguation you check maybe hundreds of disambiguation pages (many languages and many links common with further disambiguation pages). --Diwas (talk) 09:16, 29 October 2014 (UTC)

Wikidata-Templates for Wikipedia

Hello,

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

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

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

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

You are absolutely right. Wikidata is made exactly for this purpose. The use of templates that get the informations out of Wikidata is possible allready and it is not so difficult to use ist. Just put {{#invoke:Wikidata|claim|P217}} to get the value of inventory number (P217) in your template or {{#invoke:Wikidata|labelOf}} to get the label of the item in your template. However you need to create all necessary properties and source them. You have to make sure that all information is stored on Wikidata prior to using it in a template.--Giftzwerg 88 (talk) 16:00, 24 October 2014 (UTC)

There is still another issue: There are still some datatypes missing. We are not able to store all kinds of datata now. This is something the programmers are still at work. Lots of properties are not created until now because, the datatypes are missing. Unfortunately I can not find the documentation to all the possibilities of templates using wikidata. There is even a discussion to centralize the templates just as commons does with files. Then it will be possible to write a template once and use it in every wikipedia without having to copy it multiple times for all the wikipedias just by placing the name of the template into the pages. Many communities still debate if they want to use Wikidata at all. There is no activity to encourage users to write templates that use Wikidata, because there are still many issues and bugs to fix. But if you want it, you can use it with some limitations.--Giftzwerg 88 (talk) 16:43, 24 October 2014 (UTC)

Thanks for your swift reply. However, it is more about what you wrote in your second reply: especially things like tournament tables or all kind of sport results mostly have just a name and a result. But if we do this work for each local wikipedia with the respective language template, then we would have to fill out the template as many times as there are wikipedia articles in the different languages. So why not get these data at one template that might be translated, but all uses the same underlying data, e.g. sports results only would have to be updated once. I know that there are discussions on many wikipedias on whether to use wikidata at all, but this question is not about how to use wikidata in templates, but how enter data into templates once for all wikipedias.

In general, I was just curious whether this was on the development map at all or not.--Mad melone (talk) 08:30, 25 October 2014 (UTC)

see 1916–17 Svenska Serien (Q2055556) for a season where I habe tried to enter all the league table info. Filceolaire (talk) 12:15, 26 October 2014 (UTC)

That's more like it, but to visualise what I want to achieve: Please see 2014 Wimbledon Championships Women's Singles Draw and more or less the same Draw used in different languages (see Q16744746 for a list of languages). Instead of filling out the results for every language, there should be a way to include them into Wikidata and then just to include a template that gets its data from Wikidata for each language. We could do this by filling in data in the same format as right now in the templates, but why not have a more visual editor like approach to it, i.e. having the template on wikidata to be filled out not in wikicode but via the wikidata GUI, best case this GUI showing the template to be filled out directly. Is this possible or could this possible within the recent scope of Wikidata?--Mad melone (talk) 13:01, 26 October 2014 (UTC)

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

I guess what the original poster is asking for is global templates? I know quite a few people are asking for it. I don't have it on my roadmap. In my opinion it is a nice idea and should be its own project probably. --LydiaPintscher (talk) 15:39, 28 October 2014 (UTC) (posting from my personal account because I am getting strange errors on my work one...)

In my original post I was referring to global templates, that's correct. Thanks for clarifying that this is not on the roadmap, I wasn't sure about that. I have an idea for an workaround and will post it once I have run it through my head once more. Further, I want to have community concensus on this.--Mad melone (talk) 16:32, 28 October 2014 (UTC)

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

Open Data Awards

Hi everyone,

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

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

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

Honoré de Balzac (Q9711)

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

to add a brother, you first need to have (or create) an item for this brother, with as much info as you can... - in any case, you should NOT add a brother (or sister) by just adding a link to a "given name" item, like you did for Laurence - to create a family link, you must use a complete item, describing the person... Name, given name, dates, who s/he is, etc...

then, when the "brother item" (Henry Balzac) is ready, you may add it with property brother (P7) :)

for the death date problem, the second one is now "deprecated", and I added a trusted source for the right one, so it is corrected :) --Hsarrazin (talk) 16:50, 28 October 2014 (UTC)

Thank you Hsarrazin! I understand a bit better how Wikidata works. I won't be able to add the informations before a while, because I don't have my reference books right now. Moreover I don't think those persons deserve an entry in Wikipedia: Laurence died when she was around 20; Henry did not do anything noteworthy. Codex (talk) 20:45, 28 October 2014 (UTC)

@Codex:: You can still make items for them at Wikidata. Just make sure that they are linked from Honoré de Balzac (Q9711). --- Jura 16:59, 29 October 2014 (UTC)

Language column

Tracked in Tracked in Bugzilla (?)
Bug 72423

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)

Your bugzilla bug does not address the issue that I brought up. Here is what I am saying. I will use Giuseppe Porta (Q3108131) as an example. This is what it looks like in English:

Language	Code	Linked page
English	enwiki	Giuseppe Porta
français	frwiki	Giuseppe Porta
italiano	itwiki	Giuseppe Porta

This is what I want it to look like in English

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

and in French

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

and in Thai

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

and in Chinese

语言	代�	链��页�
英语	enwiki	Giuseppe Porta
法语	frwiki	Giuseppe Porta
�大利语	itwiki	Giuseppe Porta

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

Ah, yes I understand now and filed a new bug for this: https://bugzilla.wikimedia.org/show_bug.cgi?id=72423 Aude (talk) 13:17, 23 October 2014 (UTC)

Thanks. 76.24.193.7 18:48, 23 October 2014 (UTC)

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

combined interwikilink list

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

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

with links:

• Bonnie and Clyde (Q219937)
  • Afrikaans afwiki Bonnie en Clyde
  • العربÙ?Ø© arwiki بونى وكلاÙ?د
  • azÉ™rbaycanca azwiki Bonni vÉ™ Klayd
  • català cawiki Bonnie i Clyde
  • Ä?eÅ¡tina cswiki Bonnie a Clyde
  • dansk dawiki Bonnie og Clyde
  • Deutsch dewiki Bonnie und Clyde
  • English enwiki Bonnie and Clyde
  • Esperanto eowiki Bonnie kaj Clyde
  • español eswiki Bonnie y Clyde
  • eesti etwiki Bonnie ja Clyde
  • euskara euwiki Bonnie eta Clyde
  • Ù?ارسی fawiki بانی Ùˆ کلاید
  • suomi fiwiki Bonnie ja Clyde
  • français frwiki Bonnie et Clyde
  • עברית hewiki בוני וקלייד
  • Bahasa Indonesia idwiki Bonnie dan Clyde
  • italiano itwiki Bonnie e Clyde
  • 日本èª? jawiki ボニーã?¨ã‚¯ãƒ©ã‚¤ãƒ‰
  • ქáƒ?რთუáƒ?ი kawiki ბáƒ?ნი დáƒ? კáƒ?áƒ?იდი
  • 한국어 kowiki 보니와 í?´ë?¼ì?´ë“œ
  • latvieÅ¡u lvwiki Bonija un Klaids
  • Nederlands nlwiki Bonnie en Clyde
  • norsk bokmÃ¥l nowiki Bonnie & Clyde
  • polski plwiki Bonnie i Clyde
  • română rowiki Bonnie È™i Clyde
  • руÑ?Ñ?кий ruwiki Бонни и Ð?лайд
  • Simple English simplewiki Bonnie and Clyde
  • slovenÄ?ina skwiki Bonnie a Clyde
  • svenska svwiki Bonnie och Clyde
  • ไทย thwiki à¸?อนนีà¹?ละไคลด์
  • Türkçe trwiki Bonnie ve Clyde
  • українÑ?ька ukwiki Бонні та Ð?лайд
  • 中文 zhwiki 邦妮和克è??å¾·
  • Commons commonswiki Bonnie and Clyde

has part

• Bonnie Parker (Q2319886)
  • Ä?eÅ¡tina cswiki Bonnie Parker
  • Deutsch dewiki Bonnie Parker
  • Nederlands nlwiki Bonnie Parker
  • norsk bokmÃ¥l nowiki Bonnie Parker
  • português ptwiki Bonnie Parker

• Clyde Barrow (Q3320282)
  • Nederlands nlwiki Clyde Barrow
  • norsk bokmÃ¥l nowiki Clyde Barrow
  • português ptwiki Clyde Barrow

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

As far as I know, there is no tool or gadget that does this. But it would be definitely worth to write such a gadget. --Pasleim (talk) 08:28, 30 October 2014 (UTC)

But it would be better, implement it directly into Mediawiki. --Diwas (talk) 12:24, 30 October 2014 (UTC)

Mediawiki (the software), or wikidata? On Wikipedia articles it is handled by using "See also". In the section below "Different article types in one Wikidata item" there is also a request for a way of linking multiple articles from wikidata, sort of like having two English language reference books about the same subject - right now many of the Ebola outbreak (or is it now an epidemic?) articles are not linked to each other, because some are about Ebola virus, some about the 2014 outbreak, some about the outbreak in specific countries. It is very frustrating trying to find out if a wiki has an article about the subject because they are in two large groups, that are not consolidated. 76.24.193.7 22:33, 30 October 2014 (UTC)

I think navigation features should be in Mediawiki (the software), a gadget would be second-best solution.--Diwas (talk) 23:34, 30 October 2014 (UTC)

JSON dump has duplicates

Tracked in Tracked in Bugzilla (?)
Bug 72678

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

It looks like another item page [4] redirects to Turi railway station (Q17100180). I don't think the redirect should be in the dump as a duplicate, so seems like a bug. But the redirect probably should be represented somewhere and in some form. Aude (talk) 07:18, 29 October 2014 (UTC)

Thanks for submitting the bug! I'll watch it. Jefft0 (talk) 16:19, 30 October 2014 (UTC)