Shortcut: WD:DEV

Wikidata:Contact the development team

From Wikidata
Jump to: navigation, search


Contact the development team

Wikidata development is ongoing. You can leave notes for the development team here, on #wikidata connect and on the mailing list or report bugs on Phabricator. (See the [1].)

Regarding the accounts of the Wikidata development team, we have decided on the following rules:

  • Wikidata developers can have clearly marked staff accounts (in the form "Fullname (WMDE)"), and these can receive admin and bureaucrat rights.
  • These staff accounts should be used only for development, testing, spam-fighting, and emergencies.
  • The private accounts of staff members do not get admin and bureaucrat rights by default. If staff members desire admin and bureaucrat rights for their private accounts, those should be gained going through the processes developed by the community.
  • Every staff member is free to use their private account just as everyone else, obviously. Especially if they want to work on content in Wikidata, this is the account they should be using, not their staff account.
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2015/07.


dmoz (P998) for Stavropol (Q5206)[edit]

Value of dmoz (P998) for Stavropol (Q5206) can't be saved because of length limitation. The value to be saved is "/World/Russian/%D0%A1%D1%82%D1%80%D0%B0%D0%BD%D1%8B_%D0%B8_%D1%80%D0%B5%D0%B3%D0%B8%D0%BE%D0%BD%D1%8B/%D0%95%D0%B2%D1%80%D0%BE%D0%BF%D0%B0/%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F/%D0%A1%D1%83%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D1%8B_%D0%A4%D0%B5%D0%B4%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%B8/%D0%A1%D1%82%D0%B0%D0%B2%D1%80%D0%BE%D0%BF%D0%BE%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D0%B9_%D0%BA%D1%80%D0%B0%D0%B9/%D0%A1%D1%82%D0%B0%D0%B2%D1%80%D0%BE%D0%BF%D0%BE%D0%BB%D1%8C/". I believe limitation (400 chars) is too strict. -- VlSergey (gab) 16:37, 6 June 2015 (UTC)

It seems you were able to add it now? --Lydia Pintscher (WMDE) (talk) 10:45, 8 June 2015 (UTC)
@Lydia Pintscher (WMDE): well, i managed to add it using incorrect UTF-8 encoding of URL's, making ID 3 times shorter. This can be considered as workaround for this particular case. But we have other topic with even longer DMOZ IDs and such workaround won't be enough. -- VlSergey (gab) 11:47, 8 June 2015 (UTC)
Yeah I understand. I am just worried that if we make the field too long that it'll be used for storing longer free-text basically which I'd really like to avoid tbh. So I am trying to weight the benefit against the drawbacks before increasing the limit. Do you know how many cases we are talking about? How much would it need to be increased? Also I am not sure if we can change the length of different datatypes independently. I need to find out. If we can and the issue is mostly happening with identifiers then we could increase the limit for that and it would address my worries. --Lydia Pintscher (WMDE) (talk) 14:28, 10 June 2015 (UTC)
@Lydia Pintscher (WMDE): how about 4095 chars? It's more than enought for any general-purpose URL/ID field I can imagine. -- Vlsergey (talk) 16:59, 21 June 2015 (UTC)
We discussed this today. We can raise the limit for identifiers as soon as we have the separate datatype for it. I'll create a ticket for it in the next days. --Lydia Pintscher (WMDE) (talk) 14:59, 23 June 2015 (UTC)

Interwiki by the help of Statements[edit]

I have tried to create links between different pages on Wikisource by the help of edition or translation of (P629) and edition(s) (P747). It should be possible to link "svwikisource:Vårt land" with all of "enwikisource:Our Land (Runeberg)", "fiwikisource:Maamme", "fiwikisource:Maamme (1857)", "fiwikisource:Maamme (Kiljander)" and "fiwikisource:Maamme (Schröder)". Theoretically it works, the code can identify all four related pages on fiwikisource. But the code fails to transclude all four of the if-interwiki-links into the pages correctly. -- Innocent bystander (talk) 07:27, 7 June 2015 (UTC)

Sorry, there is a local bugfix in svwikisource that makes it possible to create multiple interwiki to one single project. When I installed the css-classes related to that bugfix, my problem was solved. -- Innocent bystander (talk) 10:07, 7 June 2015 (UTC)

