Shortcut: WD:DEV

Wikidata:Contact the development team

From Wikidata
Jump to: navigation, search

Project
chat

Administrators'
noticeboard

Development
team

Bureaucrats'
noticeboard

Translators'
noticeboard

Requests
for permissions

Requests
for deletions

Property
proposal

Properties
for deletion

Requests
for comment

Partnerships
and imports

Interwiki
conflicts

Request
a query

Bot
requests

Development plan Usability and usefulness Status updates Development input Contact the development team
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 list of open bugs on Phabricator.)

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 2018/02.


Hard to read titles[edit]

This began just recently. Near the top of each page are the clickable buttons that begin with "Project page", "Discussion", "Read", "Edit" and so on. In the past, these buttons stretched across the top in a straight line (and sometimes still do, eg, this edit page). Recently, there appears to be something like a "line break" between the "Discussion" and "Read" buttons. To be clear, the first two buttons are on one line, and the rest of the buttons, rather than continuing on the same line, go down on the next line, which obscures most of the page title from my view. Also to be clear, this happens ONLY when my browser is set to "largest" font, which I use all the time to make pages easier to read; smaller font settings do not present this problem. Not sure what to do about this nor where to go with this problem, but it's exceedingly tedious to have to decrease the font just to read the page title, then increase the font again to read the page. Please help, and thank you in advance!  Paine Ellsworth  put'r there  13:23, 29 November 2017 (UTC)

Hello @Paine Ellsworth: and thanks for your feedback. To investigate more, I'll need some information about the browser you use (Chrome, Firefox, etc.) and the version. I would also like to know if Javascript is disabled in your browser? Thanks a lot, Lea Lacroix (WMDE) (talk) 14:16, 29 November 2017 (UTC)
Thank you, Lea Lacroix (WMDE)! I first noticed this not long ago while I used IE v.11 to edit. I've checked it in Chrome v.62, and the "Read" button begins to wrap when the font size is increased to 125%. In Firefox v.53, I can't get a percentage; however, the "Read" button wraps after I've zoomed in three times. I've done some more checks, and this appears to be a normal occurrence that has been recently adjusted here on Wikidata. In other words the "Read" button is designed to wrap when the font is increased to a certain size. So Wikidata must have been recently changed to make the "Read" button wrap at a smaller font size, which is now within the range of my "largest" setting on IE v.11. Just so you know, this doesn't happen when I edit Wikipedia, only when I read and edit Wikidata. Oh! and my Javascript is enabled. Thanks again for your response!  Paine Ellsworth  put'r there  01:53, 30 November 2017 (UTC)
Another clue... when I increase the font size on Wikipedia enough to make the buttons wrap to the next line, only the very tip of the top of the article/page title is obscured. Here on Wikidata, almost the entire page title is obscured, and I can see only the very bottoms of the letters of the page title.  Paine Ellsworth  put'r there  02:09, 30 November 2017 (UTC)
I dug into this issue and believe it is a very old bug in the Vector skin. You can reproduce this issue on all pages (on all wikis) that are protected and can not be moved. In these cases the right-most tab next to the search box is the watch-star. Try to zoom in on these pages (or just narrow your browser window very much) and you will experience the same issue. I submitted a patch. see gerrit:394349. --Thiemo Mättig (WMDE) 17:52, 30 November 2017 (UTC)
Thank you, Thiemo Mättig (WMDE)! While this may very well be a very old bug, and while I do hope that your bug fix will handle it, let me say again that this is a very new problem for me. I have read and edited Wikidata for a long time, and it has only been recently that the "Read" button started wrapping down to the next line and almost completely covering the page title. Yes, you can make this happen on any Wiki just by zooming in enough; however, it has only recently begun to happen to me while using IE11 set to its "largest" font setting. Perhaps just a week or two ago, the same "largest" font setting produced all the buttons appearing on the same line together, so I still suspect that it was a recent software change and only on Wikidata. Thanks again for your help!  Paine Ellsworth  put'r there  06:21, 1 December 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── There is a new head scratcher for all you wonderful overworked developers... I just renamed a page on Wikipedia and discovered an interesting anomaly. When I got to the point where I had to check and edit the Wikidata page, Q5172800, I clicked the link and got the same problem described above, ie, the "Read" button and everything following it was wrapped to the next line. The left edge of the "Read" button was just under the right edge of the "Discussion" button. After editing, I zoomed out to 75% to double check the page. Then, when I zoomed back in to 100%, it was all good. All the top buttons were on the same line and, in fact, on my screen there was about a quarter-inch gap between the "Discussion" and "Read" buttons and all buttons were on the same line!!! I shall be scratching my head for a few days on this one, or at least until it can be explained. Why would the button line wrap when I first come to a Wikidata page, and then it is okay after I've zoomed out and back in again? Even this talk page performs the same way. Happy Holidays to all!  Paine Ellsworth  put'r there  03:16, 17 December 2017 (UTC)
PS. Also, if after all this I refresh the page, then it goes back to abnormal – the "Read" button and all after it wrap down to under the "Discussion" button again. Curiouser & curiouser. PS left by  Paine Ellsworth  put'r there  19:58, 17 December 2017 (UTC)

