Wikidata:Project chat/Archive/2012/12

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

Anexo: namespace

Hi everyone. I've created a lot of item about Formula One, but I've noticed that in es.wiki there are a lot of article that are in "Anexo:" namespace. After I've uploaded the interwiki, I deletel this namespace in the labe, because it's automatically uploaded with AutoEdit or slurpInterwiki gadget. An example of what I've done it's here. What I ask to you is: is it correct? Or we have to maintain it in the label? Because if we decide to remove it, we have to change AutoEdit and slurpInterwiki gadget. Restu²⁰ 14:48, 23 November 2012 (UTC)

A note: My bot implementation always removes namespace prefixes of pages titles before they are used as labels (example on User talk:MerlIwBot#name_space). But i can change it of course. Merlissimo (talk) 15:35, 23 November 2012 (UTC)

In es.wiki namespace Anexo: ('appendix') is for pages consisting in lists, tables, galleries... all that stuff that isn't really an article, as in your case that sports competition pages, nearly only tables. For the label you must, of course delete the namespace. --Rondador 22:35, 23 November 2012 (UTC)

In those cases where an article and an appendix share the same name, the description field can -and must- be used for disambiguation. Regards. --Dalton2 (talk) 23:12, 23 November 2012 (UTC)

My proposal is to deleted the "Anexo:" ns on all labels and, if there is consensus, we should modify AutoEdit and slurpInterwiki gadget so we can automatically remove it from the label. Restu²⁰ 10:47, 25 November 2012 (UTC)

Problem solved, thanks to everybody. Restu²⁰ 12:26, 30 November 2012 (UTC)

Import sources

Hello, currently administrators can import pages (MediaWiki, templates etc.) from meta. The main purpose of importing pages is so the full history of pages can be imported instead of just copying and pasting pages. Another benefit is that the tool lets the importer import templates that are used in the template (optional) since templates are usually made of other templates. I would like to propose that at least enwiki is added as an import source and other major projects (commons, dewiki, frwiki, eswiki) if possible. The reason for this is that most templates are on enwiki and other major projects, not on meta. A small discussion can be found here (search "import source" to find start of discussion) and a bug was filed here (bug 42422 (on hold until this discussion ends). Comments? -- Cheers, Riley Huntley 04:25, 25 November 2012 (UTC)

 Support I agree but I can't do anything to help. :( Raoli (talk) 04:40, 25 November 2012 (UTC)\

 Support Of course, sounds incredibly helpful. —Theopolisme 04:59, 25 November 2012 (UTC)

 Support A needed feature, at least for en.wiki and commons. Regards, — Moe Epsilon 05:15, 25 November 2012 (UTC)

 Support On the belief/presumption that "All structured data from the main and property namespace is available under the Creative Commons CC0 License; text in the other namespaces is available under the Creative Commons Attribution/Share-Alike License; additional terms may apply. See Terms of use for details." covers this. —WFC— 06:04, 25 November 2012 (UTC)

 Support --Stryn (talk) 07:13, 25 November 2012 (UTC) edit: but just templates what we really need. --Stryn (talk) 16:43, 27 November 2012 (UTC)

 Support We are not going to need a lot of templates though. Templates for discussion and userpages would be enough.--Snaevar (talk) 11:02, 25 November 2012 (UTC)

Templates for discussions and userpages already exist. What templates should exactly be imported? --Bene* (talk) 16:06, 25 November 2012 (UTC)

Wondering if {{Convert}} needed....If yes, then that will be a big problem for translation.....J^C1 16:18, 25 November 2012 (UTC)

If we need templates like Template:Convert, then it would be smarter to use Lua templates instead - test2wiki:Module:Convert or test2wiki:Module:Convertdata. The ETA for deployment of Lua support is in January - March 2013 anyway.--Snaevar (talk) 17:27, 25 November 2012 (UTC)

Well, it's great. By the way, when export is enabled, what should users expect, m/s, km/s or ft/s?....I think convert system will be needed on that time, as let them choose themselves.

As we may need a new one-way convert system that only show one result.J^C1 10:17, 26 November 2012 (UTC)

Honestly, I'd prefer to make our own templates rather than import ones from enwiki. Our templates should ideally be multilingual (perhaps based on the viewing language of a user?), and enwiki templates are not that. Let's get original and make our own: I'd be glad to help :-) Ajraddatz (Talk) 23:01, 26 November 2012 (UTC)

 Oppose per Ajraddatz. --Dalton2 (talk) 01:32, 27 November 2012 (UTC)

 Support - Ajraddatz, the nice thing about wikis is that even if we don't initially use our own, we can always tailor templates to suite our needs. Some templates probably don't need that treatment.--Jasper Deng (talk) 05:26, 27 November 2012 (UTC)

Tailoring an enwiki template to suit our needs is really not what I'd like to see either. Wikidata has the amazing potential to be multilingual - more so than other projects. We shouldn't ruin that good start by basing everything off of enwiki, which contains much bureaucracy and "templacy"? that I don't feel is needed here. Ajraddatz (Talk) 17:24, 27 November 2012 (UTC)

There is no difference between that and creating our own templates. In addition, we don't need to use enwiki templates forever.--Jasper Deng (talk) 18:09, 27 November 2012 (UTC)

 Oppose I think this is really not needed because we have so many templates as well. If one is needed, wie can import it, but I think it would be better if wikidata would have it's "own style". --Bene* (talk) 16:40, 27 November 2012 (UTC)

Enwiki was allready added as an import source 2 days ago and the bug Riley mentioned has been fixed.--Snaevar (talk) 16:48, 27 November 2012 (UTC)

There are other things that we might want from enwiki, but I'd say that more discussion is required before we start importing enwiki templates. Just because one aspect of the discussion ended doesn't mean that the discussion must finish, or that we can't revisit it. Ajraddatz (Talk) 17:23, 27 November 2012 (UTC)

• Closing - While there is some concern with using our own templates over enwikis, the discussion has ended and enwiki was added as an import source. If this is an issue still, more specific discussion can resume at a later time. Ajraddatz (Talk) 15:17, 2 December 2012 (UTC)

English variants

How do we plan to deal with variants of the English language (American English, British English, Australian English, etc.) for labels and descriptions? Since this is something that deals primarily with the English Wikipedia (right now), should we just follow the agreed upon variant there and adjust our labels and descriptions accordingly (and add other variants as aliases)? Regards, — Moe Epsilon 04:18, 22 November 2012 (UTC)

At least for now, I think that works fine. However, the enwiki "language variant policy" is rather open — I definitely don't think that whatever one article on some random website uses should be at all definitive: see this MOS page for the convoluted-ness of it all. As I said, though, I suppose just going with the spelling there is the easiest method ... for now. :) Plus, aliases are cheap. Theopolisme (talk) 04:30, 22 November 2012 (UTC)

Yeah, that's what I was thinking. Sorry for making changes over you at the Kerosene page, we should probably avoid American/British English variant words if possible to avoid a conflict. :) Regards, — Moe Epsilon 04:42, 22 November 2012 (UTC)

Currently, 'en-gb' is treated as a language in its own right. This means that if you change your language to 'en-gb', you will edit labels and descriptions in 'en-gb', not in 'en'. I do not like it at all. 'en-gb' makes sense only if British users use it, but if British users use it, there will be a big loss of human resources in the main 'en' version. We should have better solutions, like perhaps dropping 'en-gb' as a separate language and adding the possibility to marksomen aliases as 'en-gb' (that ideally could be used as the label for British users). --Zolo (talk) 07:36, 22 November 2012 (UTC)

I didn't even know this until I searched through language settings and saw British English in there. It does seem silly that it is its own language considering every other variant it would seem falls under just "English". Not only is this a detriment to the en version, but to all of the British English speaking folks who can't see clearly English labels, aliases, etc. Regards, — Moe Epsilon 07:58, 22 November 2012 (UTC)

'English' labels should become more visibe to Brish English users, once the fallback mechanism is operational (I do not know if the opposite will be true as well). --Zolo (talk) 08:15, 22 November 2012 (UTC)

I agree, they have to be open to users who also have 'Simple English' set as well, since that is another variant listed with its own labels. Regards, — Moe Epsilon 08:17, 22 November 2012 (UTC)

I meant Wikidata developers plan to do it this way: when the user's language is not available, the description will default to another language that the user is likely to understand, and in the case of British users, it will be normal English. It makes sense, but even then, I would prefer not to have "en-gb" as a fully separate language. The case of "simple" is somewhat different as it has its own Wikipedia (but I admit I am not fully clear as to how a database can be converted from nomal English to simple English without any loss of content)--Zolo (talk) 08:28, 22 November 2012 (UTC)

Oh, there's already a plan for a fallback? Is it at Bugzilla where we can track the process of it being implemented? Regards, — Moe Epsilon 08:32, 22 November 2012 (UTC)

It seems to be 36430--Zolo (talk) 08:41, 22 November 2012 (UTC)

See also Wikidata:Project chat#Fallback languages. Jeblad (talk) 14:16, 22 November 2012 (UTC)

Fallback would obviously help, and will undoubtedly come sooner or later.

But for as long as the default variant is entitled "English", there will not be a complete subset of American English titles – while not something I personally would lose sleep over, that seems strange for a site with at least a plurality of American English speakers. Perhaps we should retitle "English" as "American English"? As a Brit I'm sure I could live with the relatively technical issue of American English being en but British being en-gb, and the now-common internet practise of American English being the default variant (with the rest of us having the option to switch should we choose to do so). This idea would however require two-way fallback. —WFC— 12:34, 23 November 2012 (UTC)

It is not obvious how the fallback languages should work. Right now we only use the fallback defined in the Message objects, but I think we need something more fancy than the simple "oh no, it fails, use English". There are groups of similar languages that can be used as fallbacks for each other (within the same small group like en-gb and en-ca), there are languages we may expect users to know due to their living area (geoip), and there are languages the user may specify that he knows (Babel). If the user says he knows a specific language we may also infer that he knows another similar language. For example if I say I know nb (Norwegian bokmål) it is safe to assume that I also can read sv (Swedish) but it is not safe to assume I can read is (Icelandic). In short I think we need something more fancy than now, perhaps a weighted similarity of some kind. It is also worth noting that this is about reading in another language, which is definitely not the same as writing in those languages. Jeblad (talk) 15:36, 23 November 2012 (UTC)

Fallback handling is not always easy because of inacceptance by the community. E.g. we had along discussion about lezwiki. All living people speaking Lezgian are also able to read Russian because they are forced by government at school and at government agency. But that's also the reason why we had a long discussion until ru was accepted as fallback. Merlissimo (talk) 16:07, 23 November 2012 (UTC)

That would be akin to making English a fallback language for Welsh, and I'm 100% certain that nobody here is proposing that. This one is simply a matter of practicality. Far better to manually add u's and change z's to s's in 2–3% of cases where the Americans have got it "wrong" from a British perspective, than to manually have to copy and paste for the 97–98% of labels that are fine in both variants. —WFC— 11:11, 2 December 2012 (UTC)

In Mediawiki English is first fall back language of Welsh. Merlissimo (talk) 11:31, 2 December 2012 (UTC).

Seriously!?! —WFC— 12:35, 2 December 2012 (UTC)

[1]. en is always last fallback language. Merlissimo (talk) 13:37, 2 December 2012 (UTC)

The reason that there are currently three English languages - English, Canadian English (en-ca) and British English (en-gb) is because these languages have different spellings for certain words. For example, center in -ca or -gb is centre, honor is honour, organization is the same for -ca but organisation in -gb... etc. While it's almost silly to have different language settings for this, there does need to be a fallback to regular en. [[User:Ajraddatz|Ajraddatz]] <small>([[User Talk:Ajraddatz|Talk]])</small> (talk) 15:33, 24 November 2012 (UTC)

What is English?. Apologies for the bolding, but my first comment was largely ignored.

Your post makes the assumption that "English" is near-universally understood as meaning "American English". In my experience this is not the case, on either Wikidata or the English Wikipedia. Few would object to American English being our fallback language, or indeed assuming the "en" language code in the interests of technical simplicity. But for as long as we have one variant simply labelled as English, that variant will almost certainly be treated in line with en.wikipedia policy on language variants. If "English" is intended to mean "American English", we should rename it accordingly. —WFC— 05:59, 25 November 2012 (UTC)

I agree with WFC on this point. If there are to be different English varients, it seems "English" is being treated as "American English", the most used varient. But even so it should be renamed thus if that is the case so as to avoid confusion. Del_♉sion23 (talk) 23:56, 25 November 2012 (UTC)

As a native speaker of US English, and a veteran of several discussions in English Wikipedia, I am surprised to see US English as "Normal English." rather than labeled as one variant. It could be so labeled and still be a default. Discussions about what version a given article should use have shown that there are more native born US English speakers than there are of the Brit, Canadian or other variants, but there are also a large number of less fluent speakers in countries such as India, who may be familiar with Brit spellings. Overall this project looks like a wonderful development, and I thank those who have worked on it. Edison (talk) 16:12, 28 November 2012 (UTC)

Wasting time on adding descriptions

So, we have 2000+ pages about years, (2000 * 250+ languages =) 500,000+ descriptions, and for each language, all of the descriptions are the same. Same thing happens with places, structures, etc. If we define a "pointer" in the software, with which these sort of pages will point to another page which contains the corresponding descriptions in all languages (the word "year" in different languages, in this case), it would be far easier to create, maintain, and edit data.

I don't know if we will have such feature in the future (it has some disadvantages, too). Anyhow, I think users should not put their time and energy on these sort of pages, the system is still imperfect and may change a lot. --Z 14:37, 29 November 2012 (UTC)

Sounds like a wise idea. I  Support—with that caveat of as long as there is not some sort of "coming-soon" plan that encompasses this, of course. :) —Theopolisme 21:12, 29 November 2012 (UTC)

Yes, I think this would be an extremely useful feature. Things like "city in Florida, United States" will be duplicated an enormous amount of times. It would be better to have the software do it automatically. --Yair rand (talk) 17:01, 2 December 2012 (UTC)

Initial articles (a, an, the) in English language descriptions

So I was overhauling the Help:Description and Help:Label, and the only point that has come up that there isn't a clear consensus on is initial articles (a, an, the) in the descriptions. There's a previous discussion at Wikidata:Project chat/Archive/2012/11#Placing articles at the beginning of descriptions, however it only has three people weighing in, which isn't very many for a consensus.

My personal feeling is that initial articles is a personal stylistic choice, and I'm for allowing either version. I certainly am against going through with a bot and just removing all of them, it seems like a waste of a 50,000 edits. That being said, I'll go with whatever is decided here; I'd just very much like to get a half dozen or more voices on it. This is also Sven Manguard 16:13, 29 November 2012 (UTC)

Comments

• I support allowing either version, but if we had to choose, I support using initial articles. This is also Sven Manguard 16:13, 29 November 2012 (UTC)
  • Pulling my support for initial articles, I'm now in favor of getting rid of them. This is also Sven Manguard 19:21, 29 November 2012 (UTC)
• I'm also for allowing either version. I hope we won't have to choose. Lukas²³ ^talk in German ^Contribs 16:15, 29 November 2012 (UTC)
• No initial articles and no choice. There is no problem with a few thousand bot edits. --Leyo 16:24, 29 November 2012 (UTC)

  I'm not trying to be antagonistic, I really am curious about this, but why no initial articles? This is also Sven Manguard 16:30, 29 November 2012 (UTC)

  We should strive to keep the descriptions concise. An initial article does not add any informative value to a description. --Leyo 09:12, 30 November 2012 (UTC)

• I'm for either version. Let us not make another rigid policy that stifles progress out of this one.--Lam-ang (talk) 16:46, 29 November 2012 (UTC)
• Any uses of the descriptions surrounded by text content require consistency, and the easiest to use would be no articles, I think. To reuse the example I gave in the original discussion, if one wanted a program to use a text response of something like "Did you mean the [description1], the [description2], or the [description3]?", that would be impossible, or at least very difficult, if there were articles at the beginning. --Yair rand (talk) 16:48, 29 November 2012 (UTC)
  • No it wouldn't. "There are three results for 'Michael Jackson', [an English author], [an American pop musician], and [an American Jazz musician]." It even works with mixed results. "We have two results for 'Lord of the Flies', [novel] and [a movie based on the novel of the same name]". This is also Sven Manguard 17:01, 29 November 2012 (UTC)
• If there are technical reasons like Yair rand's I am against initial articles. Otherwise I think there should be a consensus, but I do not prefer to allow both oppertunities. Let's make a vote --Bene* (talk) 16:58, 29 November 2012 (UTC)
• I have no strong opinion, but definitely agree we need two choose one soluton. One reason why I would mildly prefer no article, is that is can be implemented in all languages I am acquainted with, while adding an article would sound really awkward in French. --Zolo (talk) 17:27, 29 November 2012 (UTC)
• I think consistency is a must with regards to the machine-readability of articles so one should be chosen as a standard and adheared to. I'm leaning towards no initial articles for simplicity, but wouldn't mind which way in the end so long as one is chosen. Del_♉sion23 (talk) 18:40, 29 November 2012 (UTC)
• I am going to answer this similarly to Zolo's comment. I don't have an strong opinion, but I would prefer no article. It can be implemented in all languages I am acquainted with. I have an different opinion on articles in labels, but we are not discussing that here.--Snaevar (talk) 18:41, 29 November 2012 (UTC)
• This is another example of how English idiosyncrasy is different. I'd like to remark that this is about English, exclusively. This rule, in case it will be adopted, won't be aplicable for other languages. But I'm afraid we've got a problem here: English is the default language by tacit consensus, most discussions are taken in the Project chat, and not in the different talk rooms, and even the system is organized around English. But, on the other hand, some (American) people are using English to establish rules with a local scope, and not the international scope that would be expected, so there can me some misunderstanding by some people from other countries. We should be careful about this to prevent problems in the future. Wikipedia was started in the USA, and that's one of the reasons why the English Wikipedia has privilege over the rest (for example, it's the only language with several WMF chapters and the one that holds the central chapter), but Wikidata is different. It was started as a multilingual project, and it should be multilingual in every aspect. --Dalton2 (talk) 18:52, 29 November 2012 (UTC)
  • But this is a matter which should be decided on a local basis. Surely it should be for users of individual languages to determine the appropriate linguistic policies and guidelines? Of course, policies which would affect all languages, such as blocking, protection, deletion and (permanent) admin policies, would require a multilingual consensus. —WFC— 08:20, 2 December 2012 (UTC)
