Wikidata:Contact the development team/Archive/2015/06

From Wikidata
Jump to navigation Jump to search

Q305267

Someone can check Q305267? Last 3 claim haven't edit button. Tested with IE and Crhome, logged and unlogged. Console said something about "Not implemented yet". --ValterVB (talk) 07:57, 16 May 2015 (UTC)

Yes. --GZWDer (talk) 11:46, 16 May 2015 (UTC)
Same happens on Q278553. GZWDer, what do you mean with "yes"? "Yes" to what? Candalua (talk) 13:12, 18 May 2015 (UTC)
"Yes" means I can reproduce it.--GZWDer (talk) 05:00, 19 May 2015 (UTC)
Another case is Q221787. Candalua (talk) 13:48, 18 May 2015 (UTC)
I have now fixed them all by reverting edits by samoabot. Something was wrong with that data. The issue we now have is that the statements with deleted properties can't be removed. We'll look into that more. @Aude: see this please. Might be relevant for the fixes you're working on. --Lydia Pintscher (WMDE) (talk) 16:09, 18 May 2015 (UTC)
I took the freedom to revert your edits but changed the precision of retrieved (P813) in the source from second to day. --Pasleim (talk) 16:56, 18 May 2015 (UTC)

Lydia, again a similar problem on Q250668: last 3 claims don't have edit button and I get the "Not implemented yet" message in console. Candalua (talk) 08:54, 27 May 2015 (UTC)

@Pasleim: Same case, could you try to fix this again? Matěj Suchánek (talk) 10:26, 27 May 2015 (UTC)
done--Pasleim (talk) 20:56, 28 May 2015 (UTC)

Update: Katie is working on fixing the underlying issue of those values not being editable. Hopefully done this sprint. --Lydia Pintscher (WMDE) (talk) 12:30, 3 June 2015 (UTC)

Cloning statements references

In this item Edoardo Gioja (Q19983446) I added one reference for occupation (P106) now I must copy it for all the statements, date of birth, place of birth, date of death etc.. it is a big waste of time it is possible fix it? --Rippitippi (talk) 00:26, 27 May 2015 (UTC)

Work with a bot or wait until this bug is solved. Snipre (talk) 08:31, 27 May 2015 (UTC)
@Rippitippi: https://www.wikidata.org/w/index.php?title=Q19983446&type=revision&diff=219743786&oldid=219609819 -- VlSergey (gab) 09:00, 27 May 2015 (UTC)
@Vlsergey: this could be a workaround but is it inaccurate since Dizionario Biografico degli Italiani (Q1128537) is a book instead the references are from website version --Rippitippi (talk) 23:52, 27 May 2015 (UTC)
@Rippitippi: Well, one can replace it like Encyclopædia Britannica Online (Q5375741) and Encyclopædia Britannica (Q455) -- VlSergey (gab) 06:38, 28 May 2015 (UTC)
Hi Rippitippi and all others interested in this feature: I have created a userscript and will make it a gadget soon which solves this issue: User:Bene*/DuplicateReferences.js. Just add importScript( 'User:Bene*/DuplicateReferences.js' ); // [[User:Bene*/DuplicateReferences.js]] into your common.js to try it out and leave feedback on the tool's talk page. If most of the issues have been resolved I will make it an official gadget. -- Bene* talk 09:53, 30 May 2015 (UTC)
Please let us know here when you make it a gadget. And thanks--Oursana (talk) 10:47, 30 May 2015 (UTC)
I'm now thinking that it is perhaps better to make it a gadget now than in a week because then all users of this tool have to change their common.js and preferences to use the gadget instead of the user script. If there don't appear any issues today I will perhaps move it into the MediaWiki namespace. -- Bene* talk 11:18, 30 May 2015 (UTC)
@Bene*: Great gadget. Thanks! — Ayack (talk) 11:29, 30 May 2015 (UTC)
@Bene*: Thanks it is perfect --Rippitippi (talk) 16:46, 30 May 2015 (UTC)
@Bene*: Nice! The only thing I would change is the text layout I think. The links look a bit out of place. --Lydia Pintscher (WMDE) (talk) 12:33, 3 June 2015 (UTC)

patrol status after undo deletion

After deleting and undo a talkpage, the status goes (so I see on browser down right) from not patrolled to patrolled. Is that ok so? Conny (talk) 10:06, 29 May 2015 (UTC).

I don't think we're doing anything special there on Wikidata. Should be the same behavior as on other wikis. If not please let me know. --Lydia Pintscher (WMDE) (talk) 12:37, 3 June 2015 (UTC)