Status update[edit]

Does anyone have an update on the status of this gnarly problem?  Paine Ellsworth  put'r there  01:00, 9 January 2018 (UTC)

The challenge as described by me above has not been repaired, so I must continue to ask, "Why does this happen only on Wikidata and not on any other Wikimedia project where I edit?" I've been doing more work than usual on Wikidata recently, and it's really a pain not to be able to read page titles because the buttons wrap around and obscure them!  Paine Ellsworth  put'r there  23:43, 26 January 2018 (UTC)

I can only recommend you to report your problem via this form with a screenshot attached. Niether am I able to understand what kind of problem you have. Matěj Suchánek (talk) 16:11, 27 January 2018 (UTC)

Monolingual string language code ("cnr")[edit]

Please add "cnr" for Q7700307#P1705. I found it on the enwiki article about Montenegrin (Q8821).
--- Jura 11:54, 25 January 2018 (UTC)

I've created T185800 for this and patch will follow soon. But before it can be merged, approval by LangCom is needed. Mbch331 (talk) 10:30, 27 January 2018 (UTC)
@Millosh: what do you think ? It's a request for a language code at Wikidata (not a new wiki/interface language).
--- Jura 17:20, 28 January 2018 (UTC)
It's a valid language code (per [1]) and I see no reason why it shouldn't be added. --Millosh (talk) 19:14, 2 February 2018 (UTC)
Is that a personal statement or an official statement from the langcom? If the latter, please add a statement to phab:T185800. Mbch331 (talk) 20:15, 2 February 2018 (UTC)
@Mbch331: thanks for the patch. I think you can go ahead with it @Millosh: is the m:Language_committee#Current member knowledgeable about this language (or closely related ones). --
--- Jura 07:20, 3 February 2018 (UTC)
@Jura1: My part of the work is done anyway. I don't have the right to merge patches. That's only to the WDME devs. I'm just a volunteer dev that submits patches. Mbch331 (talk) 07:23, 3 February 2018 (UTC)

Isidore ID (P4491) datatype[edit]

Per Property_talk:P4491#Format, please convert to string datatype.
--- Jura 17:30, 30 January 2018 (UTC)

Hello Jura, I went through the existing discussions regarding the property. It seems to me that this is an external identifier, and I'm wondering why you would like to have it converted to a string? Lea Lacroix (WMDE) (talk) 10:33, 31 January 2018 (UTC)
Hi Lea, it seems to be a search string at the website rather than the site's unique identifier for a concept.
--- Jura 16:26, 1 February 2018 (UTC)
Converting this to a string datatype won't solve any of the issues with it; but would remove the formatter URL functionality. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:21, 2 February 2018 (UTC)
  • Given that the consensus under which the property was created was external-id, nobody pinged the people involved in that consensus and creators of the proposal and only one person wants the consensus of multiple people to be overturned, the development team shouldn't act on the wishes of a single person. ChristianKl❫ 21:48, 5 February 2018 (UTC)
    • The format problem was advertised on project chat and feedback was requested as for previous requests.
      --- Jura 07:46, 10 February 2018 (UTC)
  • @Lydia Pintscher (WMDE), Lea Lacroix (WMDE): how could we address the two points raised in the meantime? i.e. use for formatter url (if that is still an issue), placement in the second section (could be helpful for other properties as well).
    --- Jura 07:46, 10 February 2018 (UTC)