• For consistency in a multilingual aspect, no articles should start a description. Regards, — Moe Epsilon 19:12, 29 November 2012 (UTC)
• Like Zolo and Snaevar; I don't have an strong opinion, but I would prefer no article. When we reached a consensus, I would not leave the choice to the user. --Beta16 (talk) 09:02, 30 November 2012 (UTC)
•  Support No initial article. Raoli (talk) 12:25, 30 November 2012 (UTC)
• No initial article. If we aren't using complete sentences, there is no need to have a or an in front of the description. Ajraddatz (Talk) 13:20, 30 November 2012 (UTC)
• I think initial articles should be allowed for English descriptions. They give information about the definiteness of the subject. Beginning a brief description with an article is also conventional in English dictionary definitions, which English Wikidata descriptions closely resemble (e.g. [2][3][4][5]). Emw (talk) 20:26, 1 January 2013 (UTC)

Title of the sitelinks and normalization

Title is in the column "Linked article"

In the sitelinks there is a title, and that title will be normalized when the sitelink is saved. That seems to create confusion, because users write something in the title field and then the text changes when they hit save. The reason for this is that there must be only one canonical form of the sitelink in use, that is a specific combination of site id and title, and the normalization to make them canonical happens when the users save the sitelink.

To make this guarantee possible we convert the title to what is called the canonical form and stores that as the title. That means we do a Unicode normal form C conversion, we strip some blank characters (and also some other characters), we do a language-specific (script) conversion, we follow any redirect (not double ones) and the title of the final page is then returned. That title is usually with a upper case (capital) first letter. We do not try to reuse any set display title on the Wikipedia-page, and we follow redirects no matter how it is defined.

For example will the music group known as dEUS in glwiki (Galician Wikipedia) be written as DEUS after it is normalized to canonical form. An other more radical example involves script conversion, like in Belgrade where you can write Beograd in srwiki (Serbian Wikipedia) and it will be converted during the normalization to Београд as the canonical form. (Why do this change in italics? Београд/Београд) A third form is when the normalization involves a redirect, like in Oslo where you can write Kristiania (an old name) in enwiki (English Wikipedia) and it will be normalized to Oslo as the canonical form.

Hope this explain a little about whats going on during normalization of the sitelinks, and why it happen. Jeblad (talk) 17:16, 30 November 2012 (UTC)

For script conversion, maybe it would be better to just display both versions, instead of getting rid of one? --Yair rand (talk) 17:09, 2 December 2012 (UTC)

Also, why does it follow redirects? --Yair rand (talk) 17:09, 2 December 2012 (UTC)

Rules for managing an item

If we want to use Wikidata for infoboxes we need imho three basic rules for managing an item:

1. An item should not be recycled. (Old items, that are not used any more, should be deleted or turned into a redirect.)
   1. See also: Wikidata:Project chat/Archive/2012/11#Recycle pages instead of deleting
2. If items are merged, the one that is not used any more should be turned into a redirect.
3. Items should not be updated. (If, for example, there is an item "2nd edition of xy" and a 3rd edition is published, the 3rd edition will get a new item id.)

--Kolja21 (talk) 23:13, 30 November 2012 (UTC)

Agree with all of the rules above. Additionally, we will need a temporary rule while merging items does not work. That temporary rule would be:

• If there are duplicate items, then move the interwiki links to the other item and then delete the empty item.--Snaevar (talk) 00:55, 2 December 2012 (UTC)

• If there are duplicate items, then move the interwiki links to the other item and then turn the item that is empty into a redirect. --Kolja21 (talk) 08:01, 2 December 2012 (UTC)
• Well, we don´t have any method of turning an item into a redirect yet. When we do have the feature to merge items that will be the only case where an item becomes an redirect.--Snaevar (talk) 10:35, 2 December 2012 (UTC)

Whose bot is editing logged out?

I've just soft-blocked the Toolserver range 91.198.174.0/24 for a day, because it seems that someone's interwiki bot is editing while logged out. If I remember correctly Toolserver bots must log in to edit.--Jasper Deng (talk) 05:09, 2 December 2012 (UTC)

Thx. To prevent this i test if token  != +\ , but this seems not to work for wikidata. I added another test. Toolserver range can be blocked for anon only forever. I'll add infinite blocks for 91.198.174.192/27 and 2620:0:862:101:0:0:0:0/96. Merlissimo (talk) 10:10, 2 December 2012 (UTC)

A page for all notification to admins

Hi everyone, I think we have to create a page, like Wikidata:Administrators' noticeboard (or something similar), so users can notify to admins all the requets that needed sysop action (like block an IP that make vandalism, revdelete copyviol, etc.). What do you think about a page like this? Restu²⁰ 11:10, 2 December 2012 (UTC)

I've started it. Let's hope that it remains inactive for a long time: that will hopefully mean that everything is running smoothly :) —WFC— 11:23, 2 December 2012 (UTC)

I hope it so. :-) Restu²⁰ 11:25, 2 December 2012 (UTC)

Bot auto updating description: disambiguation

Discussion taking place here. Del_♉sion23 (talk) 14:37, 2 December 2012 (UTC)

Consensus and translation of policy pages

I would propose that all policy pages should have a project-wide consensus and be translated to all languages. I also propose that we use English as the base language for all policy pages, so all translations use this language as source. If there are any dispute on correct interpretation the English version is used. That does not mean that English-speaking users can dictate other languages, nor that English in any way has a higher rank than any other language, it is only to make a framework where we can build a common understanding of overall rules. That do although mean that all pages should note that there are other languages and that a language related rule in one language might not apply in another language. A draft of a policy might very well be written in another language than English, but to be a policy and not merely a language-specific guideline it must be translated into English and a project-wide consensus must be achieved.

Feel free to translate this to any other languages as seems fit. Jeblad (talk) 15:47, 2 December 2012 (UTC)

Perhaps the best way to accomplish this would be through requests for comment for each of the major policies (especially the ones which aren't going on atm)? And advertising those discussions via sitenotice? Ajraddatz (Talk) 15:55, 2 December 2012 (UTC)

I think a sitenotice isn't inherently a bad idea--or at least a watchlist-notice, perhaps. —Theopolisme 19:53, 2 December 2012 (UTC)

I don't know... A lot of policies are really language-specific, and we don't really have any way of having multi-language discussions, yet, even though we really should. --Yair rand (talk) 20:35, 2 December 2012 (UTC)

How do you think this could be accomplished? —Theopolisme 23:41, 2 December 2012 (UTC)

Turn it around, would it be possible to govern one single project with 300+ different diverging policy pages about the same thing? One thing in one project should be described on one page, and that page should be translated into the different languages. 89.204.155.9 00:45, 3 December 2012 (UTC)

There are two different types of policy/guideline. Some are language specific (such as those relating to labels and descriptions), whereas others are global (blocking and protection policy for instance). It stands to reason that there will be different approaches to each type. —WFC— 07:35, 3 December 2012 (UTC)

Well, we'd have to have a lot of manual translating. There would need to be a simple way to translate individual comments in a discussion. Having more templates like {{Support}} which automatically display correctly in many languages and have redirects from many translations would also help. --Yair rand (talk) 14:27, 3 December 2012 (UTC)

Rename Category:Task force

...to Category:Task forces. The current title is grammatically incorrect. It also just looks wrong to me. -happy5214 15:43, 3 December 2012 (UTC)

•  Support The plural is the correct name grammatically. Del_♉sion23 (talk) 16:01, 3 December 2012 (UTC)
• I would prefer that we create a new namespace for task forces only and let the category have the same name as namespace. Merlissimo (talk) 16:12, 3 December 2012 (UTC)
• Not sure if it is worth the trouble of fixing the links just to add an s. A namespace might be nice, even though these are meant to be temporary (or originally were). Ajraddatz (Talk) 16:25, 3 December 2012 (UTC)

  Why temporary? Wikidata:Countries task force is added to completed task force, but e.g. population must be updated at least once a year and this should be organised by a task force i think. Merlissimo (talk) 16:43, 3 December 2012 (UTC)

   Support to own Namespace --Sk!d (talk) 18:07, 3 December 2012 (UTC)

Allow admins to assign translation admin to themselves

There already exists consensus that admins don't need to go to WD:RFP to obtain translation admin status. However, on the technical level the request must still be fulfilled by stewards. Thus I propose that admins have the technical ability to add (and/or remove) translation administrator to/from themselves only, not other users.--Jasper Deng (talk) 04:00, 25 November 2012 (UTC)

 Support I don't see any problems with it as a concept—just saving a step; however, is there some sort of technical barrier preventing this from happening? Or can a switch just be flipped? —Theopolisme 04:20, 25 November 2012 (UTC)

No, there isn't a technical barrier, just need to set $wgGroupsAddToSelf for that.  Hazard-SJ  ✈  04:21, 25 November 2012 (UTC)

Thanks for clarifying. —Theopolisme 04:22, 25 November 2012 (UTC)

You're welcome.  Hazard-SJ  ✈  04:23, 25 November 2012 (UTC)

I wonder if it would be better to leave that to bureaucrats, as people often overrate their own abilities in other languages. Jeblad (talk) 05:18, 25 November 2012 (UTC)

True. But, we already established consensus that admins can get translation adminship without a separate request for permissions. Admins are trusted, in my opinion, to avoid situations where they are uncertain of what to do.--Jasper Deng (talk) 05:28, 25 November 2012 (UTC)

We also don't have any local 'crats, and the current sentiment is against appointing any. Sven Manguard Wha? 05:35, 25 November 2012 (UTC)

 Support Will save time for those who would make use of the permission, and help us to more easily identify those who see such tools as extra badges. —WFC— 05:39, 25 November 2012 (UTC)

• I don't know if we want to make the broad characterization of badge collecting without proper evidence of that. If they grant themselves the tool but doesn't use it for the first month, it wouldn't be badge collecting. Regards, — Moe Epsilon 10:52, 25 November 2012 (UTC)

• I agree with Moe Epsilon. That most of the admins, myself included, made a mad rush for the mop at the earliest days of the project, is I think something that could be looked to as more worrying. I have a feeling that the number of admins is going to take a drop comes reconfirmation because some of them simply didn't stick around, however other than that, I've yet to see anything worrysome among the admin corps. Sven Manguard Wha? 15:50, 25 November 2012 (UTC)

• The mad dash isn't too worrying for me, on the basis that we decided early on that all initial admins would require reconfirmation. The extent to which it was a popularity contest was somewhat distasteful, but more worrying is even the remote possibility that we might reconfirm admins before fully defining the role. Back to my initial comment, in the course of a relevant discussion about a user (such as RfA, RfB or RfC) I have the right to make the point that an individual user is badge collecting, just as others would have the right to agree with my arguments, refute them, or dismiss them as irrelevant. —WFC— 00:14, 30 November 2012 (UTC)

• I am in principle fine with this suggestion, but I would like to wait until the reconfirmation wave.--Ymblanter (talk) 18:56, 25 November 2012 (UTC)
• Letting admins add themselves would be silly - if anything, add the rights in the translationadmin group to the sysop group. I like the current way we have it because it forces an admin to give some conscious thought before being added to the group, but that's not too big of a concern. But strong oppose keeping two different groups so that flag collectors can just add themselves to translationadmin without using it. Ajraddatz (Talk) 23:05, 26 November 2012 (UTC)
  • In the case of that, we don't have to reconfirm their adminship.--Jasper Deng (talk) 05:25, 27 November 2012 (UTC)
    • Um, what? Ajraddatz (Talk) 00:20, 30 November 2012 (UTC)
      • Any admins who ask for the bit w/o actually using it don't need to have their temporary adminship made permanent.--Jasper Deng (talk) 01:27, 30 November 2012 (UTC)
        • Oh, of course, sorry for misreading that. I really like the concept of temporary admins... maybe all of the admins here should go through a three-month temporary period... But that's a discussion for another day ;) Ajraddatz (Talk) 01:37, 30 November 2012 (UTC)
• Support. That's how it is in Meta. Jeblad commented that "people often overrate their own abilities in other languages", but actually translation itself is open to everybody, and it's fine, because we have a wiki here. "Translation admin" has little to do with translation itself - this permission is mostly for marking new pages for translation and for republishing translatable pages that were updated. Documentation pages are quickly being written, and it would be a good idea to mark many of them for translation, and for that you need a few translation admins. --Amir E. Aharoni (talk) 00:04, 5 December 2012 (UTC)
•  Support  Hazard-SJ  ✈  00:12, 5 December 2012 (UTC)

Label language problem for uz

Tracked in Bugzilla
Bug 42397

Tracked in Bugzilla
Bug 42420

Currently my bot cannot import items that include a uzwiki sitelink. That's because it automatically adds label using variant language codes uz-latn and uz-cyrl and not uz. For all wikis having variants enabled these labels are accepted expect uz-latn and uz-cyrl. I reported it at bugzilla:42397.

The problem is that my bot tries to import items having many sitelinks first. That is why my bot hit thiscase so often.

Because i think it will take some more time until this bug is fixed i am asking you what my bot should do with these items for the moment:

• not importing the complete item (current status)
• leaving uz/uz-latn/uz-cyrl label blank
• adding uz-latn string as uz label and do not add uz-latn/uz-cyrl

Example of the current implementation for adding uzwiki:

• uzwiki sitelink: uz:Steve Wozniak
• uz-latn label: Steve Wozniak
• uz-cyrl label: Стеве Wозниак

Only my bot adds variants for all languages and Choboty for zh-hans/zh-hant only. All gadgets are only adding labels in uz. Merlissimo (talk) 13:45, 26 November 2012 (UTC)

I don't have enough knowledge to make an informed comment, but am responding because I think it's important to keep this discussion going.

Does the Uzbek wiki exclusively use latin script (from what I've seen it does)? The impression I get from reading about the language on the English Wikipedia is that cyrillic script is being phased out – is this an accurate impression? Would preference for latin script over cyrillic be considered controversial? The answers to those questions would help determine whether to stick with the status quo or go with the third option. —WFC— 20:11, 28 November 2012 (UTC)

Government decided on 1995 to change the used alphabet from Cyrillic to latin. Since 2005 all official documents are in latin only. Many books are still written in Cyrillic and many people never have learned to use latin at school. That's why i think it would make sense to have the possibility for searching items using the cyrillic alphabet. The easiest solution would be if bugzilla:42397 can be solved soon. Perhaps you may vote on this bug to rise importance. Merlissimo (talk) 11:38, 29 November 2012 (UTC)

As there is not response i decided on my own to set uz-latn as uz label and add uz-cyrl as uz alias. Merlissimo (talk) 14:23, 4 December 2012 (UTC)

{{Chat/Header}}

Hello, does anyone mind if I move {{Chat/Header}} to {{Chat header}} and put __NEWSECTIONLINK__ on it?  Hazard-SJ  ✈  23:42, 4 December 2012 (UTC)

Makes perfect sense. Go for it. —Theopolisme 23:45, 4 December 2012 (UTC)

Yes Lukas²³ ^talk in German ^Contribs 23:46, 4 December 2012 (UTC)

Go for it. Ajraddatz (Talk) 00:19, 5 December 2012 (UTC)

 Done  Hazard-SJ  ✈  01:41, 5 December 2012 (UTC)

Possible violation?

Just a silly question: Wikipedia is using CC-BY-SA, including the interwiki links, as it is a kind of text, while we are transfering it to Wikidata, which is using CC-0 for data, including the interwiki links. Has this action violated the CC-BY-SA?--J^C1 12:26, 4 December 2012 (UTC)

No. Raw data points, including interwiki links, are not copyrightable. If we start taking large chunks of actual prose, we'd have an issue. We have no intention of doing that, however, so we're fine. This is also Sven Manguard 19:45, 4 December 2012 (UTC)

I agree with Sven. Stating the article's name lacks originality, and therefore has no copyright status. OhanaUnited^{Talk page} 21:54, 4 December 2012 (UTC)

I've noticed that description-wise, many seem to be pulled directly from enwiki (or whichever language)--simply to further clarify, is this at all a problem? —Theopolisme 22:54, 4 December 2012 (UTC)

Ideally, the lead from Wikipedia should not be used. It's often tempting, though, to copy the succinct description in a well-written lead, particularly in an item where the concept is hard to define in your own words. I don't think it is too much of a problem now unless entire sentances are Crtl V+C'd into the description (which I have seen on a few items). Users who are doing this should probably be politely informed that they should not copy leads. Del_♉sion23 (talk) 01:53, 5 December 2012 (UTC)

Thank you for your explanation.--J^C1 11:14, 5 December 2012 (UTC)

Q340969

I came across Q340969 recently, add seeing it had no English name or article, I went looking. I think Lazarette is the equivalent term after using Google Translate, but I want to check with someone who knows one of the other languages and more about boats than I. If there is a better forum, let me know. Chris857 (talk) 18:44, 4 December 2012 (UTC)

Google translate is usually correct, and that looks like the equivalent. (Though, I don't speak those languages, so I'm not completely sure either.) Ajraddatz (Talk) 16:13, 5 December 2012 (UTC)

next office hours

Hey :)

I just set the date for the next Wikidata office hour on IRC. Denny and I will be there to answer questions and discuss. More details here.

Cheers Lydia Pintscher (WMDE) (talk) 13:50, 5 December 2012 (UTC)

Nice, I will be there :) --Stryn (talk) 14:06, 5 December 2012 (UTC)

Prioritizing Hungarian articles

Since the Hungarian Wikipedia is going to be the first host of Wikidata interlanguage links, would it make sense for us to prioritize entering articles that exist at hu.wiki (there are only 229,000)? Kaldari (talk) 01:28, 30 November 2012 (UTC)

You could make a task force of items at the hu.wiki which haven't been done yet. If you do, I can help out with starting items. Regards, — Moe Epsilon 01:36, 30 November 2012 (UTC)

Would it be possible to create a category for hu.wiki pages without a Wikidata entry? —WFC— 02:12, 30 November 2012 (UTC)

The way we find pages without interwikis on en.wiki is en:Special:WithoutInterwiki. I guess we could always bugzilla a request for a feature to find pages without a wikidata entry globally (or maybe just for hu.wiki). Regards, — Moe Epsilon 02:33, 30 November 2012 (UTC)

My bot is not prefering huwiki import because replication on s7 toolserver database stopped 20 days ago. My bot uses toolserver query to detect missing articles for import. If s7 is available again and wikidatawiki_p is also replicated to s7 (currently only s1,s2/5,s3 and s4) then there would be no need for such a category. Instead please ask WMF (create database dump) and WMDE (solve technical problems) to set setup up s7 again. I asked several times in the last weeks without any positive reaction.

After my bot completed automatic import of wikis i can create report containing pages that must be imported manually because of e.g. conflict. Several minor wikis are already completed by my bot. Merlissimo (talk) 02:37, 30 November 2012 (UTC)