Property suggestions: when typing a property name, the corresponding label should appear before aliases

To test, please set your interface to English and use an item that doesn't have any of the properties already defined.

  • typing "location" should lead to "location" (P276), not "coordinate location". (try on Q33970, or remove "location" on Q557951 to try.)
  • typing "child" should lead to "child" (P40), not "father" (P22).

It's annoying in the first case, but in the second case, one risks to enter a value for the wrong property, as both have the same datatype.

Nice poem about it at Wikidata:Project_chat/Archive/2014/08#type_.22father.22_to_enter_the_name_of_a_child.3F ;) --- Jura 05:39, 31 May 2015 (UTC)

Hmm that's indeed bollocks but I think the reason there is that we simply have way more usage of "coordinate location" than "location". The same is probably true for father/child. This leads to a higher correlation of coordinate location/father with whatever properties already exist on the item. So the suggestion system assumes that you are much more likely to mean the one that is used more. I think that is the right thing to do most of the time. We're also thinking about phabricator:T89661. --Lydia Pintscher (WMDE) (talk) 12:45, 3 June 2015 (UTC)
I think it's the sensible thing to do for values. When selecting values for properties this works as it should. It's just not ideal when selecting properties. --- Jura 12:48, 3 June 2015 (UTC)

Using wikidata items within wikipedia

Is there anyway to allow the use of wikidata items and label system within wikipedia projects, rather than just here and between wikimedia projects. Doing so would mean that we could have article titles without disambiguations in the title. For a long running example, who gets the unambiguated title "Georgia" has been a matter of antagonism in English Wikipedia from the start of the project, with supporters of both the country and US state (Georgia(Q230) and Georgia(Q1428)) wanting the unambiguated title for themselves, if it is possible to integrate the wikidata database with wikipedia article titles then both of these could have an unambiguated title (with the item numbers hidden from user). Editors would still use the disambiguated titles which would redirect to the correct article. Users searching for an article would be shown the label, as happens here, to enable them to find the article they are looking for.--KTo288 (talk) 09:47, 31 May 2015 (UTC)

Many (English) Wikipedia articles use w:Template:About instead making the primary page the disambiguation page specifically because one particular topic bearing the title is substantially more notable than the others, and directing users to that page makes more sense than assuming the need for disambiguating first. Additionally, ENWP has discussed in the past hiding or otherwise differently styling (shrinking, fading) the disambiguating parts of titles, but it's never gone anywhere. Hiding the bracketed content completely would make internal and external linking much more difficult. --Yair rand (talk) 21:35, 2 June 2015 (UTC)
I am not sure how that would work. We can't serve different content under the same URL. And I don't think people will be too happy with taking over the IDs from Wikidata into the Wikipedia article URLs. --Lydia Pintscher (WMDE) (talk) 12:48, 3 June 2015 (UTC)

Unsupported calendar models

So, I don't see a bug for supporting calendars other than the Julian or Gregorian calendars on either the development plan or on Phabricator. Is this planned? If so, has there been a data model for other calendars decided upon, and could statements using it be added directly via the API? --Yair rand (talk) 22:21, 2 June 2015 (UTC)

  • @Yair rand: half year ago it was possible to set non-standard calendar model via API, but Wikidata UI can't display such value (neither most of LUA modules). Just note that setting calendar model shall not change date value (i.e. value must be in Proleptic Gregorian). -- VlSergey (gab) 22:43, 2 June 2015 (UTC)
    I'm not sure what you mean by that last statement. All values are to be stored as Proleptic Gregorian, even in other calendars that can't be reliably converted? Or are those calendars just not going to be supported? --Yair rand (talk) 22:47, 2 June 2015 (UTC)
    @Yair rand: yes, according to current Wikidata data model all values are to be stored as Proleptic Gregorian, even in other calendars that can't be reliably converted. This was has pro- and contra-, but don't ask me how to translate Middle-earth (Q79734)'s dates into Proleptic Gregorian :-) -- VlSergey (gab) 22:55, 2 June 2015 (UTC)
    So I, technically, can already today add "februari 30, 1712" according to the "Swedish calendar", if I only know which Gregorian date that corresponds to? -- Innocent bystander (talk) 07:10, 3 June 2015 (UTC)
    @Innocent bystander: yes. Some gadgets may help you to enter this date (with autoconvertion). Let me know if this isn't theoretical task and you really need it at your local wiki, I can add Swedish calendar support to WEF gadget. Anyway, you will also need representation support in your infoboxes. -- VlSergey (gab) 07:39, 3 June 2015 (UTC)
    Swedish calendar (Q1130275) Yes, this is really needed, this issue rises a lot of hot debates on svwp, so we need support for it during the years involved. There is maybe some unresolved issues, if dates between the Gregorian calendar was introduced until 1700 also should be regarded as "Swedish", when the only difference is that we still used Julian calendar here. The dates from 1712-03-01--1753-12-17 are again true Julian, but maybe in Sweden also regarded as "Swedish" since they were different from the Central European. The Gregorian calendar was introduced 1753-03-01 here. The main difference is that it was not the same as neither Gregorian or Julian between Feb 1700 and Mar 1712. I do not think you have to hurry, very few users are involved in Swedish and Finnish history here on WD. N.B. it is only what happend inside Sweden and Finland that this matter for. Gustavus Adolphus of Sweden (Q52938) died in Germany, so his date of death should be according to the calendar used in Germany. -- Innocent bystander (talk) 08:06, 3 June 2015 (UTC)