Hello, I'm trying to understand the issue here but I'm not sure what exactly needs to be solved from the Wikidata side.
Why not just remove the formatter URL statement? Lea Lacroix (WMDE) (talk) 13:15, 12 February 2018 (UTC)

Query Service issues[edit]

Could one of the team please cast an eye over recent discussions at mw:Talk:Wikidata query service - there seems to be a backlog needing attention.

Perhaps that page should have a soft-redirect to a page on this wiki? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 2 February 2018 (UTC)

Thanks for mentioning it, we will have a look. Lea Lacroix (WMDE) (talk) 08:58, 5 February 2018 (UTC)

Format for coordinates[edit]

It's a small issue, but nevertheless a quite annoying behaviour of the user interface: The easiest way to get good coordinates "by hand" is IMO to look something up on Open Streetmap and then copy/paste from the URL after you "center" on the exact location you want. In that URL, the coordinates are in the form "48.88609/8.99962". When pasting that to P625, e. g., one always needs to replace the / with a space to make this work. I know that in some formats, the slash is used to separate degrees from minutes, seconds, and so on, but wouldn't it be possible to first check if the entered text has exactly that format "decimal number/decimal number" (optionally with a "-" for negative numbers, but nothing else) and just accept that? --Anvilaquarius (talk) 18:08, 5 February 2018 (UTC)

Change P4793 to External Identifier[edit]

Shortly after this property (identifiers.org prefix (P4793)) was created it was discovered it did have a formatter URL and made sense as an external id property rather than a String. See the discussion at Property talk:P4793. Can we get this changed? Thanks! ArthurPSmith (talk) 21:42, 5 February 2018 (UTC)

  • More care should be given to identify the correct datatype before creating a property. The presence or absence of a formatter url shouldn't have any impact. If this should be changed, the datatype change discussion should seek more participation beforehand, e.g. by placing a notice on project chat. This shouldn't be changed merely because some users discussed it on some remote page.
    --- Jura 00:24, 6 February 2018 (UTC)
    • So do you object to this change? Do you have any reason related to the actual property itself? As to your claimed procedural grounds, all the people involved in the property discussion were pinged on the talk page. ArthurPSmith (talk) 16:30, 6 February 2018 (UTC)
  • Symbol support vote.svg Support conversion, ASAP (i.e. before the property is widely used). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:44, 6 February 2018 (UTC)
A ticket has been created. Lea Lacroix (WMDE) (talk) 13:12, 12 February 2018 (UTC)
  • Contrary to other requests, this change hasn't been advertised on project chat. Please seek input prior to converting. We don't want properties that end up created differently from proposals.
    --- Jura 17:11, 12 February 2018 (UTC)
    • As noted above "all the people involved in the property discussion were pinged on the talk page". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 14 February 2018 (UTC)
    • I've also noted the proposed change on Project Chat, though I was not aware this had been consistently done previously. Anyway, there seem to be no objections to the change from anybody. ArthurPSmith (talk) 16:01, 14 February 2018 (UTC)

Now done. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:52, 16 February 2018 (UTC)


I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:52, 16 February 2018 (UTC)

P2559 (Wikidata usage instructions)[edit]

Could we move Wikidata usage instructions (P2559) further up the display order please, to make it more prominent? People need to see this when they first see an item -- it's no good if it's hidden right down at the bottom.

has part (P527) could also benefit with being higher up -- ideally just after part of (P361). Thanks! Jheald (talk) 18:10, 6 February 2018 (UTC)