There is a bug for a special page; Bug 38603 – Special page for pages without connected items. Jeblad (talk) 02:42, 30 November 2012 (UTC)

My bot i currently running on dewikipedia to start on pages there. But I could change it to start on huwikipedia, if this is wanted. --Sk!d (talk) 06:39, 30 November 2012 (UTC)

I think that is a good idea. Conny (talk) 20:45, 30 November 2012 (UTC).

I will start a second botthread in a few days which than will be operate on hu wiki (so e.g. wikipages without a interwikilinks will also be imported). --Sk!d (talk) 01:53, 1 December 2012 (UTC)

hu:Special:WithoutInterwiki lists only the first 5000 articles without interwikis. Is there a way to circumvent this? Syp (talk) 12:24, 30 November 2012 (UTC)

A better special page should have some kind of paging. Also note that in the future no page in Wikipedia will be without a sitelink unless some special measure is taken, or there are no item in Wikidata for the entry. Jeblad (talk) 12:29, 30 November 2012 (UTC)

Be careful, articles without interwiki do not mean they really don't have corresponding articles in other wiki. It means only that they are not added for any reason. --Zanka (talk) 13:19, 30 November 2012 (UTC)

What would happen after Wikidata is turned on for huwiki? Should we not take out old-style interwiki links from the huwiki articles and teach the iw-robots to ignore huwiki, as maintaining interwiki in two places would be redundant? Syp (talk) 16:09, 30 November 2012 (UTC)

I don't know if its possible to run pwb interwiki bots. But my java interwiki bot MerlIwBot is compatible with wikidata client extension. It can work on pages having local and wikidata langlinks at the same time. If possible langlinks are moved to repository. My only problem that working on such pages needs much read requests. That's why i hope that bugzilla:41345 will be available before client extension goes live. Merlissimo (talk) 16:25, 30 November 2012 (UTC)

Huwiki pages without a Wikidata entry <> Huwiki pages without interwikis.

I can create any kind of listings of pages in huwiki with my bot if this helps but unfortunately my bot does not handle main namespace in Wikidata as it is waiting for API being updated in an undefined near future. Bot will process the latest huwiki dump within a few hours and the live wiki in 1-2 days. What is the task? :-) Bináris (talk) 20:35, 30 November 2012 (UTC)

Prioritizing articles on hu.wiki would make sence.

@Syp: I am expecting that the same thing will happen as Merlissimo does. That means that interwiki links with interwiki conflicts will remain on wikipedia (and probably also interwiki links that link to an section too). Other interwiki links would be moved to Wikidata and updated there. So, bot´s wont really ignore the wikipedias compleatly, but we would get rid of the automatic interwiki bots.

Pywikipedia does not work on items, but it works in other namespaces. Currently we have one pwb bot and that is Hazard-Bot. Xqt and Amir Ladsgroup are working on making pwb compatible with wikidata.

@Bináris: The task is to create a list of huwiki pages without a Wikidata entry and save it to Wikidata:Hungarian wiki task force.--Snaevar (talk) 00:45, 2 December 2012 (UTC)

My bot is now importing hu-links as a part-time job. --Sk!d (talk) 11:15, 6 December 2012 (UTC)

Deployment schedule

If everything goes well, we will deploy a new version of the Wikibase extension today to Wikidata, probably around 7-9pm UTC (i.e. in the next few hours). Things might go wrong, deployment might stall, or we might need to retract. The API will change quite a bit (you can see the new API on the test repository) and also there are a few fixes and new features (List of pages without a label, yay!) that will be rolled out. The API will very likely break the bots, but should be quite stable then (no promises, though). No Phase 2 features will be rolled out yet (we removed them from deployment code). We would love to get feedback and bug reports. A lot of code has changed in the backend to enable the data propagation to the clients.

If all goes well, we will also deploy a public client to use the data from Wikidata. If the repo, the client, and the synchronisation work well for a few days, we will aim at deployment to the Hungarian Wikipedia. If anything goes wrong, we won't deploy to the Wikipedias in 2012, but in early 2013 (as we want to make sure that we are available for fixing Wikipedia in case something goes wrong).

So, this is the current plan. Things might change, but here is to keep you posted. Cheers, Denny --Denny Vrandečić (WMDE) (talk) 15:25, 3 December 2012 (UTC)

Plans are one thing, reality another. Due to a DB update issue we had to rollback the deployment that started, so we are currently still on the same code base. We will reassess the schedule and keep you posted. --Denny Vrandečić (WMDE) (talk) 20:26, 3 December 2012 (UTC)

We'll do another attempt at updating today. I hope this time everything goes smoothly. The database will be locked again for the time of the update. --Lydia Pintscher (WMDE) (talk) 15:46, 5 December 2012 (UTC)

The site has been updated with lots of bugfixes and a new Special:EntitiesWithoutLabel. You can find all changes here.

We'll still have to do some minor clean-ups tomorrow. --Lydia Pintscher (WMDE) (talk) 20:59, 5 December 2012 (UTC)

Bugs

I can't seem to be able to add interwiki links to any items. It says "Links to pages are already set for all known sites." and [add] is grayed out. Chris857 (talk) 21:06, 5 December 2012 (UTC)

Same issue here. --Rschen7754 21:10, 5 December 2012 (UTC)

It does not seem to be influenced by age of item or what language I view it in. Chris857 (talk) 21:12, 5 December 2012 (UTC)

Urgh. Yes. We're working on it. --Lydia Pintscher (WMDE) (talk) 21:22, 5 December 2012 (UTC)

Looks like it might be fixed. <Cross fingers>. Chris857 (talk) 21:47, 5 December 2012 (UTC)

Pop up Wikipedia tool

So I'm doing Wikidata:Labels and descriptions task force/en work, and it would be very useful for me to have a tool that I can turn on and off that, when on, shows me the first 500 or so characters of the English language Wikipedia article linked to on the page I'm viewing. So if I were viewing Q1780, It would show me roughly the first paragraph of en:Bratislava. This would make adding descriptions much smoother.

Is this possible? Sven Manguard Wha? 21:49, 30 November 2012 (UTC)

+1, as the tool "popups" on wikipedia : when your mouse is on a blue link, it's show a popup with the text of the article in. - Bzh-99 (talk) 21:57, 30 November 2012 (UTC)

Well, that itself wouldn't be very useful to me, because ideally I'd be copy/pasting a few words of from the popup into the description. I need something slightly more stable. Sven Manguard Wha? 22:00, 30 November 2012 (UTC)

Good idea, a tool like this would be helpful to me too.--Stevenliuyi (talk) 09:38, 1 December 2012 (UTC)

I wonder if a tool along this line of thinking would enable us to propose a cross-wiki description sweep? In other words, I'm suggesting that we use the current workload with Wikidata descriptions as an opportunity to also audit opening sentences throughout Wikipedia. On top of killing two big birds with one stone, a cross-wiki sweep (improving Wikipedia opening sentences and Wikidata descriptions at the same time) would give us an opportunity to show Wikipedians that this wiki is more than simply a hangout for statisticians and interwiki bots. —WFC— 10:01, 1 December 2012 (UTC)

Maybe check out User:Denny/articlePreview.js and feel free to refine it. --Denny (talk) 17:16, 1 December 2012 (UTC)

Very useful, thanks.--Zolo (talk) 09:39, 2 December 2012 (UTC)

Thanks! Sven Manguard Wha? 03:56, 4 December 2012 (UTC)

Thanks.--Stevenliuyi (talk) 05:36, 7 December 2012 (UTC)

Step by step editing guide .pptx file

Hello all. Apologies if this isn't the place to put this, but if there is a translators' noticeboard, I haven't found it yet. I have created a step by step guide for the English version of Help:Editing, however there's no way to upload the PowerPoint itself, I had to upload a PDF. If you are interested in translating the document, I have uploaded the PowerPoint to mediafire.com, where I believe that the .pptx file itself can be downloaded. Don't be afraid if it looks nuts on the mediafire web view, it works fine once downloaded. Please feel free to use whatever you'd like from it. This is also Sven Manguard 19:43, 4 December 2012 (UTC)

Looks nice. Can you upload it to Commons? —Theopolisme 21:38, 4 December 2012 (UTC)

The presentation is on commons in PDF form at File:How to Edit Wikidata.pdf, and is already in Help:Editing. PowerPoint is a proprietary format, so Commons can't accept it. Sven Manguard Wha? 23:26, 4 December 2012 (UTC)

I meant PDF; thanks regardless. —Theopolisme 23:50, 4 December 2012 (UTC)

I like it. Thanks. :) Raoli (talk) 11:28, 5 December 2012 (UTC)

Nice work Sven :) --Beta16 (talk) 20:28, 6 December 2012 (UTC)

Mass Collaboration Assembly at 29C3

Hey :)

We're doing a mass collaboration assembly at 29C3 later this month in Hamburg. The goal is to show some of the cool stuff large projects are doing. I'd love to have some of you there for talks, panels, workshops, booth and whatnot (depending on what you want to do). Anyone up for that? Let me know and we'll figure out the details. --Lydia Pintscher (WMDE) (talk) 15:54, 6 December 2012 (UTC)

Just thought I'd mention that "29C3" is the 29th Chaos Communication Congress. It will be running December 27th to 30th, 2012 in Hamburg, Germany. I won't be there, as I'm in the US and can't travel like that on short notice or without it being paid for by someone else, but I wish you all well. This is also Sven Manguard 20:26, 6 December 2012 (UTC)

Interwiki and Commons

Wikimedia Commons and Wikipedias enjoy strange interwiki relation. Wikipedias do not link to Commons, but Commons adds interwiki links to Wikipedias. Majority of those links are between Commons categories and Wikipedia articles. Most Wikipedias use some sort of Commonscat template (read commons-cat, NOT common-scat) to mark interwiki link to Commons. A logical place to put such links would be in the wikidata interwiki tables. The same is true for interwiki links between wikisource projects or links to "sister projects" like between Commons and Wikisource. Should Wikidata interwiki pages be expanded to allow specifying the site? --Jarekt (talk) 16:52, 6 December 2012 (UTC)

reuse of items

Am I right, that a reuse of items [6] is not desirable? I did it some times, but felt not happys with that... Conny (talk) 20:07, 6 December 2012 (UTC).

Yes items should never be reused, at the beginning this would not be such a big problem but later if other websites will link to wikdata there have to be Unique ID. --Sk!d (talk) 22:05, 6 December 2012 (UTC)

+1. We should add this to the guideline. BTW: It would be great if the ID would not only be part of the URL but shown next to the item. --Kolja21 (talk) 23:45, 6 December 2012 (UTC)

Maybe you like this one. I also  Support not to reuse items again. --Bene* (talk) 08:17, 8 December 2012 (UTC)

Obsolete Schreibung

Hi, I think that we should not add any pages which are in this category on de-wiki w:de:Kategorie:Wikipedia:Obsolete Schreibung. Because there will not be any interwiki links. I started discussion on page Talk:Q390653, but no answers there, so I wait opinions here. --Stryn (talk) 10:17, 7 December 2012 (UTC)

• I am not a de.wp regular, though I do speak German. Are all articles in these categories doubled by real articles? If yes, we should just treat them as redirects.--Ymblanter (talk) 11:50, 7 December 2012 (UTC)

It would be very hard to tell my bot not to create articles like this, but it could be possible to list up all items in this category which have a wikidata item. Currently WD:N says that the item would be legit. --Sk!d (talk) 13:25, 7 December 2012 (UTC)

These pages are a form of redirect. The obsolet name should be written in the field "Also known as". Please also be aware of de:Kategorie:Wikipedia:Falschschreibung (misspelling). This category should be excluded from Wikidata. --Kolja21 (talk) 20:53, 7 December 2012 (UTC)

How about pages like w:AR2D? IMO we could exclude all the pages which has been mentioned in this discussion. --Stryn (talk) 11:39, 8 December 2012 (UTC)

 Support, we could add these exceptions to WD:N.--Stevenliuyi (talk) 11:47, 8 December 2012 (UTC)

Well, I think bots could skip pages like this one. Pywikipediabot does recognise disambiguation pages by checking if a template on MediaWiki:Disambiguationspage is on a page. I am no programmer, but I think the same method can be used in this case. We would just go one step further and exclude those pages.--Snaevar (talk) 17:25, 8 December 2012 (UTC)

Script for Wikipedia

In English Wikipedia, I use a script which was earlier published on this board and which used to add the Wikidata link for an article in the tools. Two days ago, it stopped showing up, this is why I created two items here which originally were duplicates (now corrected). Does everybody know what is going on? Sorry if this is not a Wikidata question. Thanks in advance.--Ymblanter (talk) 12:39, 7 December 2012 (UTC)

It went broken after the latest update. You need to make following edits: [7]. --Stryn (talk) 12:55, 7 December 2012 (UTC)

Great, it works now. Thank you so much.--Ymblanter (talk) 13:30, 7 December 2012 (UTC)

Page for interwikiconflicts

There are currently two sites to report interwiki conflicts Wikidata:Interwiki conflicts and Wikidata:Report interwiki conflicts. I think there should be only one site. In my opinion the first site looks better but there is no description on how to create a new section. There should be also the possibility to see which languages are in conflict so if i am from the italian community i could solve conflicts for the italian links. What do you think? I strongly recommend to delet one site (make a redirect) and improve one site and promote it on the main side, because this will be one of main problems wikidatians have to solve. --Sk!d (talk) 21:24, 3 December 2012 (UTC)

Exactly, support. --Stryn (talk) 21:37, 3 December 2012 (UTC)

 Support Conny (talk) 12:06, 4 December 2012 (UTC).

I had created Wikidata:Interwiki conflicts to test for test for better ways of listing interwiki conflicts, but both pages should eventually be merged. --Zolo (talk) 12:27, 4 December 2012 (UTC)

 Support -- It's better to merged. Wagino 20100516 (talk) 12:47, 4 December 2012 (UTC)

 Support two pages are definitly wrong. may there be a link to User:BeneBot*/conflicts ? --Bene* (talk) 13:42, 4 December 2012 (UTC)

 Support Yes, both should be merged. --Sotiale (talk) 01:42, 5 December 2012 (UTC)

Yes both can be merged, usually the oldest one gets the preference. When it should be merged depends on the creator Zolo, who had the intention to test. Are the tests finished? Romaine (talk) 15:47, 5 December 2012 (UTC)

I try to merge and configure archive etc. next days. Conny (talk) 19:34, 6 December 2012 (UTC).

My aim to merge historys did not work, maybe this feature is fixed? :) Need some help with the new system of Subpagecreation and embedding. Conny (talk) 18:01, 11 December 2012 (UTC).

"Abuse filter" or "Edit filter"

Hi,

Which name does the Wikidata community prefer for the Abuse filter - "Abuse filter" or "Edit filter"? The current naming in the system messages is inconsistent.

I don't think that either of the names is better. I support "Abuse filter" for a purely technical reason - I like to avoid local changes to system messages when there is no strong need for this. But if the community wants a different name, then it should be consistent. I guess that having a little straw poll about this not-very-important issue won't hurt, but correct me if I'm wrong. --Amir E. Aharoni (talk) 10:03, 5 December 2012 (UTC)

Before anyone starts to make big changes in the message space, do try to get a clear consensus on what would be the right thing to do (like "Abuse filter" vs "Edit filter") and try to figure out if the changes could go into Translatewiki instead of making them local overrides. Right now we are starting to get a lot of local overrides and that is sort of pointless. Jeblad (talk) 18:34, 8 December 2012 (UTC)

Abuse filter

• I support Abuse filter, because this name is OK, and local changes to messages should be avoided. --Amir E. Aharoni (talk) 10:03, 5 December 2012 (UTC)
• Keep it consistent. Jeblad (talk) 10:14, 5 December 2012 (UTC)
• I agree with Amir. --Sotiale (talk) 10:21, 5 December 2012 (UTC)
• Of course. --Stryn (talk) 10:56, 5 December 2012 (UTC)
• It's called the abusefilter... I see nothing wrong with that name. The point of it is to try to find/prevent abuse. Ajraddatz (Talk) 14:35, 5 December 2012 (UTC)
• It was designed to find and prevent abuse, so AbuseFilter it is.--Snaevar (talk) 15:21, 5 December 2012 (UTC)
• per abuse ;) --Vogone (talk) 16:38, 5 December 2012 (UTC)
• If it ain't broke, don't fix it. —Theopolisme 16:48, 5 December 2012 (UTC)
• Although my home wiki, the English Wikipedia, uses "edit filter", all other wikis seem to use AbuseFilter, plus, this is the proper name for the extension.--Jasper Deng (talk) 18:35, 5 December 2012 (UTC)
• Name used on most wikis. –sumone10154^(talk) 21:52, 5 December 2012 (UTC)
• same name as other wikis --Beta16 (talk) 09:20, 6 December 2012 (UTC)
• I think we have to mantain the same name as other wikis. Restu²⁰ 09:36, 6 December 2012 (UTC)
• Abuse of Wikidata is abuse of Wikidata, whether the textual content is abusive or not. This is the correct name for the thing. —WFC— 09:50, 7 December 2012 (UTC)
• best name. Lukas²³ ^talk in German ^Contribs 19:13, 7 December 2012 (UTC)
• Of course. Tpt (talk) 21:01, 7 December 2012 (UTC)
• Per all above me Wiki13 (talk) 11:38, 9 December 2012 (UTC)

Edit filter

• May filters may be created whose intention is not to tag abuse. Merlissimo (talk) 11:09, 5 December 2012 (UTC)
• Per Merlissimo. "Abuse" may disturb people whose good faith edits are tagged. Bináris (talk) 21:44, 5 December 2012 (UTC)
• I think Merlissimo's and Bináris arguments are valid, and esp. how it might tag good faith edits. Jeblad (talk) 02:38, 6 December 2012 (UTC)
• Per Merlissimo and Bináris. Filters can also be used if it isn't abuse. --Bene* (talk) 19:18, 7 December 2012 (UTC)
• As per Merlissimo and Bináris. --Rsrikanth05 (talk) 11:36, 9 December 2012 (UTC)

more prominent contribute page

Hey :)

I think it'd be great if we could link Wikidata:Contribute somewhere more prominently and expand it where needed. --Lydia Pintscher (WMDE) (talk) 14:00, 6 December 2012 (UTC)

I have changed the design a bit and marked it for translation. Hope you like it ;-) --Bene* (talk) 08:04, 8 December 2012 (UTC)

Thanks for marking it Bene*. I've started translating it in bits. Is it okay if I change the meanings of a few sentences in Hindi? The word Cool doesn't exactly have an equivalent in Hindi. --Rsrikanth05 (talk) 11:56, 9 December 2012 (UTC)

Art history vs History of art