Undo edits via API[edit]

It seems to me that it's no longer possible to undo edits via API in the main namespace. Undoing edits via API in other namespaces is still possible. --Pasleim (talk) 11:37, 7 June 2015 (UTC)

Hmm. Do you get a 'no-direct-editing' error? If this didn't happen before then I am guessing this is due to a change in core! ·addshore· talk to me! 10:49, 8 June 2015 (UTC)
I have created phab:T101694 ·addshore· talk to me! 11:25, 8 June 2015 (UTC)

Special:ItemByTitle in Scribunto[edit]

Is there any support for Special:ItemByTitle in Lua? -- Innocent bystander (talk) 11:03, 8 June 2015 (UTC)

In Lua, you can currently only get an arbitrary item if you know the id of that item. However, I'm not sure what the usecase would be of ItemByTitle in lua because titles are not stable and moving a page would possibly break all lua modules using that article. Usually arbitrary access is only useful to access items which are the values of statements of the current item. In this case you already know the item's id. -- Bene* talk 11:25, 8 June 2015 (UTC)
Not yet. See phab:T74815. --Yair rand (talk) 12:48, 8 June 2015 (UTC)
Innocent bystander, phab:T74815 is exactly about this (by the way, any updates about the timeline, anyone?). I don't agree with Bene*: accessing an item by site link will be essential, because generally on a project you don't deal with QIDs but with page names. Imagine that you have a list of people, each with their respective page in your project, and you want to show the place of birth of each person: you only have the page titles, if you want the QIDs you have to find them out manually... which is not practical. Then of course, when moving a page one should always know what one is doing (in general, not just when Wikidata is involved). Candalua (talk) 13:01, 8 June 2015 (UTC)
Agree! What I am worried about, is that many Wikipedia-users never will understand the magic of item=QNNNNNNN in Module:Wikidata as it looks today. If it was possible to add the title of the page in the templates instead, the WP-users would feel much more comfortable when dealing with it. Another question is how "expensive" such a function would be? -- Innocent bystander (talk) 13:11, 8 June 2015 (UTC)
(edit conflict) I don't think that's a good idea. What if the list contains a person which does not have an article yet? What if a page gets moved? As I wrote above, I don't want Wikipedias to use Q-ids and no Wikipedian should ever have to deal with those random numbers. However, we should try to find better ways of resolving those ids. One way would be to use Queries to generate lists automatically. This avoids both dealing with ids and dealing with page names. In the meantime we might consider to implement something like ItemByTitle but it won't be the definite solutio. -- Bene* talk 17:42, 8 June 2015 (UTC)
@Bene*: Both Qid and Pid can change, and they are still used in Module:Wikidata. The label of Properties can be used in the the #property-parser and that is even easier to change than to move a page on Wikipedia. We still do not know how powerfull the Queries will be. As far as I have understood, they cannot sort out items that have an enddate in the qualifiers. If I require a list of all independent states, it will include the kingdom of Mercia in the list. -- Innocent bystander (talk) 18:54, 8 June 2015 (UTC)
Queries will for sure be able to filter out statements with some qualifiers. Furthermore, there is a ticket on phabricator which will make properties' aliases also unique so one can query for those aliases as well (and make the old label an alias if the label is changed). I understand why you want and need a method to get the entity related to a wikipage and I don't oppose this. I just want to point out the risks that come with such a feature. -- Bene* talk 19:00, 8 June 2015 (UTC)
But it's not a new risk. It already exists in the current system. The main risk I want to know about, is if such a tool would be expensive. Today, very expensive templates are used to get updated population of villages in articles about something related. Some articles on svwp cannot be edited today if you do not have a very good IP-connection. I do not want to see one very expensive solution be replaced by something which is also expensive. -- Innocent bystander (talk) 06:59, 9 June 2015 (UTC)
Then the key could be the title/date combination. I don't know if it's possible but maybe the parser can do some switching to the ID by a special syntax, just like ~~~~ for example. TomT0m (talk) 17:40, 8 June 2015 (UTC)
I don't really understand what you mean, TomT0m. -- Bene* talk 17:43, 8 June 2015 (UTC)
Mmm then we should integrate a Wikidata search in the interface that searches by Wikidata label. But it's not really a problem that we have several ways to refer to an item, actually the more we are the most people we will touch. What's important is that in the end we refer to the same item. But anyway Wikidata's deeper integration into Mediawiki is the way to go. TomT0m (talk) 17:47, 8 June 2015 (UTC)
A Mediawiki function would be nice too. {{#qid:Berlin}} => Berlin (Q64) (when used on enwiki) or {{#qid:Berlin|site=enwiki}}. --- Jura 07:05, 9 June 2015 (UTC)

Hey :) Can you provide a specific case where you'd make use of this please? --Lydia Pintscher (WMDE) (talk) 14:25, 10 June 2015 (UTC)

Sure, try to find the items that go with those on Special:WhatLinksHere/Q20054355 without checking them one by one. --- Jura 14:33, 10 June 2015 (UTC)
Sorry. I'm being really dense here :/ What is the end result of it? What would for example a Wikipedia reader see? Or is it for maintenance? Or? --Lydia Pintscher (WMDE) (talk) 14:48, 10 June 2015 (UTC)
(edit conflict)One example is in article sv:Kristianstads kommun, to get information about the village sv:Vittskövle, Kristianstads kommun. You can see that information is summoned by the help of templates with the name sv:Template:Stat today. (That is a very expensive use of templates in this page.) I know that I can get such information with the help of Arbitrary access and the qid for the village, but I'm afraid that it can be difficult for the average WP-user to understand how and why (s)he should add something as strange as item=Q1968940 to a template, when (s)he is used to just add village=Vittskövle, Kristianstads kommun. There is always a threshold to understand new technology, and if we can simplify the interface for the WP-users, there will be more use of Wikidata in Wikipedia. -- Innocent bystander (talk) 14:49, 10 June 2015 (UTC)
Aha! Thank you! Ok that makes sense. I now see what Bene* is worried about. If the article is moved the call suddenly either points to the wrong item or none. I think that's a fair point. I however also see the usability issue you describe. I wonder how much of an issue still remains when we have the ability to build lists/tables/... in Wikipedia articles based on queries to Wikidata. --Lydia Pintscher (WMDE) (talk) 15:09, 10 June 2015 (UTC)
Yes, queries will be a good thing, but sometimes those lists will be much longer than is desired. sv:Lista över fornlämningar i Kramfors kommun only lists a small fraction of all cultural heritage sites within one municipality. The sum of all sites in all those lists on svwp makes less then 1 % of all of them, AFAIK. The sites in those lists are handpicked to fit Wikimedia Loves Monuments. -- Innocent bystander (talk) 15:39, 10 June 2015 (UTC)
That's a good point. @Bene*: I think it's ok to offer it. --Lydia Pintscher (WMDE) (talk) 14:38, 11 June 2015 (UTC)
I just tried the query which should lead to the list in the article you linked (sv:Kristianstads kommun#Tätorter). [2]. I wonder why there are more results than listed in the article. Do you have an idea?
As I said, in the short term it is ok to use the page title for identification but we should really use queries for such situations as soon as they are available as they are easier to update and maintain. -- Bene* talk 15:40, 11 June 2015 (UTC)
It's the time-perspective. Vanneberga (Q10712673) is no longer an urban area. -- Innocent bystander (talk) 15:57, 11 June 2015 (UTC)
Ah ok, that makes sense. So we still have to improve our data and add start/end date qualifiers to a lot of statements to make them useful for queries/lists. -- Bene* talk 16:20, 11 June 2015 (UTC)

I think we should offer mediawiki functions for more Wikidata ones. {{#label:Q64}} and {{#label:Q64|lang=en}} should work without LUA. --- Jura 18:25, 10 June 2015 (UTC)

Problem to add label in yiddish[edit]

A contributor tries to add a label in Yiddish to the property title (P1476) but the system doesn't allow the saving of the edit. I tried to perform the same action and have the same problem.

The error message provides by the system says:

Property P357 already has label "título" associated with language code pt-br.
Property P357 already has label "título" associated with language code gl.
Property P357 already has label "titel" associated with language code sv.
Property P357 already has label "શીર્ષક" associated with language code gu.
Property P357 already has label "title" associated with language code en-gb.

Can it be a problem of font ? Or something else ? Thanks Snipre (talk) 15:36, 9 June 2015 (UTC)

Can you give me the Yiddish label please? I'll try to reproduce it then and see where the issue lies. --Lydia Pintscher (WMDE) (talk) 14:20, 10 June 2015 (UTC)
@Lydia Pintscher (WMDE), Redaktor: I don't know the correct label in yiddish but I tried in both latin and yiddish using this word טיטל. I took it from obsolete property (OBSOLETE) title (use P1476, "title") (P357). Hope this is the correct term. Snipre (talk) 18:06, 10 June 2015 (UTC)
Mpfh. Ok I tried to reproduce this now. The behaviour is correct in some way. There are two issues:
  • That it got into this situation in the first place. It should not be possible to get to the point where two properties have the same label.
  • It's probably best not to show you the error and prevent the edit when the conflict is in a language that you are not editing right now. --Lydia Pintscher (WMDE) (talk) 14:53, 11 June 2015 (UTC)
I wonder how these labels made it into the system but iirc this started happening after [3] got deployed. While this change should only change the capitalization check, perhaps the check on the term_text did not work at all and allowed also duplicate values. We have to check for all properties if they are editable and otherwise remove the conflicting labels/replace them with some appendix to make the properties editable again. -- Bene* talk 16:27, 11 June 2015 (UTC)
I've now created phabricator:T102148 to resolve this. --Lydia Pintscher (WMDE) (talk) 17:11, 11 June 2015 (UTC)

Bug[edit]

Torre de' Picenardi (Q20064978) the same wikilink is on Torre de' Picenardi (Q42224) I think we need a check in all DB --Rippitippi (talk) 01:50, 10 June 2015 (UTC)

The links are different, it's just that one redirects to the other. - Nikki (talk) 02:22, 10 June 2015 (UTC)
Merged. --ValterVB (talk) 17:00, 10 June 2015 (UTC)
Ops I'm sorry I don't see redirect link --Rippitippi (talk) 17:43, 10 June 2015 (UTC)

The Massacres of the Triumvirate The Massacres of the Triumvirate (Q19904594)[edit]

by described at URL (P973) I'd like to add also the Japanese version http://www.louvre.fr/jp/oeuvre-notices/《三頭政治下の虐殺》 which is not accepted. Oursana (talk) 11:04, 10 June 2015 (UTC)

I just tried to add it and it worked. Do you remember the error message you got? --Lydia Pintscher (WMDE) (talk) 14:17, 10 June 2015 (UTC)
Did you copy the URL as pasted here, or the escaped URL that some (most?) browsers will give you when copying the link? If I use the URL as pasted here it says Malformed URL: http://www.louvre.fr/jp/oeuvre-notices/《三頭政治下の虐殺》 - Nikki (talk) 14:38, 10 June 2015 (UTC)
Ah yeah. That is to be expected at least because of the space. URLs should be escaped. --Lydia Pintscher (WMDE) (talk) 14:49, 10 June 2015 (UTC)
Thanks to both of you. I do not know what escaped Url means and how to get it. I am using Safari and I tried to add the Url as posted here. Oursana (talk) 14:53, 10 June 2015 (UTC)
There are certain characters that should not be in URLs. Spaces for example. Escaping means turning them into a special character sequence that is allowed. Take a look at the URL as it is in the item now. I don't know how that works on Mac and Safari but for me Chrome just handles that. --Lydia Pintscher (WMDE) (talk) 15:11, 10 June 2015 (UTC)
Why don't we just escape the urls when they get entered? -- Bene* talk 21:17, 10 June 2015 (UTC)
Why should this be done, Bene*? --Succu (talk) 21:26, 10 June 2015 (UTC)
Because it currently requires them to be escaped even though we can't guarantee that users will/can input an escaped URL. Not all browsers prefer escaped URLs over unescaped ones and not every URL will be copied from the address bar or a link on the page even in browsers which do prefer escaped URLs. - Nikki (talk) 02:17, 11 June 2015 (UTC)
Lydia: There isn't a space in the URL. I assume you're talking about "《" - that's a single fullwidth character. - Nikki (talk) 02:17, 11 June 2015 (UTC)
Hah! Yes. Same thing applies though I assume. --Lydia Pintscher (WMDE) (talk) 14:54, 11 June 2015 (UTC)

Wiktionary interwiki links[edit]

What is your opinion about Task 1 and Task 2 in Wikidata:Wiktionary/Development/Proposals/2015-05? Is it good? Is it feasible?

Same questions about Option B, where the pages in Wiktionary's main namespace are linked through the standard Wikidata Sitelink system (currently used in Wikidata for Wikipedia, Wikisource, Wikiquote...).

Visite fortuitement prolongée (talk) 20:30, 10 June 2015 (UTC)

I am happy with the proposal and Daniel didn't see any major issues with it either. With main namespace pages you mean the pages about words? I'd prefer the automatic way and only use the items for the remaining pages. --Lydia Pintscher (WMDE) (talk) 14:56, 11 June 2015 (UTC)
"With main namespace pages you mean the pages about words?" →‎ Maybe. See wikt:en:Wiktionary:Namespace. Visite fortuitement prolongée (talk) 20:33, 11 June 2015 (UTC)

sitelinks not being shown on Special:Recentchanges[edit]

Since some days, I cannot see any interwiki links on any Recent Changes pages, on any project I tried so far (en.pedia and many wikipedias and wikisources). I only see the interwikis if they are still present locally (such as on en.wiktionary or ca.wikisource). --Candalua (talk) 08:42, 15 June 2015 (UTC)

Special:RecentChanges (Q6293548)? -- Innocent bystander (talk) 14:05, 16 June 2015 (UTC)
That one. The sitelinks from that item used to appear on Special:Recentchanges, but not anymore. Any ideas? Candalua (talk) 14:39, 16 June 2015 (UTC)
Maybe check the content of MediaWiki:Recentchangestext at the local wiki. The template inside may supress all links and only keep some local ones. Matěj Suchánek (talk) 14:51, 16 June 2015 (UTC)
No, what I see is that the interwikis suddenly stopped working, for that particular special page, on *many* projects, and the local MediaWiki:Recentchangestext pages weren't changed at all! I don't understand how a template can "suppress" all links... @Lydia Pintscher (WMDE):, did something change in the code recently? Candalua (talk) 15:31, 16 June 2015 (UTC)
It seems that no language links are shown on any special page anymore, even not on Wikidata. Afaik we didn't change anything in Wikibase, maybe a change has been made in core that doesn't allow sitelinks on special pages anymore? -- Bene* talk 16:30, 16 June 2015 (UTC)
I opened phab:T102939 --Candalua (talk) 10:38, 18 June 2015 (UTC)
Ok, actually there was already phab:T102888 (and I even searched before opening a new task...) Candalua (talk) 10:41, 18 June 2015 (UTC)

Textarea bug[edit]

Whenever I press save and produces an error (due to edit conflict or otherwise), the textarea of the property value is set to disabled. I have to manually remove disabled="" from the HTML textarea tag to modify the value and save again. I am using Firefox on Windows 7. —Wylve (talk) 13:01, 16 June 2015 (UTC)

I think fixing phab:T89784 also fixes this. Sjoerd de Bruin (talk) 13:17, 16 June 2015 (UTC)
Yeah that should be the same thing. Thanks for linking. --Lydia Pintscher (WMDE) (talk) 14:22, 17 June 2015 (UTC)

Wrong coordinates conversion[edit]

Sorry if this has already been noted, but there appears to be something wrong with coordinates conversion: Q3399001 (Q3399001) has latitude = 43.8394 which is equal 43 50' 21.83", but it is shown as 43°50'24"N. --Zolo (talk) 16:21, 16 June 2015 (UTC)

Had wrong precision. --JulesWinnfield-hu (talk) 20:33, 16 June 2015 (UTC)
Thans, but even so, shouldn't it have given 50°22 rather than 24 ? --Zolo (talk) 07:16, 17 June 2015 (UTC)
43°50'24" comes from 43.84. I don't know what should it be when the stored precision doesn't match the input precision. Neither is good or wrong. --JulesWinnfield-hu (talk) 11:07, 17 June 2015 (UTC)

P1186[edit]

Could you please add - with the help of a bot - to all items using the P1186 (MEP directory identifier) the source website http://www.europarl.europa.eu/meps/ as a qualifier.

While doing this, it might be also helpful to do a normal plausibilty check for names/ID combination and find out about missing items.

Currently I'm migrating the identifier from dewiki to Wikidata. In dewiki an external source is obligatory for using WD-data.

Thanks a lot. Cheers. -- Wikidatafan (talk) 20:09, 16 June 2015 (UTC)

Create a request at WD:Bot requests. Matěj Suchánek (talk) 20:16, 16 June 2015 (UTC)
@Wikidatafan: Please have a look at Wikidata: Sources in order to have a common way to source data. And in order to be able to create in the future a correct reference in WP using WD, the best is to describe for URL the link using reference URL (P854), the language used in the webpage using language of work (or name) (P407) and the title of the webpage using title (P1476). The publication date of the webpage publication date (P577) or the date retrieved (P813) when the webpage was checked is good too in order to compare if the current version is similar to the one at the moment of the statement creation. Snipre (talk) 14:16, 17 June 2015 (UTC)

interwiki link problem on Polish Wikipedia[edit]

The interwiki links for hydrogen peroxide (hydrogen peroxide (Q171877)) are not showing on the Polish Wikipedia despite the correct article pl:Nadtlenek wodoru being given on Wikidata. Jason Quinn (talk) 10:30, 19 June 2015 (UTC)

They show up for me. It might be a caching issue. Can you add "?action=purge" to the URL and load the article again? --Lydia Pintscher (WMDE) (talk) 10:37, 19 June 2015 (UTC)
The previous IP edit was me. I've been experiencing an intermittent auto-logout bug on Wikidata for about a year or so. I changed it to me signature. Anyway, adding "?action=purge" fixed the problem. Thank you. Jason Quinn (talk) 16:28, 19 June 2015 (UTC)
PS Any idea why this was occurring for me? I had never visited that page before. Jason Quinn (talk) 16:29, 19 June 2015 (UTC)
There is an additional cache that is kicking in that is independent of you. That's probably what happened here. --Lydia Pintscher (WMDE) (talk) 19:05, 19 June 2015 (UTC)

Ranking labels[edit]

Is there any plan to rank labels? Some of the aliases are really deprecated, while other labels can be used in all languages because they are titles of a particular edition (for instance Las habitaciones de atrás (Q14624872)), it would be nice to rank such labels as "preferred" and display it in all languages when there is no other label.--Micru (talk) 09:08, 21 June 2015 (UTC)

There are no plans for it currently. I don't want to say it'll never happen but it's not something I consider a priority at this point :) --Lydia Pintscher (WMDE) (talk) 13:51, 22 June 2015 (UTC)

Numbers with units[edit]

It's been several months since I've heard anything on this - has there been any progress? --Rschen7754 15:33, 21 June 2015 (UTC)

User interface work is still needed. We had no UI developer for a while. We just got a new one so this will pick up speed again now. --Lydia Pintscher (WMDE) (talk) 13:52, 22 June 2015 (UTC)
@Lydia Pintscher (WMDE): Do you want to include the problem of the uncertainty at the same time ? Snipre (talk) 18:51, 22 June 2015 (UTC)
I wanted to but I've realized that this will just delay it even further. So we'll tackle it but probably not in the first version. --Lydia Pintscher (WMDE) (talk) 15:11, 23 June 2015 (UTC)
@Lydia Pintscher (WMDE): Ok thanks. But it can be good before launching the first version of the Numbers with units datatype to see if it will be a good solution to already include in the code fields to store the uncertainty. Snipre (talk) 07:37, 27 June 2015 (UTC)

Please can we have automatic labels and descriptions based on transcriptions and statements[edit]

There are a lot of languages which do not have descriptions yet. I did a search for "Peri" and it threw up a load of items with no descriptions in English, many with no labels in English. As I went through these adding labels and descriptions I noticed some patterns:

Lots of places and people in Italy, Indonesia, Estonia, Romania and Turkey named Peri. (plus a lot of wikinews articles in Serbian about Katy Perry or Kejti Peri as they say in Serbian). In pretty much every case the best label in English is the label in the language where the original wikipedia article is (most of these are in one language only). There is a concept "Peri" but it is already linked to "Fairy" and isn't a problem. I didn't find one item (so far - I'm only half way through and then there all the "La Peri" items) where you couldn't just reuse the label in the original language. While some could be translated even those cases tended to be proper names(Peri Photography Centre in Turku, Finland) so they could just as well stay untranslated.

  • Please modify the search function to show the label in another language if there is no label in English.
  • Please modify the item interface to show the label in another language (or labels in other languages) as a proposed label with a simple one click to accept workflow.

For labels I have not found a single case where the label could not be easily rendered from a few basic statements. Instance of and Country; Occupation and Country of Citizenship etc. By adding these basic statements I could be adding labels in a hundred languages instead of just in one.

  • Please replace the descriptions with descriptions which are automatically generated from statements
  • Where statements are missing change the wikipedia mobile interface to invite users to add basic statements.

This will needs some thought as to the workflow -

  • Can we have a way for wikidatans to develop and edit the flow diagram to guide wikipedia mobile users and respond to their answers?
Filceolaire (talk) 23:07, 22 June 2015 (UTC)
We maybe also have to agree about how we in the best way choose good labels and descriptions to Wikisource-items. Items like Q20203267 (Q20203267) and Epistles of Fredman (Q5383621) tend to have very simlair labels and descriptions. Different descriptions makes its easier to search, but it does not make it easy to manually read a statement. Imagine in edition(s) (P747) in Bible (Q1845) 400 claims, having the same label: "The Bible". -- Innocent bystander (talk) 07:04, 23 June 2015 (UTC)
The search function already uses your fallback languages (babel) in the search function now. Sjoerd de Bruin (talk) 07:23, 23 June 2015 (UTC)
Does babel:de-0/fr-0/ru-0/ja-0/zh-0 add more fallback-languages? -- Innocent bystander (talk) 08:21, 23 June 2015 (UTC)
Depends on what you see here, try it. Sjoerd de Bruin (talk) 10:54, 23 June 2015 (UTC)
Ok, it worked (at least in that page). In real life, I have seen content in fi and fit, even if that wasn't on that page. - Innocent bystander (talk) 11:10, 23 June 2015 (UTC)
My language is English then pt, fr, de, it, es, nl as babel languages but I don't see labels from these in search. I would love to see fallback labels in these languages but I would also like to see fallback labels in any other language if these were missing. Filceolaire (talk) 17:48, 23 June 2015 (UTC)
As Sjoerddebruin said language fallbacks are already happening in many many places. You just can't see them because English is the last in all fallback chains. I am trying to find ways to improve this but it is not easy. We can't do fallbacks that are specific to a user for example as that kills caching. Doing specialized fallbacks for certain topics is also something I don't want. --Lydia Pintscher (WMDE) (talk) 13:36, 1 July 2015 (UTC)
multiple items with similar labels and statements in one language are something that autolabels can detect and address. Editions of the bible can be distinguished by their date of publication for instance. All those Wikinews articles in Serbian about Katy Perry (there are about a dozen of them) could be distinguished by their publication date too if that statement was added and the label got auto updated when the statement was added. (Q20203267) could get the label "Fredmans epistlar " from the Swedish label with the description <edition or translation of (P629):Epistles of Fredman ( Q5383621), language of work (or name) (P407):Swedish (Q9027)> from the statements. My guess is that auto descriptions are easy for 95% of all items and for 99% of the items actually accessed. As the algorithm for labels is improved these percentages will I hope get even better. Filceolaire (talk) 17:48, 23 June 2015 (UTC)
I am not sure the "publication date" is good to add in all Wikisource-items, since the pages on Wikisource sometimes is regarded as a work separate from the one published on paper. Should a new date then be added every time somebody edit the page, or should we choose the first edit of the page? And often is there no corresponding WP-items for the Wikisource-items, and the WS-items then carry more information than it should. :) -- Innocent bystander (talk) 18:35, 23 June 2015 (UTC)
Note that I didn't suggest adding a publication date to the wikisource translation example above - I suggested the description read <translation of:original name><language:Language of the translation>. That should work 99% of the time I think. Filceolaire (talk) 02:08, 27 June 2015 (UTC)

Century dating—localization[edit]

Please see WD:Project chat#Century dating—localization.

In short: in some cases, certain dating (for date of birth, date of death, what have you) is only available at the century level (e.g., "12th century"). At the moment, when a Wikipedia uses {{#property: ...}} to pull information like that, the result comes out as "12. century", which is a bit of a strange hybrid of German and English forms. Other wikis might like this to come out in other forms:

  • lawiki: "saeculum XII" (would be fine, though ablative "saeculo XII" would be even better)
  • frwiki: "XIIe siècle"

Is this possible, either natively or at translatewiki? After all, if the date of involved is, say, 15 January 1208, it correctly comes out on lawiki as 15 Ianuarii 1208.

Please note: at least at lawiki, Lua has not been implemented, and it's not clear whether it can be any time soon. (Small wiki, limited numbers of people able to help on it, etc.) We'd far prefer an approach native to the interface, if possible. Thanks. StevenJ81 (talk) 18:27, 26 June 2015 (UTC)

Can you please clarify something for me? When you look at the date here on Wikidata it is correct for you? When you display it on a Wikipedia it is shown in which language? Or is it just the formatting that is wrong? --Lydia Pintscher (WMDE) (talk) 13:20, 1 July 2015 (UTC)
Formatting is odd, sample at Property_talk:P569#Date_output. --- Jura 13:29, 1 July 2015 (UTC)
There was some other oddity with the input form discussed in the misnamed Project chat thread:
an input of "15. century" results in 1500-01-01 +/- 100 yr (Special:Diff/145618879. (Q2161498) seems better. --- Jura 13:36, 1 July 2015 (UTC)
Great. Thank you. I opened phabricator:T104447. --Lydia Pintscher (WMDE) (talk) 13:51, 1 July 2015 (UTC)
That ticket is only about the display of the date on Wikipedia (etc) when using data from Wikidata and not about the display on Wikidata itself, right? From what I can tell, Wikipedia, Wikisource, etc, are displaying the date in exactly the same way as Wikidata itself, which in all the cases I've tried is wrong. I added a date to Wikidata Sandbox (Q4115189) and tried changing the interface language on Wikidata and previewing {{#property:P571|from=Q4115189}} on several Wikisources. The result:
  • Wikidata in English: "15. century" - wrong, should be "15th century" (English doesn't use a dot for ordinal numbers)
  • English Wikisource in English: "15. century", as above
  • Wikidata in German: "15 century" - wrong, should be "15. Jahrhundert" (German does use a dot for ordinal numbers and the text isn't translated)
  • German Wikisource: "15 century", as above
  • Wikidata in Latin: "15. century" - wrong, should be "saeculum XV" or at least "saeculum 15" (Latin doesn't use a dot for ordinal numbers, the text isn't translated and the number is in the wrong position)
  • Latin Wikisource: "15. century", as above
  • Wikidata in Japanese: "15. century" - wrong, should be "15世紀" (Japanese doesn't use a dot for ordinal numbers, the text isn't translated and there shouldn't be a space between the number and word)
  • Japanese Wikisource: "15. century", as above
- Nikki (talk) 14:34, 1 July 2015 (UTC)
An option to generate an ISO looking output would be nice too. --- Jura 15:04, 1 July 2015 (UTC)

Replacing statements[edit]

I have today replaced some statements, that were wrong. (They were user-mistakes imported from Wikipedia, why I did not marked the old statements as deprecated.) I had some severe troubles with this in IE11/W7. It demanded several reloads of the page to be able to edit the page. -- Innocent bystander (talk) 10:40, 1 July 2015 (UTC)

What sort of trouble were you having? - Nikki (talk) 12:36, 1 July 2015 (UTC)
The browser stalled and the statements did not change as intended. -- Innocent bystander (talk) 13:49, 1 July 2015 (UTC)
There were some issues we fixed very recently where removing the last reference of a statement could cause this. The fix will be here in a few days. I hope that fixes your issues. If you still see it next week please let me know. --Lydia Pintscher (WMDE) (talk) 13:54, 1 July 2015 (UTC)