MediaWiki:Wikibase-SortedProperties. Matěj Suchánek (talk) 18:44, 6 February 2018 (UTC)
@Matěj Suchánek: Is that the order actually used in the presentation? Jheald (talk) 19:07, 6 February 2018 (UTC)
It is. Is there something that makes you think the opposite? For instance, today I made a change to have legal form (P1454) placed a bit higher and it works. Matěj Suchánek (talk) 19:15, 6 February 2018 (UTC)

Label Query service and property label[edit]

This query timeouts :

select distinct ?prop ?propLabel {
  ?item (p:P1766|p:P41|p:P4004) [?qual []] .
  ?prop wikibase:qualifier ?qual .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
} limit 1

Try it!

whereas this one seem to be pretty quick

select distinct ?prop ?propLabel {
  ?item (p:P1766|p:P41|p:P4004) [?qual []] .
  ?prop wikibase:qualifier ?qual .
  #SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
} limit 1

Try it!

so either there is a bug with the label service if you require labels for properties, or there is a big performance issue at the moment. author  TomT0m / talk page 12:47, 10 February 2018 (UTC)

@Smalyshev (WMF): Do you know anything about this? Lea Lacroix (WMDE) (talk) 08:35, 12 February 2018 (UTC)
  • Isn't this the same as usual?
    --- Jura 17:12, 12 February 2018 (UTC)
  • I would recommend using a subquery here:
select distinct ?prop ?propLabel {
  { SELECT DISTINCT ?prop {
   ?item (p:P1766|p:P41|p:P4004) [?qual []] .
   ?prop wikibase:qualifier ?qual .
  } LIMIT 1 }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!

Without it, label service probably does much more work than it should with the limit clause. Smalyshev (WMF) (talk) 07:15, 13 February 2018 (UTC)

@Smalyshev (WMF): You mean that it computes the label systematically and even if « ?propLabel » is not used at all in the query ? But most of the time the label is useless in the query ! This is suboptimal and not very user friendly to encapsulate the query just for that.
Then I guess it may be worth coding a data view that displays the label and compute it at viz time, or a js gadget that computes the label from the item identifier, according to the user language, without having to dealing with this on the query. author  TomT0m / talk page 14:51, 13 February 2018 (UTC)
@TomT0m: Not exactly, what I mean is I suspect the service is called on more than one property, even though limit 1 is set... It is not called if you don't have ?propLabel - it wouldn't know what to do then - but it is called when you have it, and probably more than once. If you wrap the inside query, it would be called only once. Also, I'm not sure you need distinct there - if you have limit 1, there's no chance of result having duplicates as far as I can see.
It is possible to do visualization mode that fetches labels at display time, and for big result sets it may be advantageous, but for small ones - not so sure, unless of course the query is suboptimal. But that's not a bad idea to have such mode, could you submit a phab task describing the idea? Smalyshev (WMF) (talk) 20:10, 13 February 2018 (UTC)
(1) That’s what I had in mind. Each time the query service « choose » a value for « ?prop » it computes the value for « ?propLabel », even if « ?prop » is discarded later. This is suboptimal as no « ?prop » value can be discarded through « ?propLabel », nor the value or any other variable in the query. (There is a functional dependancy between ?prop and ?propLabel, but nothing actually depends on the value of ?propLabel). Of course this is a very particular case that ?propLabel appears only on the projected variable, so it’s easy to see. Maybe if the query engine new that the « label » service result is functional (always has one and only one value xLabel for each ?x value) it could take advantage of this, for example through some kind of « constraint network » analysis, in constraint programming (Q528588) terminology. After some googling this seem to be described for example here. Although it’s a very particular case as usually we can’t be sure that there is a functional dependancy between two or more variables in graph patterns, except in a very few cases (for example we are sure that for every property we have 1 corresponding qualifier property, and the other way around). If he’s aware of this, the query engine could delay the computed of dependant values to the projection step. Maybe he does this but the « service » extension does not allow it to draw the conclusion he can.
I’ll file a ticket. author  TomT0m / talk page 12:29, 14 February 2018 (UTC) @Smalyshev (WMF): done. author  TomT0m / talk page 13:01, 14 February 2018 (UTC)

Wikidata:Article placeholder[edit]

The documentation should be updated. --Succu (talk) 23:10, 16 February 2018 (UTC)

Placement in identifier section[edit]

To detail a point brought up earlier, is it possible to add an option to place statements of a few properties (e.g. P1036, sample use: Q64#P1036) in the identifier section of pages (in the sample Q64#identifiers). Currently the sort seems to be based exclusively on datatype.
--- Jura 06:52, 17 February 2018 (UTC)

Why not simply change P1036 to external-id datatype? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 17 February 2018 (UTC)
Dewey Decimal Classification (P1036) is not an identifier but classifier. An identifier identifies an unique instance of class. In contrast, a classifier is used to tag all instances of a class. For example the code 813.54 means American narrative prose from 1945 to 1999. If P1036 is an identifier, we would add that code to the item about the class of American narrative prose from 1945 to 1999. But since P1036 is used as classifier, we add the code to all instances of that class. --Pasleim (talk) 14:10, 17 February 2018 (UTC)
would be more useful to have such classes on Wikidata and to use this property only on the class item. This would allow us to encode the class definition as statements in Wikidata and to infer instances automatically, for example with {{Implied instances}}. Or to add automatically the statements in the class item to the explicit instances of it without having to put the logic into the bot (or an out wiki inference rule). author  TomT0m / talk page 14:17, 17 February 2018 (UTC)
In one sense, certainly; but we have plenty of other external-id properties on Wikidata that "identify" classes of things. Do we really add Dewey codes to every item about a book with that code? The examples on the property page certainly do not suggest that. I also note that, in the property proposal, User:Merrilee of OCLC said "The Dewey identifiers are just that -- identifiers... I had an in depth conversation with the Dewey Editor, Michael Panzer, last week and this use of Dewey identifiers as free for all to use lines up with his understanding as well.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:17, 17 February 2018 (UTC)
  • I think the datatype of one or the other properties for which this can apply should be discussed elsewhere. I think there is a general need for this.
    --- Jura 08:24, 20 February 2018 (UTC)

Lua data access timeout errors[edit]

Over the last week or so I've seen pages start timing out that did not before, see Wikidata:WikiProject Roads/United States/Alabama and Wikidata:WikiProject Roads/United States/California. Is this just a temporary issue, or will this be permanent? --Rschen7754 21:30, 18 February 2018 (UTC)

Thanks for noticing. We will have a look. Lea Lacroix (WMDE) (talk) 08:14, 19 February 2018 (UTC)

Statement only visible to some users?[edit]

There's a strange edit war going on on Q1218, where two users (@Sokuya, Emir of Wikipedia:) have been repeatedly adding what appears to me to be a duplicate of the official website (P856) statement, and one editor (@Triggerhippie4:) has been reverting them. The edit summaries are quite confusing: (revert) "already here", (re-add) "I can't find it here. There is no official website parameter.", (revert) "there is", (re-add) "restore", (revert) "it's a duplicate. are you blind?", etc. Now, I can see what is either the original statement or some kind of technical glitch, but I don't know if that means much here. Is there any chance that something on this item is causing it to appear differently for different users? (Also, to the two users who don't see the statement, could you try to do a Ctrl-F search for "official website" if you haven't done so, just to make sure you didn't somehow both miss the statement? And to any passers-by, could you post whether the statement appears for you?) --Yair rand (talk) 17:59, 19 February 2018 (UTC)

I did search with Ctrl-F but didn't find it. Strangely it does appear on Q1218 when I scroll manually to find it. Somehow the "official website" string not found with Ctrl-F, very strange (I'm using Safari browser on Mac, I've a screenshot of it but don't know where to upload it so you can see it too). @Triggerhippie4: is right, it does appear. I can see it now when I scroll manually to find it. Sokuya (talk) 18:32, 19 February 2018 (UTC)
Using Firefox on Windows find works for me. Mbch331 (talk) 18:44, 19 February 2018 (UTC)
I can see it now. Prior to when I reverted I did do Ctrl-F and couldn't find it which is why I reverted. --Emir of Wikipedia (talk) 19:28, 19 February 2018 (UTC)
I was able to find it with Ctrl-F during the edit-war, and still can (Chrome, Windows). --Triggerhippie4 (talk) 00:03, 20 February 2018 (UTC)
I can find it without problem. A cache issue, maybe ? --Hsarrazin (talk) 08:32, 20 February 2018 (UTC)

Query timeout (Dutch descriptions)[edit]

There is a timeout problem at Wikidata:Request_a_query#People_without_Dutch_description brought up by Mbch331. Instead of pinging Lucas Werkmeister there, the formally better way to bring this up would be to post it here (sorry about it Lucas). It's a general request for maintenance ..
--- Jura 08:28, 20 February 2018 (UTC)

To break down the problem, why does this query work:
SELECT ?item WHERE {
  ?item wdt:P31 wd:Q5
  OPTIONAL {?item schema:description ?descnl FILTER((LANG(?descnl)) = "nl")   }
} LIMIT 1
Try it! but not this query:
SELECT ?item WHERE {
  ?item wdt:P31 wd:Q5
  OPTIONAL {?item schema:description ?descnl FILTER((LANG(?descnl)) = "nl")   }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "nl". }
} LIMIT 1
Try it! and not this query:
SELECT ?item WHERE { {
SELECT ?item WHERE {
 ?item wdt:P31 wd:Q5
 OPTIONAL {?item schema:description ?descnl FILTER((LANG(?descnl)) = "nl")   }
} LIMIT 1
} }
Try it! --Pasleim (talk) 10:20, 20 February 2018 (UTC)

I think there is a FILTER ( !BOUND(?descnl) ) missing in Pasleim's sample. It might be better to just experiment with Mbc331's sample and attempt to get it to work. Here there are two queries that don't work (and did work, or at least should work) and one that does.
--- Jura 10:57, 20 February 2018 (UTC)

#times-out even with hint
SELECT ?item ?itemLabel
WHERE
{ 
  # hint:Query hint:optimizer "None".  
  {
    SELECT ?item 
    WHERE
    {  ?item wdt:P31 wd:Q5
        OPTIONAL { ?item schema:description ?descnl FILTER(LANG(?descnl) = "nl")   }
        FILTER ( !BOUND(?descnl) )
    }
    LIMIT 1
    }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!


#times-out even with hint
SELECT ?item ?itemLabel
WITH
{ 
    SELECT ?item 
    WHERE
    {  ?item wdt:P31 wd:Q5
        OPTIONAL { ?item schema:description ?descnl FILTER(LANG(?descnl) = "nl")   }
        FILTER ( !BOUND(?descnl) )
    }
    LIMIT 1
} as %include  
WHERE
{
  # hint:Query hint:optimizer "None".  
  INCLUDE %include
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!

#works
SELECT ?item
WHERE
{ 
        ?item wdt:P31 wd:Q5
        OPTIONAL { ?item schema:description ?descnl FILTER(LANG(?descnl) = "nl")   }
        FILTER ( !BOUND(?descnl) )
}
LIMIT 5000

Try it!


Hope that clarifies it.
--- Jura 10:57, 20 February 2018 (UTC)

Formatter url and string datatype[edit]

A problem brought up further up on this page. It seems that this works sometimes and sometimes it doesn't. What's is the development status on this? I think ideally this would work as for "external id"-datatype when the url is set on a property.
--- Jura 08:30, 20 February 2018 (UTC)

Merging two items[edit]

Dear Wikipedia,

I've noticed that the En, Id, Sv entries for Mystic Ark are separated from the Ja entry for Mystic Ark. For some reason I can't merge the two items. I've forgotten my Wikipedia account, and I have little clue as to how to use Wikipedia beyond browsing, and I have other things to do...

https://www.wikidata.org/wiki/Q6948921

https://www.wikidata.org/wiki/Q11342060

They're about the same thing, so I think they should be merged.  – The preceding unsigned comment was added by 98.163.90.2 (talk • contribs) at 20. 2. 2018, 14:44‎ (UTC).

→ ← Merged Matěj Suchánek (talk) 15:33, 20 February 2018 (UTC)