How you solve the problem with two subjects:

• Covering the academic subject: Art history
• The product of said subject: History of art

With only one representation term in other languages:

• de:Kunstgeschichte = academic field + subject

Is there a page (task force?) where those cases are listed?

--Media watch (talk) 15:00, 6 December 2012 (UTC)

How is this a problem? Labels don't need to be unique. --Yair rand (talk) 17:17, 6 December 2012 (UTC)

It's a problem because I can only add one interwiki link. The correct Wikidata entry would be:

1. item: Art history and History of art
   1. de:Kunstgeschichte
   2. en: no Wikipedia article
2. item: Art history
   1. en:Art history
   2. de: no Wikipedia article
3. item: History of art
   1. en:History of art
   2. de: no Wikipedia article

--Media watch (talk) 19:21, 6 December 2012 (UTC)

I imagine you would actually create all 3 of those entries. Anyone have different ideas on this? This situation is actually very common with English common names for plants, as they often refer to more than one actual species and other languages do not have the equivalent common name but just use the separate scientific names. Kaldari (talk) 22:21, 7 December 2012 (UTC)

But it is a kind of interwiki conflict, isn't it? For example ja:美術史 appears on both pages.--J^C1

Simple solution. Create the page with the enwp title as the English label, and the dewp title for the German Label. Add the alternate name as an alias. Since the Japanese article is commons, just add it. Hope this helps. I suggest taking History of Art over Art History as Art History is more specific as a subject. --Rsrikanth05 (talk) 11:47, 9 December 2012 (UTC)

The point is, you cannot add ja to both.-J^C1 12:49, 9 December 2012 (UTC)

My point was to create an item, named History of Art in en, and Kunstgeschichte in de, and add 美術史 to it. --Rsrikanth05 (talk) 13:21, 9 December 2012 (UTC)

Get it. How about interwiki links of Art History?--J^C1 16:24, 9 December 2012 (UTC)

Problems with bot imported data and what to do about it

I've noticed that even though the original idea was to have items and page links verified by humans, this idea has basically been thrown out the window and most entries are now being created by bots with no direct human oversight. This is leading to some very messy data. As one small example, compare Q228265 and Q369197 (by the time you read this they may be fixed). In this case it is completely unclear what either page is actually designating as the label + description are identical and they both include links to the exact same topic (the Marvel comics character "Black Widow"). Obviously the problem here is that the interlanguage links on en.wiki are wrong (in this case a complete mess). Since we've apparently decided to just import this mess as is, shouldn't we at least set up some sort of reviewing mechanism. For example, marking all bot-created entries as "unreviewed" and providing a mechanism for humans to set them as "reviewed"? Kaldari (talk) 22:16, 7 December 2012 (UTC)

Also if we're just scraping the en.wiki interlanguage links en masse, why don't we just import them directly from the en.wiki langlinks table rather than scraping them with bots? It would be several orders of magnitude more efficient. Kaldari (talk) 22:34, 7 December 2012 (UTC)

(edit conflict) The problem is the sheer scale of bot operations here. However, we could theoretically make the bot userright not include autopatroller — but then, what about all the actual vandal edits, swallowed up/hidden by the bot edits? As such, that doesn't seem to be an option. I suppose there could be some sort of filter/tag to unreviewed bot edits...but still, who would be able to review all of them? —Theopolisme 22:37, 7 December 2012 (UTC)

As they say on en.wiki, there is no deadline. The alternative is to have them randomly reviewed by whoever stumbles upon them with no idea if they have already been reviewed by 10 other people. What do you think about the idea of just importing the data straight from the database rather than scraping it with bots? Kaldari (talk) 22:51, 7 December 2012 (UTC)

The current set of interwiki links, consolidated into one place with labels and (eventually) descriptions, is in my opinion an improvement on the current set of interwiki links, separately maintained by each local wiki. Consolidating them into one location will make it easier for bots and humans alike to eventually fix the problems, and for that reason I'm all in favour of continuing at full steam. The problems we identify here are problems that already existed.

I would also request that you avoid using the word "data" in this context. If bots were importing statements that we are proposing to put in infoboxes, I would agree with requiring 100% human review, regardless of how long that might take. We need to have a reasonable degree of confidence in our statements – the things that most people would consider "data". I disagree in the context of interwikis, which have long been maintained by bots anyway. —WFC— 08:32, 8 December 2012 (UTC)

I second WFC. The issue is not that the bots are bringing things over en masse, the issue is that the things they're bringing over are, well, a mess. We shouldn't be stopping the bots for the 0.1% with issues, we should instead be focusing on making sure that the bots are able to accurately and consistantly report where they're having problems so that humans can fix those problems. On person threw around a set of numbers that was rather frightening, that there are either 14 million or 17 million (I forget which) total pages that need to be brought over, and that it would take somewhere along the lines of 350 days for one bot to do that if it were running at the far-fetched speed of 30 edits a minute. We've got three bots doing it, and they combine for somewhere less than 30 edits a minute. We've got two more in the pipelines, and even then we're going to be looking at what, 50 edits a minute? The magnitude of this project is as such that we simply cannot do this without bots. The best we can do, and the sanest answer, is to clean up after them. Eventually people are going to see the entries anyways because they're going to be adding data points and because the interwikiks are going to go live, so a ton more people are going to see everything. Let's not panic over this. Sven Manguard Wha? 17:29, 8 December 2012 (UTC)

Over time it will be easier for ordinary users to fix sitelinks as they will not fight against the bots. That will create a new situation where the quality of the linking will be higher than now. An other thing is that when the content of the infoboxes are driven by Wikidata the sitelinks must be correct for the system to work properly. That means that unlike now where a langlink can be broken and nobody notices it, that will not happen in the future. To a much larger degree the system will expose failures and that will trigger corrective actions. We will get a kind of self-aligning visual process contained at one place instead of a murky and obscure langlink system spread all over the place.

I think we need more bots that can do quality assurance on the links, and perhaps we should even try to make some special pages that does the same. For example we could verify that the page clusters seems to cover the same general topic, like MerlIwBot does now. Another solution could be to check if a label in one language is close enough to a best match in the other languages. We could also try to verify if aliases exists in the given language. There are several ways to verify the data, we just have to figure out how to do it and possibly in a way that is effective enough. Jeblad (talk) 19:46, 8 December 2012 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Exactly as Sven put it. —Theopolisme 19:33, 8 December 2012 (UTC)

It's not only a question of the "quality of the linking". The links can be set correctly, but still not fit, because we have to two different types of linking:

Wikipedia and Wikidata (phase 1) are based on similarity: links "to one or more nearly equivalent or exactly equivalent pages" (en:Help:Interlanguage links).

Wikidata (phase 2) is based on a unique header (as in the concept of en:authority control).

If phase 2 is started Wikidata will change from similarity to unique headers since one item can not have two contradictory properties. --Kolja21 (talk) 00:10, 9 December 2012 (UTC)

I have previously been told, very specifically, than an item can have contradictory statements. For instance, if references disagreed over a person's year of death, we would be able to give conflicting years of death, each backed up by the applicable source? Was this information incorrect? Assuming that my understanding is right, the situation of a specific article being linked via interwiki to a more general one would in practise be held in a similar manner. —WFC— 00:44, 9 December 2012 (UTC)

Of cause an item can have more than one and even contradictory statements. But a person should not have 2.000 inhabitants and a river been written by Thomas Wolfe. Take the scientific classification: One Wikipedia has an article about the family, the second about the genus and the third about the species. If it a a small family with only one species in the genus all three article will be linked. In phase 2 we have to separate the three articles because species and genus are two contradictory properties. --Kolja21 (talk) 01:14, 9 December 2012 (UTC)

Example: The martyrs en:Epipodius and Alexander are linked to es:Epipodio de Lyon. The interwiki link is correct since both articles are about the same subject. In Wikidata (phase 2) we have to split the articles. --Kolja21 (talk) 01:40, 9 December 2012 (UTC)

Thanks for that, I understand now. What to do in such situations is something we need to think about as a matter of urgency (guideline wise). It's also a discussion which the developers should be invited, so that they can advise us on what is and isn't possible from a technical standpoint. I've added a note at Wikidata:Contact the developers.

But as far as phase one is concerned, I still don't think that we need to stop completely – differences between Wikipedia are not problems in and of themselves when there are no statements. The important thing is that phase two is human-led, as humans are the ones who will be in a position to raise or action such issues. —WFC— 05:46, 9 December 2012 (UTC)

How should "Disambiguation pages" be linked?

Linking to a foreign Disambiguation page with translated name does not work, since the meaning is not defined yet. Linking to a foreign page with the same name does not make sense because in most cases those pages do not exist.

Right now we have a mixture of both methods (e.g. Q7387) and this is chaotic. So, how to proceed? --Sixsi6ma (talk) 22:15, 7 December 2012 (UTC)

1. Disambiguation pages should be linked to pages disambiguating the same term on different wikis, i.e. to pages with the same name, but allowing for some variations (like a "(disambiguation)" suffix.

2. I'm rather uncomfortable with having disambiguation pages (or categories, for that matter) mixed in with "real" data items, though. It messes with the semantics. -- Duesentrieb (talk) 21:35, 10 December 2012 (UTC)

-> 1. While this might work for romance and germanic languages, I doubt you could find equivalents for russian or chinese disambiguation pages.

-> 2. Could you elaborate on that, I am not sure what you mean by "real" data items.

Thank you. --Sixsi6ma (talk) 23:30, 10 December 2012 (UTC)

dB Error

Tracked in Bugzilla
Bug 42547

I just got a dB error:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "Wikibase\TermSqlCache::saveTermsOfEntity". Database returned error "1213: Deadlock found when trying to get lock; try      restarting transaction (10.0.6.44)".

Anything serious? --Rsrikanth05 (talk) 13:01, 9 December 2012 (UTC)

I would mention this at Wikidata:Contact the development team --Bene* (talk) 13:06, 9 December 2012 (UTC)

Will do. Thanks for letting me know. --Rsrikanth05 (talk) 13:17, 9 December 2012 (UTC)

This is a known issue. We are looking into it. -- Daniel Kinzler (WMDE) (talk) 21:32, 10 December 2012 (UTC)

problems earlier today

Heya :)

Sorry for the problems earlier today. The site was set to read-only for a while due to replication issues on several Wikimedia wikis. More details in Erik's email. --Lydia Pintscher (WMDE) (talk) 10:45, 11 December 2012 (UTC)

Search bar broken... again

Tracked in Bugzilla
Bug 43020

The search bar in the upper right is doing precisely nothing for me again. Item by title still works perfectly, so we're not totally in the dark, but yet again the basic search is down.

I would very much appreciate it if this could get fixed and stay fixed this time. This is also Sven Manguard 18:56, 11 December 2012 (UTC)

It seems to have fixed itself. Is there any explanation for why it went down? This is also Sven Manguard 19:45, 11 December 2012 (UTC)

Sorry for that. Can you ping me (on IRC ideally) when it happens again so we can look into it when it happens? That'd help with debugging it. Thanks! I don't know why it happened this time unfortunately. --Lydia Pintscher (WMDE) (talk) 11:17, 12 December 2012 (UTC)

It's happening right now for me, but only with certain words. For example, "rabbit" comes up with no results, while "apple" comes up with several. Sven Manguard Wha? 16:49, 12 December 2012 (UTC)

Seems like the auto-completion feature only works for page titles (which of course is useless on wikidata.org - but you can try it by typing Q123 into the search box - you'll get suggestions). I'm not sure whether it ever worked for anything else, and if so, why it stopped now. It would certainly be good if it worked for labels. I'll add a ticket on bugzilla for that. -- Daniel Kinzler (WMDE) (talk) 17:17, 12 December 2012 (UTC)

Disambiguation catch-22

Tracked in Bugzilla
Bug 42754

Issue illustrated above. If you're wondering what the text on the right is, that's this.

Hey all. I need some help figuring out how to get around Wikidata's automatic prevention of ambiguous entries. The situation is this: In English, Q175795 and Q175802 both have the label "Ozyorsk" and the description "town in Russia". It should be a simple change, and one I've done before, to just add in the province to both. However because the same ambiguity issue (same label and description) is also affecting the pair of entries in German, I can't save the changes in English.

Now I could just delete one of the articles, make the changes to the other, and then undelete the one I deleted, but I was wondering if there was another way I could fix this. Any help would be appreciated. Sven Manguard Wha? 16:54, 12 December 2012 (UTC)

There is no way at the moment, but we are working on it. Might take until January until the change goes live though, because the regular deployment schedule is suspended over the holidays. -- Daniel Kinzler (WMDE) (talk) 17:08, 12 December 2012 (UTC)

Bot-added aliases from redirects

Does anyone know what can be done about the thousands of bot-added aliases from redirects? An enormous amount are errors, and there are far too many to ever be cleaned up manually to a reasonable level of accuracy. Is it even possible to undo all aliases added by a specific user? Going through all pages edited by the alias-adding bots and removing all the aliases on those pages would probably cause the loss of a large amount of valid aliases added by users other than the bots on those pages, and all alias-adding labor since the bot edits would be lost. However, if that's actually the only way possible to mass-remove them, then the longer we wait, the more work will be lost when we finally do remove them. --Yair rand (talk) 14:44, 3 December 2012 (UTC)

For my Bot: I can identify which aliases where initially imported by my script without any problems. For dewiki nearly all redirects that are imported as aliases are valid. That's because of the redirect rules on dewiki which are checked locally my scripts. Merlissimo (talk) 15:19, 3 December 2012 (UTC)

@Merlissimo: Do you check if a redirect links to an anchor on a certain part of a page?--CENNOXX (talk) 16:44, 3 December 2012 (UTC)

I exclude static redirects, anchor redirect and redirects containing a non hidden category. And the group of label and aliases has no entries that only differ in lower/upper case. Because of Yair rand notice on my talk page i excluded enwiki long time ago. Merlissimo (talk) 16:50, 3 December 2012 (UTC)

Slightly out of context but is there anyone with ideas how we could identify important redirects? Could we ask for some additional logging from searches in Wikipedia? What about spell checking the aliases? Match aliases against text in linked articles? Any other ideas? Jeblad (talk) 17:05, 3 December 2012 (UTC)

That highly depends on the project. On dewiki we have a bot that checks if a redirect title is contained in target page text. If not sb. must add this redirect to a special page after checking. So nearly all redirects are ok as aliases. Misspellings are no redirects on dewiki.

I also think removing aliases manually is easier (one click on the x) than finding and adding new ones. Merlissimo (talk) 17:24, 3 December 2012 (UTC)

Using the method of adding endless incorrect aliases and manually clearing out errors over the course of years would not likely lead to aliases being at all accurate, ever. If the number of clicks is the issue, use User:Yair rand/FindRedirectsForAliases.js. We shouldn't fill Wikidata with millions errors just to help editors pick out the few that might be accurate. We really need to fix the fact that most of our current aliases are useless mistakes. --Yair rand (talk) 21:49, 3 December 2012 (UTC)

I agree. E.g., if some contestant on the American Idol is not a notable it redirects to the American Idol article, and then bot add it to American Idol's aliases section. Not good... --Stryn (talk) 05:15, 4 December 2012 (UTC)

Help:Aliases?

Maybe there should be a proposed Help:Aliases as there is for Descriptions and Labels? It could give advice on what counts as an alias (e.g. alternative names) and what should be excluded (e.g. common misspellings). It could then be adopted as an official guideline if consensus is reached. Other things that may need to be included are "order" (i.e. should they be in any particular order?) and "capitalisation", which would probably be the same as with Labels for each respective language. 130.88.141.34 11:32, 4 December 2012 (UTC)

 Support Clarity is key--this seems like a question that will probably keep coming up; as such, if we can at least get started on a guideline now, we'll be better prepared for the future. —Theopolisme 11:53, 4 December 2012 (UTC)

 Support I think we have to live with some irritating redirects (for example men with female names because the wife is liked to her husband). On the help page we should inform that 1) not all aliases are "real" aliases and 2) of cause, if a reader find this kind of error he should correct it. --Kolja21 (talk) 18:56, 4 December 2012 (UTC)

I've started it. Please feel free to add to it. Sven Manguard Wha? 00:05, 5 December 2012 (UTC)

Is removing the bot-added aliases possible?

To get back to the original topic, is there any way to eliminate the aliases added by User:Sk!dbot? These countless errors really need to be dealt with. --Yair rand (talk) 22:10, 9 December 2012 (UTC)

By hand. Considering how they were created, I'm not sure how we could go and correct them via bot. Ajraddatz (Talk) 19:14, 13 December 2012 (UTC)

Statistics

Is it possible and easy to get a statsitics how many elements contain a certain laguage e.g. how many hu Articles are covered already.--Saehrimnir (talk) 18:57, 15 December 2012 (UTC)

There are two tables (we call them secondary storage) that holds the information. One is for sitelinks and one is for terms, that is labels, aliases and descriptions. Both can be used for providing statistics. Perhaps something for a volunteer? Jeblad (talk) 20:49, 15 December 2012 (UTC)

Proposal: Every single piece of information "statement" added to Wikidata must be sourced, no exceptions

Hi there. We're getting closer and closer to Phase II deployment, but before we even start importing information, I wanted to make sure that we had a clear policy on sourcing information.

Reworded paragraph: When we start gathering information here, I believe that it is vital that we make sure that every individual "statement" that is hosted on this project is sourced to a reliable source. I don't think that there is any reason, other than laziness on our parts, for anything to be completely unsourced. Therefore I don't want it to even be an option, I want sourcing to be mandatory, and I want unsourced information to be either sourced or removed on sight. What constitutes reliable can be left for another discussion. I want to be strict on this because the entire value of Wikidata comes from it being a database of credible information. Sourcing is how we get credibility. The reason why I want to insist on there not being exceptions is that I think it's a slippery slope. My experience with fair use on Wikipedia has shown me that no matter how strictly worded an exceptions policy is, everyone is going to go in with a different interpretation, and fighting is going to ensue. I don't want either the slippery slope or the fighting.

Now one downside of this is that the sad fact of the matter is that, at least in English Wikipedia, many infoboxes are not fully sourced or even partially sourced. This means that we're not going to be able to just import infoboxes.

I'd like to hope that I can get the community's support on this matter. At the very least though, I'd like for this to be well debated before the technical ability to add this information in even becomes available.

Thoughts? Sven Manguard Wha? 22:50, 6 December 2012 (UTC)

That would greatly limit what kinds of data we could have. Imagine if Wikipedia needed a citation for every one of its categories. Take a look at some of the phase two example images on Meta; how would we source a certain Commons image as being an example of a "drawing"? And it would be pretty difficult to source things like a certain person's gender. How often does a source specifically say that George Washington was male? --Yair rand (talk) 22:58, 6 December 2012 (UTC)