We're currently undertaking a review of all things calendar. There are quite a few issues based on misunderstandings on several sides and we need to fix them. I hope we have the analysis completed in the next week or two and can then get back to everyone with findings and recommendations. --Lydia Pintscher (WMDE) (talk) 12:50, 3 June 2015 (UTC)

Bezeichnungsglättung

Falls bei der Eingabe ein Leerzeichen am Anfang oder Ende steht, wird dieses derzeit entfernt. Könnte in gleicher Form ein doppeltes Leerzeichen im gesamten Bezeichnungstext entfernt werden? Kann jemand eine Abfrage machen, wie viele Bezeichnungen derzeit doppelte Leerzeichen ( ) haben? Dankend, Conny (talk) 07:46, 31 May 2015 (UTC).

Hast du ein Beispiel? Ich würde gern nachvollziehen wo die herkommen und dann schaun wie wir damit umgehen. --Lydia Pintscher (WMDE) (talk) 12:46, 3 June 2015 (UTC)
Maybe this answers your questions/comments. http://quarry.wmflabs.org/query/3881 --- Jura 13:23, 3 June 2015 (UTC)
Thanks! I think one of us 3 is confused at least :D What Conny is talking about is double spaces inside a description. I checked a few and I can't find that in the items in your list. Am I missing something? --Lydia Pintscher (WMDE) (talk) 13:58, 3 June 2015 (UTC)
Must be me. It shows what isn't mean to exist (leading space) ;) To get what Conny seems to be looking for, you can change the query to use "%  %" instead. --- Jura 15:22, 3 June 2015 (UTC)
Thanks! :) I'll have a look. --Lydia Pintscher (WMDE) (talk) 15:14, 4 June 2015 (UTC)

Impressed!

I made some code in a Module to learn of the value of Arbitrary Access. The result can be seen in Talk:Q499464. It illustrates the results of some elections to the municipal counsil in Båstad Municipality (Q499464), Sweden (Q34). I am not only impressed by the value of Abitrary Access (I knew it would be great.) But I expected that my large graph would take much more power from the hardware! But it looks like it would easily allow me to add every election since 1919 to 2015. The corresponding template in sv:Båstads kommun sometimes makes the load of the page slow, even if that template contains less information, since it isn't including votes received (P1111). 

NewPP limit report
Parsed by mw1018
CPU time usage: 0.569 seconds
Real time usage: 0.644 seconds
Preprocessor visited node count: 556/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 58058/2097152 bytes
Template argument size: 0/2097152 bytes
Highest expansion depth: 3/40
Expensive parser function count: 25/500
Lua time usage: 0.441/10.000 seconds
Lua memory usage: 4.79 MB/50 MB

-- Innocent bystander (talk) 14:12, 4 June 2015 (UTC)

Oh wow. Thank you so much for doing this and taking the time to write here. The example is pretty awesome. It'd be interesting to see how well it holds up with bigger items. I suspect the size of the loaded items is the determining factor. --Lydia Pintscher (WMDE) (talk) 14:42, 4 June 2015 (UTC)

Curlie ID (P998) for Stavropol (Q5206)

Value of Curlie ID (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

I have tried to create links between different pages on Wikisource by the help of edition or translation of (P629) and has edition or translation (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

Tracked in Phabricator
Task T101694

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

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}} => 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). [1]. 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. 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

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 P357 (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 [2] 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

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)

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)

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)

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)

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

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

Sorry if this has already been noted, but there appears to be something wrong with coordinates conversion: Porta Augusta (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

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)

The interwiki links for 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

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)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team/Archive/2015/06&oldid=1102549277"