I was referring only to statements. Not the internal stuff. I've corrected the title. Sven Manguard Wha? 23:53, 6 December 2012 (UTC)

I'm not sure there's any distinction, actually. --Yair rand (talk) 23:56, 6 December 2012 (UTC)

For many road articles, the most reliable source for the lengths *is* the government. --Rschen7754 22:59, 6 December 2012 (UTC)

I've removed the "third party" part. You're right on that one. Sven Manguard Wha? 23:56, 6 December 2012 (UTC)

 Support I agree in principle for certain types of information, and definitely for most parameters on items about living people. Though I beleive it would be sensible to have a time limit to allow people to source it before deleting it. The same way as they delete unsourced BLPs on the English Wikipedia after 10 days. I'd also be a less strict about things having to be from party sources. Many types of data are at their most reliable from the horse's mouth. Del_♉sion23 (talk) 23:04, 6 December 2012 (UTC)

I disagree. Anyone adding information is going to be taking it from a source already, why should we permit them to put in the information but not the source. This isn't prose building, it's much simpler. Sven Manguard Wha?

I agree with Sven, but the developers are already programming Wikidata that way. It does not allow to add information (statements) without an source. It is then up to the community to identify reliable sources.--Snaevar (talk) 23:07, 6 December 2012 (UTC)

I worry that such a restriction would be gamed. People putting in a source of "aaaaaaa" to meet a character limit, figuring that they'd come back to it, and then never coming back to it. Sven Manguard Wha? 23:56, 6 December 2012 (UTC)

True. I skipped the details in my last message. There is a lot more to it than I have mentioned. I have for example not even mentioned rankings of statements. Here are some links about this topic:

• "Let´s talk about Wikidata" on Wikimania 2012. There are discussions about statements between 50th minute and the 59th minute.
• meta:Wikidata/Data model#Statements (technical explaination)
• meta:Wikidata/Data model primer
• meta:Wikidata/Notes/Inclusion syntax v0.2#Statement_Parts - how statements will be included in the wikipedias. Note: This is an draft.--Snaevar (talk) 02:13, 7 December 2012 (UTC)

Making it a technical restriction seems like a bad idea, on the grounds that some information may be indisputable but very awkward to source. Having a warning box pop encouraging you to input a source would be great, but it seems likely that there will be useful or indisputable statements which may not be sourced (having unsourced statements carefully patrolled seems advisable, and those which are not implicitly true/otherwise accurate and hard to source either marked as unreliable or deleted would help avoid inaccuracies). Yair rand's examples show how this could get in the way of constructive edits. Even sourcing something like.. <notable person> is a human, it's not clear to an editor (especially a new one) how to source that, and it's not something which necessarily needs a source. hm, that's not an ideal example either, depends on how specifically a source should support a statement in the guidelines. Anyway, it could end up putting people off editing if the software just refuses to save something they're not sure how to source. I'll try and think of a better one. You could link to many reliable sources which imply that, but requiring a source which directly states it seems like it would get in the way of useful edits. If nothing else, building this into the extension as required limits the use elsewhere dramatically, though that's probably not the primary concern. Main point: technical flexibility is good, lets us adapt policy on what needs/does not need sourcing without dev intervention. Not everything necessarily needs a source, even though a VAST majority should have one. Perhaps we'll find that the exceptions are so rare that it's healthier to only accept submissions with sources, but that should be a community thing.

I'm not keen on discarding all unsourced infobox statements either (or mass rejecting from here+keeping on the wikipedias). Ideally they should be replaced with equivalent sourced statements, and wikidata seems like a far better place to carry out that project than spread out over all the wikipedias (avoiding redundancy in upkeep/finding of data is one of the main goals of this place). They should be clearly labeled as unsourced WP statements, but let's reuse all we can, and handle the improvements in sourcing somewhere centralized and designed for data: here. --Esp261 (talk) 01:26, 7 December 2012 (UTC)

•  Support for items only qualifying for our notability guideline. It does not make sense to do this for non-article pages (like editing stats) - the RfC on non-article content hasn't concluded, so there's still that possibility.--Jasper Deng (talk) 23:16, 6 December 2012 (UTC)
•  Neutral Sounds reasonable, but we need examples. I really would like to know first what is planned. Screenshots of the drafts would help. If there is a field called "source", what kind of content does it accept: Plain text or/and external links? --Kolja21 (talk) 23:42, 6 December 2012 (UTC)
• comment I think the proposal is very interesting, at least as a general rule. The last I heard was that references would not be enforced by the software but it would be possible to source any statement. In the document at m:Wikidata/Data_model#Statements the relation between the Statement and the ReferenceRecord is a zero-to-many, or 0..* (also written as *). That means there can be none or many references given for a statement. If we should follow the proposal the relation would be changed to 1..* (also written as +). The change in itself to enforce this in the software would not be difficult, but it could make it nearly impossible to construct statements. The reason is that you would not be able to create statements without adding the references at the same time. Because of this it would be difficult to have an absolute and software-supported rule for this, but as a general rule it could be wise. At least it would create a positive drive to source (mostly) everything. Jeblad (talk) 01:34, 7 December 2012 (UTC) 01:32, 7 December 2012 (UTC)
• I am wondering whether it would make sense to make sources required for some types of data only. That would be a pretty crude heuristics but possibly better than nothing. It certainly makes sense to require a source for a quote or for a figure, but much less so for a Commons file, or for claims like "Barack Obama is a human". --Zolo (talk) 06:29, 7 December 2012 (UTC)
•  Support a non-negotiable principle as far as I'm concerned. I would even go as far as to suggest that phase two be delayed until the software is capable of enforcing this. No source should equal automatic deletion within a week, IMO. To accept anything less than that from the software would be to knowingly necessitate needless backlog drives, and at the same time open ourselves up to (100% justified) accusations of institutional slackness and an unacceptably high error rate.

  Actually having to provide a false source for fake information would be a natural deterrent to those minded to do so. Not a complete one, but a strong start. Additionally, plausible but false statements backed up by nonsensical strings are easier to detect than plausible but false statements without a source. —WFC— 08:43, 7 December 2012 (UTC)

• My comment on requiring the software to enforce this obviously depends on there being consensus for everything to be sourced. I'm just assuming that the community's interest in verifiability will win the day. What we also have to consider is the willingness of individual wikis to use our data if it is questionable, and this project's viability if the bigger wikis choose to have nothing to do with us. —WFC— 09:11, 7 December 2012 (UTC)

•  Neutral Any data may not have source. If all information must be a source, we will NOT be able to add every data from the Wikipedia infoboxes. Raoli (talk) 11:33, 7 December 2012 (UTC)

• Can you provide an example of accurate information on Wikipedia, which could not possibly meet the sourcing requirement? —WFC— 11:37, 7 December 2012 (UTC)

  E.g. death of people. On dewiki we mark every person as death how was born before 1869 as death because this is the year of birth of the oldest living person (with not confirmed date). Or if sb. was born in 1740 the infobox contains entry "date of death: 18th or 19th century". It is feasible that he did not live in 20th century. Merlissimo (talk) 12:14, 7 December 2012 (UTC)

  On date of birth/death specifically, we could usually source "unknown". The other option would be to say that the subject lived until at least this point in time. For instance, if sb. invented something in May 1767, we could source their death as being "after May 1767". Additionally, there will be plenty of sources for something like en:Maximum life span, which might be used in tandem with such statements after relationships kick in.

  But I'm not trying to dismiss your general point: it's a very strong one. To an extent my response depends on the technology. Let's say a local wiki chooses to use Wikidata in infoboxes: wouldn't they still have the option to retain what they already have? For example, if date of birth were known, would it be possible for de.wiki to use Wikidata's value for birth, but keep its "18th or 19th century" estimate for death? —WFC— 14:28, 7 December 2012 (UTC)

  An very interesting case is en:Riaz_Ahmed_Gohar_Shahi. All wikipedias (ar / da / de / fr / it / lv / ms / nn / pl / ru / sv / zh) except enwiki have categorized this person as dead. On enwiki he is only disputed and so "possible living people", because he promised that he will revive one day. Merlissimo (talk) 14:52, 7 December 2012 (UTC)

  He is not dead on fi-wiki either. Because we don't do own research, we need reliable sources. Once, about two years ago I updated article about Bomis because it's already dead project, but because I can't find any sources, that project is dead, my update was removed. On Finnish Wikipedia sources are very important. --Stryn (talk) 15:40, 7 December 2012 (UTC)

  There are a lot of aspects of en.wiki that I have fought tooth and nail to avoid on Wikidata, but one of my favourite principles there is to "let the facts speak for themselves".

  In the example you give, there are sources that cite him as having died in 2001, others which say 2003, there will undoubtedly be at least one source which says "between 2001 and 2003", and yet other sources say that he might still be alive. Wikidata's function should simply be to provide different statements for each of these possibilities, with sources, and then let individual Wikipedia decide which statement to use, if any. For anyone who might be researching him on Wikidata directly, they will have all the statements available to them, and be able to draw their own conclusions. —WFC— 08:12, 8 December 2012 (UTC)

 Support however I am concerned, that will definitely prevent copying fields from Wikipedia or Commons infoboxes, since fields there often do not have references for every individual fact. It might be tricky to provide a source for images depicting people: since most images on Commons do not require references proving that the subject of the image is who the description claims. Same with genders (already mentioned), in commons we have a field for gender in the Creator template, however that field is often filled based on name, image, or references to "he" or "she" in the writing about person. Lately I was helping with infoboxes for climbing areas (en:Template:Infobox_climbing_area) and some of the fields like "Cliff aspect" (very important for climbing) are mostly found by checking it on Google Maps. So the reference might be "See any map?". --Jarekt (talk) 14:08, 7 December 2012 (UTC)

•  Oppose As Raoli said there are some data that would be interesting to have in Wikidata and hat have no source. By example: We will want, I believe, to add the VIAF ID to Wikidata pages with a statement. And I don't see how it's possible to have a source that give the mapping from VIAF ID to Wikidata page. An other example: in the future, I'm pretty sure that people will want to add the Wikipedia's historical monuments lists to Wikidata and these list contain coordinates of monuments of countries whom database of historical monuments doesn't give coordinates as the French one. So, I don't think that the must is the right way to take. I believe that a policy like the Wikipedia ones is a better way to adopt. Tpt (talk) 17:48, 8 December 2012 (UTC)

• Starting at must and making policy adjustments as and when necessary, is surely preferable to starting at "we would very politely ask you to provide a source" and hoping for the best. —WFC— 06:39, 9 December 2012 (UTC)

•  Oppose I disagree. This is a wikimedia project. Everyone knows that in wikimedia projects we deal with user generated content. And we also know a source is not a 100% gaurantee for correctness. In criminal law even one item of proof is no proof.
  However, our wikidata is sourced, to the wikipedia article it took the data from.
  If I use wikdata to find, say, the avarge age of nuclear reactors it is likely that what I find is reasonably correct & usefull, and a 95% correctness won't kill me. If I look for data about, for example, the average time of death of aposteles...., whatever fringe subject, maybe I should really double check what wikipedia, wikidata give me.
  To demand 100% sourcing for wikidata would kill the usefulness of this project to me. -- Stratoprutser (talk) 18:50, 8 December 2012 (UTC)
  • I have yet to see a example of something that can be put in a statement that can't be sourced. Not a single one. Someone was talking about images before, but I don't see how images would wind up in statements. If we allow statements without sources, we're going to open the door to people sticking their personal opinion into the project. Anyone that's had to suffer through dealing with genre warriors in music articles or nationalist POV pushers knows exactly what my worry is. Wikidata is a collection of data, data can be traced back to where it came from. If it can't, it's untrustworthy, period. Sven Manguard Wha? 23:10, 8 December 2012 (UTC)
    • Data comes from wikipedia entries and can be traced back to there, "period". -- Stratoprutser (talk) 16:42, 9 December 2012 (UTC)
      • What? --Yair rand (talk) 18:55, 9 December 2012 (UTC)
      • Data from Wikipedia will come from Wikidata, not the other way round. "We don't need citations on Wikidata as people can go to the Wikipedia article and see the reference there" is the exact opposite of what Wikidata is for. Del_♉sion23 (talk) 19:04, 9 December 2012 (UTC)
        • Ah? Thats why were scraping wikipedias for interwiki links? -- Stratoprutser (talk) 19:13, 9 December 2012 (UTC)
          • Interwiki links don't need references in this proposal. I hope we don't start just scraping data from Wikipedia. There's no time limit here so it would be best to do it well and do it properly than do it quickly and have a Wikidata full of unreliable information. Del_♉sion23 (talk) 21:08, 9 December 2012 (UTC)
    • So how would you find a source specifically stating a random notable individual's gender? --Yair rand (talk) 18:55, 9 December 2012 (UTC)
• comment I wonder if this could be connected to ranks. This is a feature of the statements. See m:Wikidata/Notes/Data_model_primer#Ranks for a description. One implementation that would increase users willingness to add references could be to say that to promote statements to preferred they must either have a source that can be verified by some automatic means or by being promoted by an other user with the necessary rights (that is a patroller). Automatic means could be that the source must be available on the net and must have a valid quote from the external source. Ideally we should be able to find all the data in the quote but that could be difficult. It should although be possible to identify the quote in the content from the external source. In practice the user copies a snippet from the external source, enters it in the available field for this, and adds placeholders (like […]) for text that should be left out. Jeblad (talk) 22:52, 8 December 2012 (UTC)
•  Oppose Not needed, atleast not for now, considering that the statement on Wikidata is merely a description of the article which is most likely sourced from the respective language Wikipedia article. --Rsrikanth05 (talk) 10:55, 9 December 2012 (UTC)

• Please note that we are talking about statements, not descriptions. —WFC— 12:29, 9 December 2012 (UTC)
  • I did read that. As of now, what else except a description is counted as a statement? If each and every link to individual wikipedia pages require a source, that would be very redundant. --Rsrikanth05 (talk) 12:36, 9 December 2012 (UTC)
    • This is not for now, but for when Phase 2 comes in. Each individual data point should be referenced or Wikidata will be unreliable itself. Del_♉sion23 (talk) 18:55, 9 December 2012 (UTC)
      • Just to reiterate, we are not talking about descriptions. —WFC— 12:59, 11 December 2012 (UTC)

•  Support Authors in wikipedia articles dont have to decide whats right or wrong but can offer conflicting information from different sources to the reader, may it be in the text or in a footnote - which wikidata cant (as far as I understand it). So if you construct a statement on wikidata the people on wikipedia need to know on what source it is based - or they just have to take it as a step in the wrong direction and prohibit its use :) Alexpl (talk) 12:50, 9 December 2012 (UTC)

  Wikidata will allow to set conflicting values for the same property and for each values one or more sources. For more information see Data model primer. Tpt (talk) 15:47, 9 December 2012 (UTC)

  That is true, but Wikipediareaders are not very likely to go Wikidata to check on conflicting values. They will mostly accept the Wikipediastatement, generated from Wikidatacontent as fact. Alexpl (talk) 07:03, 10 December 2012 (UTC)

•  Oppose deletion on sight of unsourced statements, at least if they have been imported from a Wikimedia project. While we should ultimately be aiming to serve well sourced data to the projects, making an existing statement's lack of a source more visible would also be useful. I presume we can ensure that they are clearly marked as unsourced when used in projects, based on the "warnings" part listed in meta:Wikidata/Notes/Inclusion_syntax_v0.2#Statement_Parts. But even if this isn't possible, storing them here on Wikidata in some form of quarantine (where they couldn't be accessed by the projects) could still be of some use, to show editors here which statements still need sources. I would only support deletion on sight if it was technically not feasible to ensure unsourced statements were clearly labelled as such when they were used in the projects, nor to prevent them from being used. Speedy deletion might however make sense for particular kinds of unsourced statements, e.g. controversial statements about living people. --Avenue (talk) 17:10, 10 December 2012 (UTC)

  I like the quarantine idea for data which has been imported from WMF projects such as Wikipedia. Perhaps a combination of a quarantine for stuff we are saying has come from another Wikimedia project, and deletion on sight for completely unsourced statements (not sourced to a WMF project)?

  It's important to stress two things. Firstly, that the deployment of phase two will be extremely gradual. The number of unique articles throughout Wikipedia will be something in the order of 10–20 million, and I would probably stick another zero on that to estimate the number of statements we would be aiming to create.

  Secondly, my understanding is that Wikidata has not been designed to function in any way as an on/off button – I believe that individual projects will be able to choose precisely what they do and don't want to use from here, right down to individual statements. If we are importing a statement from Wikipedia but haven't gotten around to locating a third party source, local wikis may as well continue to use their long-standing local data, in the knowledge that we will eventually provide them with properly sourced data. —WFC— 12:59, 11 December 2012 (UTC)

  I don't object to speedy deletion for unsourced statements that don't come from a WMF project. I'd support your suggestion of a hybrid quarantine/speedy deletion framework for unsourced statements of WMF/non-WMF origin respectively. However I still think serving unsourced WMF-origin statements with warnings attached would be better than a strict quarantine, because it increases the number of editors who'll be made aware of the problem. Maybe displaying the warnings needn't be compulsory, but I think it should at least be the default. --Avenue (talk) 15:25, 11 December 2012 (UTC)

•  Support The more I think about this - quite radical, in fact - proposal, the more I think Sven isn't just right. He's damn right. About importing data from Wikipedia, let me just tell this: I was translating a Spanish article about into Italian, that I later found to be both POV and unsourced. So I started to do some researches on my own, and among other things I found out that both his place of birth and death as written on Spanish Wikipedia were wrong - and I didn't work that hard to find a good source. This is just a small and relatively inoffensive case, but let's just think for a moment about a potential problematic article/item... That's why I'm totally in favour of Sven's proposal. --Sannita - not just another it.wiki sysop 00:40, 13 December 2012 (UTC)

  How does refusing to host unsourced data here help to determine whether it is incorrect? I think we should aim to develop a process that notifies Wikipedia readers/editors of possible data problems in an article, and thus encourages people interested in the subject to help fix it. I don't see how simply refusing to host unsourced material here would do that. --Avenue (talk) 06:46, 14 December 2012 (UTC)

•  Support I think it would be no big problem to recycle data from Wikipedia, but if we do so, the exact version of the Wikipedia page should be given as source and it should be considered as a really bad source. --Kersti (talk) 16:26, 17 December 2012 (UTC)

What Wikidata can that Wikimedia Commons can't

Hi everyone ! I'm currently working on a fr-wikipedia article about a major roman door of a French basilica. In one of the source, the scholar draws lines between one of the corbels and other artworks. I really don't know how to make these lines visible in Wikimedia projects : I can (and will) write it on the Wikipedia article, but I would also like to have it visible on Wikimedia Commons as well and the "other version" field of the artwork template doesn't feel like the proper tool. But with Wikidata, we will be able to draw these lines easily :) This message had no other goal than to say "I Love Wikidata" :) Léna (talk) 11:40, 16 December 2012 (UTC)

Metrics of content stability

Hi! I'm new around here and I'm not sure where's the best place to get feedback, but this looks a promising place :-)

I've just added a proposal at Wikidata/Preventing unwanted edits about ways to allow programmers to assess the rate at which some resources are edited. The idea is basically that edit wars should not lead bots and scripts astray; for that, programs using Wikidata should be able to detect values that are changing quickly or recently, and review the level of trust that they place on them.

The idea of ranks is a good and simple base for this goal, but might not be enough if their values can be manually changed by editors at any time. Having some stability metrics so that programmers can develop their own ranking systems would be preferred. What do you think?

P.S. (Is there a way to Wikilink to the Wikidata pages at http://meta.wikimedia.org/ from here?) Diego Moya (talk) 19:10, 14 December 2012 (UTC)

Yes, there is a way to link to pages on Meta-Wiki. This can be done with [[m:<page>]] or [[meta:<page>]]. --Wiki13 _talk 19:27, 14 December 2012 (UTC)

Diego: This is also possible on every wikipedia, wiktionary etc. Lukas²³ ^talk in German ^Contribs 19:52, 14 December 2012 (UTC)

Is it yet possible to link to Wikidata from other wikis in a similar manner? —WFC— 00:28, 15 December 2012 (UTC)

The prefix is d:. --Rschen7754 01:00, 15 December 2012 (UTC)

Both d and wikidata works as prefix, they were defined some time ago. They can easily be used for links to items with the q-ids (Q585) or through sitelinks (Special:ItemByTitle/enwiki/Oslo).

The attribute rank for statements is a three-level quality going from deferred to normal and preferred. The idea is to change them manually, perhaps with only admins or auto-patrolled allowed to set preferred, or tagged somehow unless they have a source that checks out.

There are at least two ideas floating around for estimating quality in Wikipedia. One idea is to use an ageing algorithm to mark edits (also called stability) and one to mark them with calculated trust according to an observed reputation for the user doing the edit (also called WikiTrust). Jeblad (talk) 14:37, 15 December 2012 (UTC)

Great! Can you point me where are those being discussed? Thanks. Diego Moya (talk) 15:07, 15 December 2012 (UTC)

Seems like w:en:Wikipedia:WikiTrust is more or less dead now, but there is some code floating around. [8] GroupLens worked on an aging algorithm many years ago, but the project wasn't completed. Other works by GroupLens about Wikipedia. You can for example ask Aaron Halfaker from GroupLens which is now Research Analyst at Wikimedia Foundation. Jeblad (talk) 15:43, 15 December 2012 (UTC)

Ah yes, of course I've tried WikiTrust in its day; yes, it's a good example of what I'm aiming for. I'll take a look at GroupLens. Thanks! Diego Moya (talk) 00:05, 19 December 2012 (UTC)

data values - needs your input

Denny wrote down some initial thoughts on data values and we'd love to have your feedback on this. More details in this email. --Lydia Pintscher (WMDE) (talk) 21:34, 17 December 2012 (UTC)

new Wiki import task force shows conflicts for each wiki

As you know MerlIwBot is doing a complete scan of langlink at all wikipedias except enwiki every month. So my bot always have a complete overview of all conflicts on these wiki. I created reports containing pages that could not be imported automatically because of conflicts. Currently i only listed two conflict types. Creating readable list for the rest is much more complicated and will be implemented later (internally i have a connection graph).

Please give comments how i could improve this list on talk page. Also the main page needs some more info. Merlissimo (talk) 22:36, 18 December 2012 (UTC)

deployed new code

Heya :)

Just a quick note that we deployed new code to wikidata.org. All changes can be found here. We're still working on getting test2.wikipedia.org to properly work with Wikidata. Please let me know of any problems you see that might be related to the update.

Cheers --Lydia Pintscher (WMDE) (talk) 21:27, 10 December 2012 (UTC)

Just to reiterate from October; Wikidata:Project chat/Archive/2012/10#Breaking changes in the API. There are several changes to the API and there will be more in the future. Especially it will be additions of new functionality. Keep an eye on the automatically generated documentation from the API,[9] especially if something that used to work suddenly breaks. It is also possible to test-drive bots and scripts at the test repo or test client. Jeblad (talk) 22:09, 10 December 2012 (UTC)

Tracked in Bugzilla
Bug 42956

I do not know if it is related to my computer, but everything seems to work fine in most languages, but when I set the language to French, it gets slow, I cannot add sitelinks, and "import interwiki" and "label list" disappear. --Zolo (talk) 13:46, 11 December 2012 (UTC)

I have also this issue. I've reported the bug on Bugzilla. Tpt (talk) 19:07, 11 December 2012 (UTC)

There is a a small changes in the API that I forgot to mention. It should not be important, we wild-guessed that nobody was using this information anyhow. In entities there were for each entity an attribute name touched that was changed to modified. Touched was updated quite often, while modified is more seldom. There will be at least one breaking change in the next roll-out as page-specific information will be tucked away in their own substructure, possibly called pageinfo. When times come there will be a warning on the technical lists and also here. Jeblad (talk) 15:52, 13 December 2012 (UTC)

On Bugzilla, it is announced that the « Fix will be available on wikidata.org with next deployment ». But, when will be this next deployment? In French, we still cannot add sitelinks which is really annoying... --Ayack (talk) 14:21, 17 December 2012 (UTC)

As it looks right now the Foundation will have the next deployment cycle in early January. --Lydia Pintscher (WMDE) (talk) 14:24, 17 December 2012 (UTC)

Thanks for your comment. So we can't normally contribute to Wikidata for at least 15 days more... It's really a shame! --Ayack (talk) 14:31, 17 December 2012 (UTC)

Yes. I'm really sorry about that but we have to go with the deployment cycle. --Lydia Pintscher (WMDE) (talk) 14:37, 17 December 2012 (UTC)

It's also a shame that no one cares enough about any other language than English to make an announcement or offer any help to French-speaking contributors, and that everything gets reported on the English language chat. I was told Wikidata was a multilingual project; seems we have a huge misunderstanding here. Ljubinka (discussion) 15:15, 17 December 2012 (UTC)

That's not true. I am here to offer help to anyone. But it's a fact that I don't speak French. It's a pity but that's the way it is. I rely on people like you and Tpt to help me with that and spread important messages. --Lydia Pintscher (WMDE) (talk) 10:48, 18 December 2012 (UTC)

Update: We're checking if we can deploy this one bugfix only today. --Lydia Pintscher (WMDE) (talk) 10:48, 18 December 2012 (UTC)

Thank you for your help Lydia! Much appreciated. --Ayack (talk) 14:36, 18 December 2012 (UTC)

Update 2: We've deployed the fix for this last night. --Lydia Pintscher (WMDE) (talk) 09:57, 19 December 2012 (UTC)

It's strange, I've just created an item in French (Q1200967), and I still have no link to edit or add another language even after clearing Firefox's cache... --Ayack (talk) 11:08, 19 December 2012 (UTC)

Hmm. Do you have javascript enabled? --Lydia Pintscher (WMDE) (talk) 11:14, 19 December 2012 (UTC)

Does this occur in other browsers? --Rsrikanth05 (talk) 12:52, 19 December 2012 (UTC)

Yes, I have javascript enabled and it works with Firefox 17.0.1 when language is set to English, but not when I select French. With IE 8.0.6 it doesn't work whether I am in French or English. For now I can't try other browsers. --Ayack (talk) 14:47, 19 December 2012 (UTC)

Bah. Not good obviously. We will investigate. --Lydia Pintscher (WMDE) (talk) 15:11, 19 December 2012 (UTC)

Tried it with French on IE7. I too am facing the same problem. --Rsrikanth05 (talk) 15:47, 19 December 2012 (UTC)

I've just tried it at home on Mac OS 10.8.2 and it works both with Firefox and Safari... So either the problem is linked to Windows XP or it is caused by a slow connection. --Ayack (talk) 18:27, 19 December 2012 (UTC)

Note that the "blank page" problem might confuse caches, and they will be reluctant to purge and get a fresh copy. Often it seems like it is enough if you do a purge on anything in your browser, and then the pesky items starts to work. Lets say somethin like this. Jeblad (talk) 15:47, 20 December 2012 (UTC)

Now, it works well with Firefox 17.0.1 + Windows XP. So the bug seems to be resolved for me. Thanks. --Ayack (talk) 17:07, 20 December 2012 (UTC)

Using Incubator wikis' content?

Some Wikipedias are experimental, on Wikimedia Incubator. Should we be able to link those wikis' content?--Jasper Deng (talk) 19:54, 15 December 2012 (UTC)

Yes we should, but there should not be a special way for Incubator. Interwiki links can make use of the redirects in the missing.php script (like cy.wikinews.org -> incubator:Wn/cy), which are currently only for Wikimedia languages, i.e. not (yet) for Wikipedias. This will become relevant when Wikidata is extended to sister projects, and/or when redirects are implemented for non-Wikimedia languages. SPQRobin (talk) 18:28, 17 December 2012 (UTC)

That's awesome. Do you know if all of the wikipedias on Incubator have those redirects? Ajraddatz (Talk) 15:49, 19 December 2012 (UTC)

As I said, it's currently only for Wikimedia languages, by which I mean those languages in the langlist/SiteMatrix: those that have at least one Wikimedia project. Since Wikipedia is de facto always the first project, no Incubator Wikipedia can currently benefit from these redirects. The goal is to have redirects working for all language codes, currently e.g. khw.wkipedia.org gives a server error. (The domains just need to work, then missing.php takes care of the actual redirects.) SPQRobin (talk) 16:41, 19 December 2012 (UTC)

Enable rollback for autopatrollers or create a new user group

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus for rollback yet. Ajraddatz (Talk) 21:16, 23 December 2012 (UTC)

---

In my opinion rollback on this wiki should absolutely not be a big deal and more trusted users should have the permission here, because rollback can hardly be misused on this project. There can't occur any edit wars about content, because it is clearly defined. At the moment only stewards, global rollbackers, admins and staff have the permission to quickly revert obvious vandalism with "rollback". I'd like to change that with this proposal. We have three possibilities:

1: Add the "rollback" permission to the autopatrolled user group

2: Create a new user group

3: Don't change anything

I hope for your support because rollback can make life easier for some vandal fighting users :-) Vogone (talk) 20:03, 8 December 2012 (UTC)

Support 1

1. --Vogone (talk) 20:47, 8 December 2012 (UTC)
2. Support this option and option #2 with this option preferable. Once vandalism starts occurring, it really can't stay up for any significant period of time. We must err on the side of caution here.Tazerdadog (talk) 23:22, 8 December 2012 (UTC)
3. There are relatively few situations under which rollback could be misused on this project, most of them relating to labels, descriptions and statements in controversial topics. People who cannot be trusted to use rollback appropriately in such situations probably shouldn't have the autopatrolled flag, and it therefore makes sense to bundle the two together. —WFC— 00:23, 9 December 2012 (UTC)
4. --Sk!d (talk) 01:59, 9 December 2012 (UTC)
5. Autopatrollers are users with a minimum level of trust; we can certainly trust them with rollback. This, that and the other (talk) 10:37, 9 December 2012 (UTC)
6. --Steinsplitter (talk) 10:53, 9 December 2012 (UTC)
7. First choice.--Snaevar (talk) 12:21, 9 December 2012 (UTC)
8. Raoli (talk) 23:09, 9 December 2012 (UTC)
9. --CENNOXX (talk) 01:05, 10 December 2012 (UTC)
10. IW 19:00, 11 December 2012 (UTC)
11. --LadyInGrey (talk) 18:13, 13 December 2012 (UTC)
12. B25es (talk) 17:55, 15 December 2012 (UTC)

Support 2

1. Vandals will come, and the more rollbackers, the better. This is first choice, option 1 the second. Rschen7754 22:29, 8 December 2012 (UTC)

   Another point to consider: users who have an established record on other projects (rollbacker, admin) but who do not want to run for admin on this project. --Rschen7754 07:16, 14 December 2012 (UTC)

2. If we do need to expand the usage of this tool, then I'd prefer a separate group over an addition to autopatrolled. Either one works, though. Ajraddatz (Talk) 22:45, 8 December 2012 (UTC)
3. In my opinion we can wait to add the flag, whatever user group we decide to assign it, because there aren't so much vandalism at the moment. When there will be need of trusted user with rollback flag, I think we need to create a separate group from autopatrol, because I think this flag should be used by users that patrol recent changes and revert a lot of vandalism. Restu²⁰ 01:02, 9 December 2012 (UTC)
4. I had posted this on Vogone's talk page after I came across a few instances of vandalism. I support a separate group rahter than giving it to all autopatrollers. Considering the fact that an article like this one was published recently, I suspect that now habitual vandals from enwp will now try and target WD as well. --Rsrikanth05 (talk) 09:47, 9 December 2012 (UTC)
5. I support this option. Autopatrolled are users whom we trust they are not vandals and do not cause disruption. I nominated several users and they were all granted autopatrolled flag, even though I am not sure they are aware of this. In contract, rollbackers should read the policy and must be very well aware that they are rollbackers. Therefore, though I agree this is not a big deal, I believe this should be a separate flag.--Ymblanter (talk) 11:15, 9 December 2012 (UTC)
6. Second choice.--Snaevar (talk) 12:21, 9 December 2012 (UTC)
7. –sumone10154^(talk) 21:30, 9 December 2012 (UTC)
8. Lukas²³ ^talk in German ^Contribs 23:18, 9 December 2012 (UTC)
9. Not the same as autopatroller. As such, let's separate it. —Theopolisme 01:37, 10 December 2012 (UTC)

   Protection is not the same as blocking. Shall we separate those too? —WFC— 13:19, 11 December 2012 (UTC)

   That argument has been made before. It all comes down to what people view as needed and how restricted they want the access to be. Is there a serious concern on this project that we should break the adminbits apart? Sven Manguard Wha? 02:39, 12 December 2012 (UTC)

   WFC: I didn't theoretically have any problems with melding together rollback+autopatroller when I first noticed this thread. However, then I saw Ymblanter's comment: "In contra[s]t, rollbackers should read the policy and must be very well aware that they are rollbackers." There's a difference between any editor with common sense enough to make 100 good edits and an editor with one click access to revert vandalism. Different purpose, different goals. —Theopolisme 02:55, 12 December 2012 (UTC)

   Sven: Is there a serious concern on this project that people who can be trusted to create content without a second look might abuse the ability to revert content without a second look? —WFC— 02:09, 21 December 2012 (UTC)

   Theo: I don't recognise that argument, for the reasons I gave to Sven. On the other hand, there is a big difference between any editor with enough common sense to block obvious trolls/protect pages that are vandalised or subject to edit wars on an hourly or daily basis, and editors with the objectivity, analytical skills and diplomacy to appropriately close a tough RfC or policy discussion. And yet calls to diverge in any way, shape or form from the en.wiki trainwreck of an admin model seem to be falling on deaf ears. —WFC— 02:09, 21 December 2012 (UTC)

10. Merlissimo (talk) 12:31, 14 December 2012 (UTC)
11. Per Restu20. Kondi (Talk) 19:34, 19 December 2012 (UTC)

Support 3

1. Unneeded.--Jasper Deng (talk) 21:58, 8 December 2012 (UTC)
2. For the record, I support this, am neutral on option 2, and very strongly opposed to option 1. Sven Manguard Wha? 23:04, 8 December 2012 (UTC)
3. In the future, a seperate usergroup will be fine once there is a purpose, but there isn't one right now. The Autopatrolled usergroup shouldn't get rollbacker. AP is simply for not having to check over the same user over and over again for bad edits. Regards, — Moe Epsilon 04:38, 9 December 2012 (UTC)
4. I both agree with Jasper Deng and Moe Epsilon. At this stage I think there isn't any need for a seperate rollback group or assigning it to the autopatroller group. --Wiki13 (talk) 11:05, 9 December 2012 (UTC)
5. That's not a big deal, but why do we need to change something if that is not needed (for now)?--J^C1 12:44, 9 December 2012 (UTC)
6. Per User:Jasper Deng. If it ain't broke, why fix it? Tiptoety ^talk 18:22, 9 December 2012 (UTC)
7. Users tend to rollback non-vandal edits, too. This is a serious problem IMO. --Leyo 23:17, 9 December 2012 (UTC)
8. Not yet, vandalism doesn't exist just yet (oops I think I just jinxed it), and we'll have a better scope on what we need to do with the rollback group then. -- DQ (ʞlɐʇ) 05:43, 10 December 2012 (UTC)
9. Currently this is the best choice. --Stryn (talk) 06:24, 10 December 2012 (UTC)
10. Seems unnecessary for now. --Avenue (talk) 22:32, 12 December 2012 (UTC)
11. For the time being. --Sannita - not just another it.wiki sysop 00:08, 13 December 2012 (UTC)
12. Not for now, so for next year. Maybe, it's about some weeks later... Wagino 20100516 (talk) 17:59, 13 December 2012 (UTC)
13. --Ralgis^WM-CR 04:07, 22 December 2012 (UTC)

Comments

• I think I've used rollback once here in over a month. Can you provide any proof of a need for this group? Thanks, Ajraddatz (Talk) 20:06, 8 December 2012 (UTC)
  • Well, it's true that there isn't much vandalism at the moment. But I also think that we should decide about that before the vandals come. It is nothing urgent and rollback can't harm anyone. Regards, Vogone (talk) 20:10, 8 December 2012 (UTC)
    • Once data starts flowing in there is a lot more potential for conflict. However, vandalism would also be a bigger problem. I would support giving it to autopatrolled, as a vandalism edit could, once the project is up and running, disrupt every single wikipedia! Content disputes, on the other hand, would be relatively easy to adjucate. Tazerdadog (talk) 20:42, 8 December 2012 (UTC)

• I'm still undecided at the moment. I was considering that, as others have mentioned, as it hardly is used at the moment, it would be better to either leave things as-is or add it to the autopatroller group since they should be trustable (I'm leaning towards this option). There is also the issue of a future increase in vandals. If there isn't a significant increase, then any of the two options aforementioned by me still work. However, if there is a significant increase, we could easily have the group added if we remained as-is, or considering splitting the groups if we had just added rollback to autopatroller. Yes, considering there is a significant increase, we'd probably end up with the rollback group either way, but unless I see such an increase, I'd oppose having another group to unnecessarily (as in, to very little use) populate (most likely a large number of users would want to get this right).  Hazard-SJ  ✈  23:06, 8 December 2012 (UTC)
• I have supported number one on the basis that there is likely to be an almost complete overlap between those who could be trusted to create appropriate items, and those who would not misuse rollback. However, the need to do something with the rollback right will largely depend on the competence of our admin policy. If sysop tools are to be easily granted to those who would make use of them, and easily removed from those who have not, we will not have a shortage of active editors making regular use of the rollback tool. —WFC— 00:32, 9 December 2012 (UTC)
  • This is also my opinion, by the way. --Vogone (talk) 00:59, 9 December 2012 (UTC)
  • Yes, this is a quite sensible argument.  Hazard-SJ  ✈  01:01, 9 December 2012 (UTC)
• Apart from Rollback, I was also suggesting IP block excemptions. I need it quite often on enwp as I contribute from my university, where a vast IP range often gets blocked. --Rsrikanth05 (talk) 10:10, 9 December 2012 (UTC)
  • Could you post the block message here or in an e-mail? Then I could grant you the permission. Vogone (talk) 10:19, 9 December 2012 (UTC)
• One big argument for a separate group over adding the right to autopatrolled is that there is (or should be) policy to follow with rollback, whereas there is no correct usage for having one's edits marked as patrolled. Any specific responses to this? Ajraddatz (Talk) 01:02, 12 December 2012 (UTC)
• I see many voters supporting option 3 with the argument "not needed for now". This proposal is not for the need now. We want to decide what we want to make if rollback is really needed. I think some voters have misunderstood this point. Greetings, Vogone (talk) 22:44, 12 December 2012 (UTC)
  • I'd propose this when we have a need for it. We'll decide then.--Jasper Deng (talk) 18:01, 13 December 2012 (UTC)
    • Why not decide now before there's a real need? We don't have to put it directly to bugzilla/gerrit. I just want to know whether the community wants to limit these rights to admins or give it also to other trusted users. Kind regards, Vogone (talk) 18:19, 13 December 2012 (UTC)
      • At this stage it's too early to tell - much will depend on the amount of vandalism we get.--Jasper Deng (talk) 22:03, 13 December 2012 (UTC)
        • Here is my opinion on the matter: We need to be prepared a little bit in advance. You never know when vandals might strike. Once WD becomes a centralised hub between other WM projects, which will be happening soon, trust me, the vandalism will start. Being an active RC Patroler on enwp.org, I know how things could get here. The proposal is to keep the group ready for now, in the event something happens, a trusted user, upon request, may be granted these rights as is the case on enwp. My two cents, hopefully they make sense. --Rsrikanth05 (talk) 12:06, 19 December 2012 (UTC)
          • That's where I fundamentally disagree - let's not pre-emptively make any new usergroups.--Jasper Deng (talk) 22:01, 19 December 2012 (UTC)
            • We need to be a little preemptive. Vandalism on WD will have a major impact on other projects. What if someone replaces an the link to an article of a famous person to that of a lesser known rape case? It'd be disasterous. --Rsrikanth05 (talk) 07:23, 20 December 2012 (UTC)
              • We have enough sysops at the moment, and in addition, global sysops and global rollbackers can help. The amount of vandalism we get should determine who should get what permissions.--Jasper Deng (talk) 00:27, 21 December 2012 (UTC)
                • Until vandalism builds up to that point, and even after that, any user can use the undo tool. I'm not sure there is enough consensus to make any changes at the moment, so for now I'll agree with Jasper Deng. In the sense of being a little prepared in advance (Rsrikanth05 and Vogone), I believe it might be best to just draft some guidelines, and if and when the community decides to hand out the right, having the guidelines agreed to would be much easier.  Hazard-SJ  ✈  14:54, 22 December 2012 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Creating deleted items

Deleted items can't be created again. So item with number 1.000.000 wasn't actually the one millionth item. I think it should be enabled, that deleted items can be created (at least by administrators). 2A00:1398:9:FB00:45E8:5E72:6354:3244 12:29, 16 December 2012 (UTC)

Deleted items can be recreated by administrators but the community decided not to do so because of transparency reasons. Regards, Vogone (talk) 12:37, 16 December 2012 (UTC)

Most deleted items are deleted because they were duplicates. Recreating the deleted item would mean that, at least for a few moments, there were two Wikidata pages covering the same thing. Apparently this would cause issues down the road. Now while I don't personally find it to compelling of argument, I also have less grounding in databases or higher level computer stuff than a lot of people that are making the argument, so I defer to them. We're never going to run out of numbers, and there's no harm in skipping over the ones we've deleted (although it would be nice to have a setting for the enumItems gadget that allowed it to skip over deleted pages). Sven Manguard Wha? 02:20, 17 December 2012 (UTC)

Though I agree with this policy of deleting items and not "recycle" them for technical reasons, I wonder if it's possible nonetheless cancel the duplicates, and then re-create that item with another subject. Just asking. --Sannita - not just another it.wiki sysop 13:10, 17 December 2012 (UTC)

Even if some of the deleted items can be undeleted and used for other items it will not be a simple fix. The necessary mechanism to cleanse a deleted duplicate item for offending links and terms if it conflicts with another correct item don't exist for the moment. Undeletion as it is now imply deletion of the correct item before it is possible to undelete the duplicate, because there will be conflicts in the sitelinks table and possible also in the terms table. After undeletion the previous duplicate the item must be cleansed for offending links and terms before the correct but conflicting item can be undeleted too. The manual process will later on in Pase II imply publishing invalid content in all articles on Wikipedia that has a sitelink in the item, unless there are local overrides.

The correct solution would be to detect the offending links and terms and post an additional page during undeletion where it is possible to delete the offending links and terms. The ordinary edit interface can't be used for this as the item doesn't exist in the ordinary sense, but we can create a temporary object.

Note that offending links and terms may come from multiple items, that can make manual cleanup very messy.

One alternative is to simply recycle them as empty or blank items. That could work, but then the history would be wrong and must be left deleted. Also it would be necessary to fix the id generator for handling this special case. It would be a code change with no real use case, except for creating a complete number sequence. That would be a very weak argument for putting resources into coding the solution.

The simplest solution is to say that item ids should never be reused. Jeblad (talk) 13:38, 17 December 2012 (UTC)

I think this puts an end to all speculations about this. :) Thank you very much for being so exhaustive, and I suggest a little note about this should be put into FAQ or somewhere else in the guidelines, just to be sure that, when someone will come up with the same objection, we'll know what to say. :) --Sannita - not just another it.wiki sysop 15:16, 17 December 2012 (UTC)

When I inadvertently ended up creating a few dupes, instead of Requesting them for Deletion, I instead renamed them and turned them into an item for something else. Perhaps you could try this out? --Rsrikanth05 (talk) 17:42, 19 December 2012 (UTC)

Indeed. That works perfectly well when you catch that it's a duplicate 30 seconds after creating the page. It's not something I'd recommend if it's been 30 days since creating the page. Then things start to get confusing. This is also Sven Manguard 19:10, 19 December 2012 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘In the event that we do find an abandoned item with just a label or description with no links, just rename it and post a message on the talk page. I'm guessing that should suffice? --Rsrikanth05 (talk) 12:49, 20 December 2012 (UTC)

IIRC, the main problem in the past with reusing items was that there might have been links to it, meaning to link to the originally placed item. If the item is reused for something else, the link would become inaccurate.  Hazard-SJ  ✈  15:01, 22 December 2012 (UTC)

@Rsrikanth05: There is no reason for recycling but strong reasons against it. The Q... is an identifier that should not change it's subject. --Kolja21 (talk) 18:11, 22 December 2012 (UTC)

Main page localisation

Hi everyone! Good to see that the project is so alive!

I'm currently localizing all the relevant parts of the project into the Bosnian language but now I have run into a problem where I would like the page MediaWiki:Mainpage/bs to point to Wikidata:Početna strana instead of Početna strana. Since I don't have enough rights to edit the specific page, I would kindly want to request some admin here to help me accomplish this task. :) Thanks in advance! -- Edinwiki (talk) 16:02, 20 December 2012 (UTC)

 Done. --Stryn (talk) 16:05, 20 December 2012 (UTC)

Thanks Stryn! -- Edinwiki (talk) 16:07, 20 December 2012 (UTC)

Btw. Can anyone tell me if there is some way of capitalizing a language that is shown in a language box, or is there a specific reason that only certain languages are capitalized? -- Edinwiki (talk) 16:04, 20 December 2012 (UTC)

It reflects the conventions used in the individual languages. Jeblad (talk) 01:58, 21 December 2012 (UTC)

What about other pages like News and Project Chat? I had asked this on IRC yesterday and also on Deeny's WMDE page. There were people who said WD:/News/code and others who said WD:local_name. --Rsrikanth05 (talk) 11:57, 22 December 2012 (UTC)

Depends on if they use the translate extension or not. Those that do have WD:Page/code. Others have WD:Local name. Only the pages that can't use the translate extension (discussion pages) should be in the "others" category. Ajraddatz (Talk) 14:34, 22 December 2012 (UTC)

Category pages

I hope adding category pages is fine as has been done at Q1458045. --Rsrikanth05 (talk) 11:52, 22 December 2012 (UTC)

Yes, it's fine. --Kolja21 (talk) 12:52, 22 December 2012 (UTC)

Configuration templates (e.g. bot templates)

What about the usage of templates e.g. to point and configure a bot to/on a specific page. An example would be User:DrTrigonBot which uses a template in order to configure the bot (what page to edit, what content to change, source of the data, ...). So what's the "correct wikidata" way of doing this if I would like to configure the bot in order to update a given item e.g. Q45816... Shall I just create Wikidata:Q45816 and place the template with all config there? Or use another namespace? Or is there another method to use in order to do that?

Another just weakly related question would be; how to store comlete lists (1D data) or even tables (2D data) here on wikidata? All to the same item (like interwikis)? What about 2D data?

Thanks a lot and greetings --DrTrigon (talk) 11:51, 20 December 2012 (UTC)

In my opinion a bot should not use pages on-wiki for its own configuration, unless that configuration is to be shared within a project of some kind. Private configuration should be kept, well private.

List and tables will not be created as such, they will be built by querying the database and building the results in a way that can be published on Wikipedia. They will only be as complete as the items found, but the items found may not reflect articles in Wikipedia. That is the items can be without sitelinks. For example we could have items for all lakes with a water surface above 1km², even if they do not have an article even on the local Wikipedia.

Queries as described for Phase III will have their own namespace (Query) and prefix (Y) and can be referenced from articles. For example navigational templates like municipalities in counties, or tables over lakes within an municipality. Jeblad (talk) 02:00, 21 December 2012 (UTC)

The configuration has to be on-wiki else it would be worthless - the main idea is to have the possibility to configure it from wiki, consider e.g. archive bots.

So you think we should add list containing thousands of entries spread over thousands of items? What about tables (how to handle the relation between columns and rows)? E.g. a list of all table tennis players with their current ranking?

The queries are fine, but who is supposed to update/syncronize the data they contain? Do you want to do this for thousands of entries by hand? That's were my bot come into play.

Greetings --DrTrigon (talk) 07:47, 21 December 2012 (UTC)

According to your examples you end up with an archive bot that should do its job on an item? Why? I don't see a use case. If you want to do archival of the talk page, then you use the talk page itself.

There will be no way, at least not for now, to build lists or tables as a single item. Tennis players are entities that should go in their own items. Relations between rows and columns will be the result of how the queries are set up.

Queries will be updated in separate jobs. You reference a Query and it will update as new data is available. The Query page is not something you update manually, it is sort of a job description for what you want to do. As a result of the job the lists and tables are built, and those results can be handled like a single object.

Note that the items are not wikitext, they are structured data where one aspect is their ability to reference other items. Jeblad (talk) 08:24, 21 December 2012 (UTC)

So you are telling me that SubsterBot (Wikidata:Data collaborators#User:DrTrigonBot, Wikidata:Requests for permissions/DrTrigonBot, w:en:User:DrTrigonBot/Subster) and its function become completely useless and redundant with wikidata? So I can shut it down, since wikidata does everything already? Greetings --DrTrigon (talk) 08:52, 21 December 2012 (UTC)

Will wikidata be able to automatically syncronize with any external source like URL (plain text, zip, csv, odf, xlsx) or mail? --DrTrigon (talk) 09:32, 21 December 2012 (UTC)

Seems like a nice bot, and I'm sure there are interesting use cases. Unfortunately you can't post your templates on the item page, that is simply not possible as the content is JSON data. You can do it on a talk page, or possibly some other page, but templates that controls a bot from the wiki will always be somewhat fragile. Also note that your scheme with insertion of text on a wikipage will not work for items, as you can't change them as wikitext. It will be possible to change all aspects of the items through API calls, but that probably imply changes to your bot. Also note that the Queries will not insert anything, it is an extraction mechanism. The project (as done by the dev team) will not build systems for automatic import, that is up to the community. See also m:Wikidata/Technical proposal#Not to be done by the project 2. Jeblad (talk) 09:42, 21 December 2012 (UTC)

It's obvious that I have to change my bot! That's the reason why I am asking here on how to change the bot in order to make it wikidata conform. As suggested in the very first post I do have some ideas (like using "Wikidata:" namespace) but I want to do it nice (right and correct)!! So you are mentioning now it should use the "Talk:" namespace (the one beloning to the items, e.g. Talk:Q45816) - that is a statement we can build upon! ;)) Any other ideas? Other suggestions? Or does everybody agree? (to be honest - somehow I feel strange using this namespace since it is not very intuitive... but it is something I can start with)

Regarding your argument about how "fragile" such a system is; you are right! As it is used now it is not trivial to get it working, but once set-up it does its job quite well. Compared to updating all contents by hand it is way more comfortable to just maintain the bots templates... ;)) Any ideas to make it more stable are very welcome!!

Is there something like a test-item or test-wiki for Phase 2? I would like to test some of the bots functions in order to adopt them to wikidata. How to do that?

Thanks so far! Greetings --DrTrigon (talk) 10:00, 21 December 2012 (UTC)

http://wikidata-test-repo.wikimedia.de --Lydia Pintscher (WMDE) (talk) 12:59, 21 December 2012 (UTC)

Started first test on test:Talk:Q356, please have a look and comment. Thanks and greetings --DrTrigon (talk) 21:15, 23 December 2012 (UTC)

Merry Christmas

Merry Christmas everyone!

Merry Christmas everyone!

I'm escaping from my long wikivacation to wish you all a Merry Christmas and a Happy New Year. --Dalton2 (talk) 19:28, 23 December 2012 (UTC)

Merry Christmas to you too, and everyone else in the Wikimedia Project! Del_♉sion23 (talk) 22:50, 23 December 2012 (UTC)

Happy holidays :) Regards, — Moe Epsilon 03:55, 24 December 2012 (UTC)

Happy holidays also from the dev team to all of you! :) --Lydia Pintscher (WMDE) (talk) 08:37, 24 December 2012 (UTC)

From me too! :D Jeblad (talk) 08:46, 24 December 2012 (UTC)

Merry Christmas to all involved here! --Wiki13 _talk 15:34, 24 December 2012 (UTC)

Merry Christmas to all contributors and to the amazing dev team. Tpt (talk) 16:29, 24 December 2012 (UTC)

More seasons greetings from me! Merry Christmas to all who celebrate it, and Happy Holidays to the rest :-) Ajraddatz (Talk) 16:30, 24 December 2012 (UTC)

Merry Christmas to anybody concerned and a happy 25 of December to anybody else. I can't wait for January to have some free time to work again with all of you, awesome team :) — Arkanosis ^✉ 17:06, 24 December 2012 (UTC)

Q525028 ;) Danmichaelo (talk) 17:35, 24 December 2012 (UTC)

+1. Conny (talk) 18:34, 24 December 2012 (UTC).

Same to you all. :-) --Bene* (talk) 13:51, 25 December 2012 (UTC)

Yes, merry christmas! Lukas²³ ^talk in German ^Contribs 14:35, 25 December 2012 (UTC)

next steps for the first Wikidata client - the Hungarian Wikipedia

Heya folks :)

I wanted to give you a heads-up about the next steps for Wikidata deployment. In this particular case it is about the first Wikipedia actually using language links from here. A while ago we discussed this with the Hungarian Wikipedia community and they agreed to be the first to use Wikidata. (Thanks so much!) We're now getting closer to the date where this will actually happen. As it currently looks we will flip the switch on January 14th. Obviously unforseen stuff might happen and delay this but that's our current plan. More Wikipedias should follow soon after that and I will keep you posted when I have more concrete info about the dates for those. Let me know if you have any questions about this. --Lydia Pintscher (WMDE) (talk) 21:00, 20 December 2012 (UTC)

One thing I forgot: It'd be great if you could take this to the project chats in other languages so they also know what's going to happen. --Lydia Pintscher (WMDE) (talk) 21:25, 20 December 2012 (UTC)

Hi Lydia, thanks for this great news! --Kolja21 (talk) 21:28, 20 December 2012 (UTC)

Thanks for the info Lydia! I already informed everyone on the Bosnian wikipedia via our village pump. Keep us updated about the progress! -- Edinwiki (talk) 21:52, 20 December 2012 (UTC)

• That would be great if we had any idea what exactly is going to happen in the Hungarian Wikipedia on January, 14.--Ymblanter (talk) 02:29, 21 December 2012 (UTC)

Language links shown on that Wikipedia in the sidebar are going to come from here and the wikitext instead of only from the wikitext. Editors there can remove them from the wikitext if they wish to do so. They will also be shown edits from here in their recent changes for articles that concern their Wikipedia. --Lydia Pintscher (WMDE) (talk) 07:25, 21 December 2012 (UTC)

And who is it who changes interwiki links to correct Wikidata-ID's? Bots?--Stryn (talk) 10:58, 21 December 2012 (UTC)

That's not necessary. Say you have an article on the Hungarian Wikipedia about Water. And there exists an item in Wikidata about Water. If that item in Wikidata has a link to the Hungarian article then everything is fine. The article in the Hungarian Wikipedia will get its language links from Wikidata automatically. The language links that exist in the wikitext of the article in the Hungarian Wikipedia can be removed by the editors there if they wish to do that. If someone wants to write a bot to remove them and the Hungarian community agrees to this then that is possible too. --Lydia Pintscher (WMDE) (talk) 11:09, 21 December 2012 (UTC)

(BK) There is no need to add wikidata-ID to huwiki. This is done by die wikibase cleint extension. My bot is prepared to remove local langlinks, but we'll have some problems with pages changed in between. Merlissimo (talk) 11:12, 21 December 2012 (UTC)

Ok, it's nice, that Wikidata-links comes automatically :) --Stryn (talk) 11:22, 21 December 2012 (UTC)

 Info Automatic import of huwiki pages is nearly completed. There are some (~2000) moved or deleted pages that will be solved automatically. But most missing pages must be imported manually (~4000). Wikidata:Wiki import task force/huwiki lists huwiki pages which must be imported manually. Currently this report only contains big problems. I'll add minor problems later (because i think most depends on the big problems and my be imported automatically after they are solved). So your help is needed. It would be great if import is finished before huwiki wikidata client is enabled. Merlissimo (talk) 11:12, 21 December 2012 (UTC)

I will be here as a liaison. If there is a message to translate, tell me. Thanks a lot to Merlissimo and others who did this tremendous work for huwiki's interwikis. You may also be interested in hu:Wikipédia:Wikidata/1. fázis/Hibabejelentő where the problems will appear (if any), although it is primarily for developers. Bináris (talk) 14:15, 21 December 2012 (UTC)

Will there be - beside the language links (maintained by Wikidata) - a link from Wikipedia to the Wikidata item? This would be useful. (I like the way the Dutch Wikipedia puts their main links on the top right: nl:Berlijn). --Kolja21 (talk) 14:45, 21 December 2012 (UTC)

You can always create a link from a Hungarian Wikipedia page (if the page uses sitelinks) by using [[d:Special:ItemByTitle/huwiki/{{PAGENAME}}]]. There are some ideas about linking to Wikidata, but if you want an additional link anywhere (like in the toolbox) just say so and we help you with the code. Jeblad (talk) 15:27, 21 December 2012 (UTC)

It'll be great to have this rolled out on an actual Wikipedia. I can help with some of the unimported hu links. Ajraddatz (Talk) 18:34, 21 December 2012 (UTC)

@Jeblad: We could add the Wikidata ID to de:Vorlage:Normdaten, since it is a kind of authority control, but I think the best way would be if every article has an automatic generated link back to Wikidata showing the item ID Q... --Kolja21 (talk) 19:45, 21 December 2012 (UTC)

• Is Wikidata:Wiki import task force/huwiki automatically updated to remove conflicts that have been solved, or do we remove them manually once the conflict is fixed? Regards, — Moe Epsilon 21:50, 21 December 2012 (UTC)

according to Wikidata:Wiki_import_task_force: Lists are updated twice a day by MerlBot. Signalwerk (talk) 23:14, 21 December 2012 (UTC)

I'm not sure hat I understand: How will you be able to get iw-links from Wikidata using MediaWiki syntax? Or will every page just automatically search for the page title on Wikidata and add those iw-links? πr² (t • c) 22:47, 23 December 2012 (UTC)

It happens automatically, yes. --Lydia Pintscher (WMDE) (talk) 08:37, 24 December 2012 (UTC)

If a Wikipedia project enables the WikibaseClient extension the sitelinks from Wikidata will be injected into all pages unless some or all links are explicitly turned off in individual pages by {{noexternallanglinks}} or overridden by locally defined langlinks. That means everything works as before until the langlinks is removed from the articles. At that point sitelinks from Wikidata will be the sole source for such links. There are also some special ways to use the parser function so the extension stays away from some languages at a page. That are the weird cases where some language version splits (other will then merge) an article. For more about this see the usage section of WikibaseClient and especially how noexternallanglinks works with and without additional arguments. Those cases are pretty rare (less than 1‰) and the manual (bot?) work doesn't really pose any big problems. Over time I think the different projects will align the articles so the problem will go away. Jeblad (talk) 04:09, 25 December 2012 (UTC)

Thanks for the explanation but I still don't get the point how the author of an article will manage the langlinks in future. There must be some link back to Wikidata. Why all langlinks should show up as identical if they aren't? In the future there will be two kinds of langlinks: Wikidata-langlinks and additional langlinks. Both could be shown on one list but, for example, the Wikidata-langlinks first (with a small note "Wikidata"). --Kolja21 (talk) 13:35, 25 December 2012 (UTC)

In Wikipedia all the langlinks in the wikitext will be removed, and if there is no {{noexternallanglinks}} in the wikitext then the sitelinks from Wikidata is injected instead. The net result is that the links will show up as usual, but the maintenance of langlinks in the Wikipedia-projects will go away. All (or most) maintenance will instead be in Wikidata. In short; no langlinks-mess in the bottom of the articles even if the links shows up as before. Take a look at Supetar at Test2, the links are there in the rendered version, but if you take a closer look at the wikitext there are no langlinks as the links are sitelinks and comes from Wikidata. At the Main Page at Test2 there is a {{noexternallanglinks:*}} which blocks use of all sitelinks, and you will then have full control by adding langlinks as usual. The site test2.wikipeidia.org is a testsite that thinks it is English Wikipedia, the scary thing is what will happen when we use a real site like Hungarian Wikipedia. At least it seems like we need a better description how {{noexternallanglinks}} works and how langlinks are replaced with sitelinks. Jeblad (talk) 19:28, 25 December 2012 (UTC)

And what if someone is writing a new article like the disambiguation page Jakeš? How will he know that Wikidata even exists? Should he add the langlinks like before and later a bot will do the cleanup? --Kolja21 (talk) 22:42, 25 December 2012 (UTC)

There will be a link to Wikidata and sitelinks should be maintained here. Initially a lot of users will not be aware of Wikidata and how it works, but I think that will be a short transition. Jeblad (talk) 00:15, 26 December 2012 (UTC)

Thanks! I'm really looking forward to Jan. 14th. Cheers --Kolja21 (talk) 01:49, 26 December 2012 (UTC)

Adding new interwiki links

Since prospectively all interwiki links will have to be added here, I have the following question. I often create new articles in English Wikipedia which from the beginning have a Russian interwiki link (often this is the only interwiki link, i.e. the same article prior to my creation existed in Russian Wikipedia and nowhere else). Imagine now I have to go to Wikidata to add the link to my newly created article. (I guess I need to do it, since no bot would guess what the hell is the article about). However, here Cyrillic search does not work (I consistently get empty search results even if the Russian entry exists on Wikidata). What should I do then?--Ymblanter (talk) 02:26, 26 December 2012 (UTC)

We need to get the search to work as it should, that is the search box in the upper right corner. Right now it seems like it doesn't work in at least some cases. That could be because the old entries are not reindexed as they should, but it could also be due to other reasons. Some weeks ago we shifted from using our internal terms index to using Lucene search, and it seems like things started to fail around the same time. My guess is that the index in Lucene is incomplete.

My idea of how this should work is that the drop down box should contain the labels and possibly descriptions for a search matching labels and possibly aliases. The last entry in the list should be an ordinary search on all content in the items, including the terms, like on Wikipedia. If a namespace are given the search should be directed to that namespace only, and if that namespace holds wikitext the search should be like it is on Wikipedia. If the namespace is property or query (future stuff) it should be like items in the mainspace but only list entities from the property or query namespace.

There is also an API module for connecting two articles and creating an item in the process if it does not exist already. That API module is only intended as a stop gap measure until most of the items are built with more or less complete sitelinks.

As a next step I would really like some kind of fuzzy search, and I would also really like the fuzzy search to use transliterated terms. That is really outside the present project, but I think it would make it a lot easier to connect items across different language editions and especially when those editions use different scripts. Perhaps we need a special page for this kind of data mining as it will be somewhat weird, you do a fuzzy search for a transliterated label, alias or sitelink but exclude the originating edition. Seems to me it should be a special page. Jeblad (talk) 23:37, 26 December 2012 (UTC)

Yes, I think it would be good to have the search like this. But as soon as the existing search is not flawless, we probably need to have an option of keeping iw links in the articles for newly created articles and then collecting them by bot.--Ymblanter (talk) 08:25, 27 December 2012 (UTC)

Untranscluded RFAs

Category:Requests for permissions - I see at least two RFAs that were never transcluded. What should be done about this? --Rschen7754 19:17, 26 December 2012 (UTC)

I'd ask whether they are still interested in becoming sysop here on their talkpage. Vogone (talk) 22:44, 26 December 2012 (UTC)

Yeah, just drop them a note telling them their requests for adminship wasn't transcluded and asking whether they want to restart it. Regards, — Moe Epsilon 23:55, 26 December 2012 (UTC)

I only see one untranscluded, and I've left the user a message. Ajraddatz (Talk) 00:57, 27 December 2012 (UTC)

Yes, I've deleted the other one as nonsense ;-) Vogone (talk) 01:00, 27 December 2012 (UTC)

By the way, as far as I know requests for translationadminship were never transcluded like RfAs. They were always made on-page. How should we handle this if the candidate still wants to be elected as translationadmin? Regards, Vogone (talk) 01:05, 27 December 2012 (UTC)

I'd say just keep it where it is. I'm pretty sure there have been a couple of transcluded ones anyways. Ajraddatz (Talk) 01:08, 27 December 2012 (UTC)

It doesn't matter that much but there weren't any transcluded requests ;-) Greetings, Vogone (talk) 12:10, 27 December 2012 (UTC)

Deletion gadget broken

The deletion gadget keeps inserting two Qs, resulting in a broken link. Would it be possible to fix this? --Rschen7754 23:54, 28 December 2012 (UTC)

I've changed the code. There shouldn't be two Qs now. Regards, Vogone (talk) 01:46, 29 December 2012 (UTC)

Thanks! --Rschen7754 01:47, 29 December 2012 (UTC)

Localization to Hungarian

Before turning on the Wikidata client extension the Hungarian localization should be finished. They are available at repo, client and lib. Before doing the localization the glossary should be localized to Hungarian so the naming is consistent. It is available at Wikidata:Glossary/hu, that is here. Jeblad (talk) 01:55, 29 December 2012 (UTC)

wikidata @ wikizine

Hi, I am writing in Wikizine an item about Wikidata. Could someone check it out of what wrote (and have taken over from talk pages here) is correct please? Thanks, It is at meta:Wikizine/EN2012-133#Technical_news. --Walter (talk) 21:36, 28 December 2012 (UTC)

Thanks to Jeblad. This is done. --Walter (talk) 17:51, 29 December 2012 (UTC)

North Frisan problem

There is going to be a problem with the North Frisan (frr.wiki) articles to some extent. They have articles of the same topics in different dialects. For the article on a basic geometric circle, they have frr:Krais (Geometrii) in the Söl'ring dialect, and they have frr:Kreis (geometrii) for the Öömrang dialect. How are we going to fix this kind of conflict? Regards, — Moe Epsilon 04:07, 29 December 2012 (UTC)

The only thing that I've managed to think of is them having "dialect disambiguation" pages that we would use here.  Hazard-SJ  ✈  05:07, 29 December 2012 (UTC)

I guess I can start these kinds of disambiguation pages, but there is quite a few different dialects:

• frr:Kategorie:Öömrang Artiikel (largest (main) dialect I can place on the main data entry)
• frr:Kategorie:Mooring Artiikel‎
• frr:Kategorie:Friisk Artiikel‎
• frr:Kategorie:Nordfriisk Artiikel‎
• frr:Kategorie:Fering Artiikel‎
• frr:Kategorie:Gooshiirder Artiikel‎
• frr:Kategorie:Halifreesk Artiikel‎
• frr:Kategorie:Halunder Artiikel‎
• frr:Kategorie:Karhiirder Artiikel‎
• frr:Kategorie:Wiringhiirder Artiikel‎

That could end up being a lot of articles, but there's currently no way to link the same language twice, so there's almost no other alternative but a disambiguation. If the dialect has one article for one topic, obviously that one would make the main data entry, but if there is two of the same article, the Öömrang dialect is the largest of these and would be the best target if two dialect topics exist. Regards, — Moe Epsilon 05:27, 29 December 2012 (UTC)

"Disambiguation" is irritating because these are full articles. We have the same problem in all Wikipedias. For example: es:Alcalde (mayor) is in German de:Bürgermeister, but the German Wikipedia has also an article about the Spanish term de:Alkalde. --Kolja21 (talk) 03:34, 30 December 2012 (UTC)

Yes, they are, though that is slightly more solvable than this because it's spread across a couple different languages. The frr wiki having ten dialects on the same domain provides for a more interesting challenge. Regards, — Moe Epsilon 11:52, 30 December 2012 (UTC)

Featured articles and good articles

Hello, would local communities that do so have to continue manually recognizing articles as featured or good, for example, the English Wikipedia with the Link FA and Link GA templates, or would it be better for us to centralize that too?  Hazard-SJ  ✈  04:37, 29 December 2012 (UTC)

I've been wondering about this for a while... --Rschen7754 04:42, 29 December 2012 (UTC)

Initially we discussed a kind of badges to attach to the sitelinks. Apart from some rudimentary experimentation we did not complete the implementation and later on I removed the defunc code. The idea was to somehow mark the links, and possibly also open for other maintenance badges. It could be something like the aliases but instead attached to the sitelinks. If we use a badges-analogy it would be simple to implement a limited set of values, but if we use textual tags it would be easier to extend the concept. It should be fairly simple to extend the sitelinks with additional info, but there are a lot of places in the code that needs updating so it will be some work to do. An other way to solve this is to simply define this as a kind of property of the item itself, then we will have a working solution as soon as statements works. That creates a conceptual problem, because the quality of some random article is not part of the external entity as such. Jeblad (talk) 05:37, 29 December 2012 (UTC)

Given that "featured article" status in this kind of thing are properties of the Wikipedia article, not the Wikidata item, it would seem to make sense to store this information in the Wikipedia article, and somehow transclude it in Wikidata and Wikipedia interwiki. Would that sort of thing be a medium term possibility ?--Zolo (talk) 08:37, 29 December 2012 (UTC)

It would be nice to centrilize the information about FA and GA articles. Centralizing them would lead to less maintainance and less edits than there currently is. With that being said, this feature is in my opinion of an medium importance.--Snaevar (talk) 14:56, 30 December 2012 (UTC)

Just FYI: fi-wiki, da-wiki and sv-wiki has also "promising articles". --Stryn (talk) 16:16, 30 December 2012 (UTC)

There are a couple of bugs for this; Bug 36735 - The API does not set badges, and [Bug 40810 - Featured and good article badges Bug 40810] - Featured and good article badges. The older one was a bug for later before it was changed and then even marked as a duplicate for the newer one. The general discusion should be about link attributes, what we need and how we can implement it. Jeblad (talk) 16:29, 30 December 2012 (UTC)

Yes it would be a great feature. Beside maybe Wikidata could centralise also other maintenance tags as Promotional content/non neutral, curent event ones, and so one... it could be useful. Otourly (talk) 16:39, 30 December 2012 (UTC)

Some early experiments to start with?

Hello all, I am just peeping into this Wikidata chat hall for the first time. Hope my ignorance and naivity will be tolerated.

I am pretty eager to see how Wikidata plans its approach to such a great engineering task that can change the very way humans live on this planet.

On browsing through several pages here, I have not been able to see if there is already a long term database/structure road map for the project. If it is all right for me to suggest, here are a few of my cents:

Although an integrated database structure may take much more time, discussions, foresightedness and standardisations we could start doing something right away. An example is creating very large translation tables (of single words) between different language Wikipedia.

To begin with, we could define some fundamental data objects and elements such as 'PERSON', 'PLACE', 'BOOK' etc. They may have some essential attributes to begin with which can be easily populated by semi-automated means (by users and bots using various Wikis, infoboxes etc.) These attributes can have sub-attributes and so on.

An example:

• PERSON
  • PERSON/ID (MasterKey Index)
  • PERSON/NAME1.en (In English)
  • PERSON/NAME.de (German)
  • PERSON/DateofBirth.ce (Christian Era)
  • PERSON/SEX

etc. (In this example, a PERSON is a unique person on whom there are many articles and who is referred in many articles (in many language Wikipedias For eg: Obama).

Such a data can then be populated easily. It can also be immediately put to use in various language Wikis, The Wikipedia articles themselves can have a new kind of element (like a template or magic word) that actually pulls out the data from a common single universal data server and replace the (hitherto static) words. This can work both within the normal text of an article or within a template or infobox.

Advanatges:

1. Contributors can start doing some work immediately.
2. The work such gathered can be put to use immediately with minimal development time.
3. Early users will find it very useful. They will capture the entire idea of Wikidata soon and this will catapult Wikidata's prospects rapidly.
4. The data can be automatically reused and re-packaged for future databases with higher structural complexities.
5. This will prompt lots of fresh ideas, bring out indications of possible bottlenecks and some prior insights to the actual long-term database design.

Hope you understand what I mean. I am ready to clarify more if needed.

Viswaprabha (talk) 12:37, 30 December 2012 (UTC)

Take a look at m:Wikidata, and then m:Wikidata/Notes/Data model primer and even m:Wikidata/Data model. The planned solution is a schema-less implementation of linked data, centered around collections of statements about the entities. Statements can hold properties that have some information about the entity, like population numbers for a city. Jeblad (talk) 16:35, 30 December 2012 (UTC)

I also hope phase 2 will start soon and softly (step by step), for example with authority control. (See also: Wikidata:Infoboxes task force) --Kolja21 (talk) 19:29, 30 December 2012 (UTC)

Discussion launched on Commons about Wikidata

I launched the discussion on Commons about the interest of linking our "creators" to wikidata, and get automatic wikilinks eventually - I think it may interest the community there.

For now, I'm trying to systematically add all new Commons "creators" to wikidata (all those with wikilinks of course), so that an easy link would be possible :)

I also think that it would be interesting to be able to add links to Commons Categories (that correspond to the items created), so it would be easier to find the concordance.

What do you think ? --Hsarrazin (talk) 14:05, 30 December 2012 (UTC)

Hi Hsarrazin, I think it would be a good idea to add Wikidata. You should post a comment on commons:Template:Authority control. --Kolja21 (talk) 19:39, 30 December 2012 (UTC)

Bot documentation

Hi. Is there some page I can read on the specifics of bot running on Wikidata? How do I handle entity names, how are interwiki links introduced, how to choose the names of the entries on each page, what new API calls exist etc.? Thanks.--Strainu (talk) 21:13, 30 December 2012 (UTC)

First you can see the page Wikidata:Bots; there are only seven running Bots. Otourly (talk) 21:53, 30 December 2012 (UTC)

There is a page mw:Extension:Wikibase/API (a little outdated) on how the API is supposed to work, and the APIs selfdocumentation for Wikidata. The selfdocumentation is different for test repo (staging, no experimental features) and dev repo (bleeding edge, with experimental features). All of these are for the repo, the client has no special API calls. Don't experiment with new bots on Wikidata.org, use the test server. Jeblad (talk) 04:21, 31 December 2012 (UTC)