Wikidata:Contact the development team/Archive/2018/01

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

Renaming namespaces and Wikidata

Hello! With regards to Wikidata:Bot_requests#Module_namespace_on_Javanese_Wikipedia_renamed,_but_Wikidata_still_displaying_old_one_and_links_are_broken maybe Wikidata should do it itself, or a maintenance script should be created to do this to avoid broken sitelinks when a namespace is renamed. What do you think? Regards, —MarcoAurelio (talk) 11:28, 13 December 2017 (UTC)

Also mentioned in Bot requests. Lea Lacroix (WMDE) (talk) 16:57, 13 December 2017 (UTC)
As mentioned on the bot request page it is easy enough to do with QuickStatements. I don't think we can spend more time on developing extra tools for this (afaik) rare case. --Lydia Pintscher (WMDE) (talk) 13:36, 14 December 2017 (UTC)
It's not that rare Lydia Pintscher (WMDE) that namespaces names change from time to time specially on some languages. I don't think we want broken links do we? What about a maintenance script so it can be run when it's required? —MarcoAurelio (talk) 09:17, 2 January 2018 (UTC)

MediaWiki:Mainpage/kv, MediaWiki:Mainpage/ba, MediaWiki:Mainpage/sah

Please change value for next messages:

Very thanks before!--Kaganer (talk) 18:00, 7 January 2018 (UTC)

✓ Done Didn't you mean to post to WD:AN. Matěj Suchánek (talk) 18:17, 7 January 2018 (UTC)
@Matěj Suchánek: Thanks! This place was based on previous request about similar topics ;)
But next question may be aimed to developers especially. Maybe if current mode for 'Mainpage' is "single page for any languages" (with automated substitution translated version related with UI language), then needs to change configuraton setting $wgForceUIMsgAsContentMsg for this site - for eliminating these redirects for all further languages? In my opinion, 'MediaWiki:Mainpage' should be called from any languages without language suffix.--Kaganer (talk) 18:23, 7 January 2018 (UTC)
This is very broad problem. As example, for 'bg' (Bulgarian language) links to mainpage from sidebar and from logo is leads to unexisted page Начална страница (while the translation Wikidata:Main Page/Content/bg is completed). --Kaganer (talk) 18:46, 7 January 2018 (UTC)
See also phab:T184386. --Kaganer (talk) 20:43, 7 January 2018 (UTC)
I fixed the link for bg, but I also support the proposal in T184386. --Pasleim (talk) 09:34, 8 January 2018 (UTC)

RecentChanges and tags

Hi! At the moment RecentChanges with tag RedirectCreated doesn't work. Could you check why? Thank you, --Epìdosis 14:58, 2 January 2018 (UTC)

Moreover, Special:Tags is down: when I try to load it, I got
[WkueCwpAICsAAL1rFFMAAAAA] 2018-01-02 14:59:19: Errore irreversibile di tipo "Wikimedia\Rdbms\DBQueryTimeoutError"
--Epìdosis 14:59, 2 January 2018 (UTC)
For the Rbdms error I logged T183921. Mbch331 (talk) 15:27, 2 January 2018 (UTC)
The work in phabricator:T91535 should fix this hopefully. --Lydia Pintscher (WMDE) (talk) 14:38, 15 January 2018 (UTC)

Deletion of Wikidata items - Q number is inadequate

I have now twice had to reach out to an active deletionist to address Q numbers that I have created in good faith that he has deleted. The problem is that if I don't have more than the Q number I have zero ability to fix -- or even know what the item is.

https://www.wikidata.org/w/index.php?title=Topic:U3o2j70bn3v7yu1y&topic_showPostId=u4yjzk7ynvpvcufw&fromnotif=1#flow-post-u4yjzk7ynvpvcufw


Neither of these pages provide enough information to the end user for them to understand and/or fix the issues. There needs to be some way that the various language descriptions are listed on the pages.

- https://www.wikidata.org/w/index.php?title=Q37022934&action=edit&redlink=1

- https://www.wikidata.org/w/index.php?title=Special:Log&page=Q37022934


I am also not receiving a notification on my Talk page, which would happen if I was on En Wikipedia or Wikimedia Commons.

This is highly problematic in the extremis. Can this be addressed by your team? If this is not the place for my request, please let me know where I should go.

Thanks! -- Erika aka BrillLyle (talk) 18:34, 2 January 2018 (UTC)

+1 — Ayack (talk) 22:27, 2 January 2018 (UTC)
+1, not being able to tell what the topic of the deleted item was is a substantial problem. I've filed a ticket on phabricator at phab:T184025. --Yair rand (talk) 00:05, 3 January 2018 (UTC)
It's possible permite to creator of the deleted item (Bot excluded) to see the deleted item? --ValterVB (talk) 08:48, 3 January 2018 (UTC)
+1. An automatic solution that gives a label (e. g.) would have to address the problem of bad labels, though, so it must be possible for the deleting admin to hide the label and descriptions as well in certain cases (when labels are libelous, racist, violating privacy etc.). --Anvilaquarius (talk) 10:30, 3 January 2018 (UTC)
+1 not being able to see what was deleted is really problematic. --Hsarrazin (talk) 11:31, 3 January 2018 (UTC)
 Support I think that having the label is good. In cases where the label is libelous the deleting admin can change it before deleting the item. ChristianKl12:26, 3 January 2018 (UTC)

Just a quick update: I've looked into it with the team and we might be able to do something about it. We will probably look into it in the next sprint or the one after. However what we will not be able to solve is the language. We can only provide one label. --Lydia Pintscher (WMDE) (talk) 14:28, 15 January 2018 (UTC)

WMDE feedback for the RfC "Allow the creation of links to redirects in Wikidata"

The RfC Allow the creation of links to redirects in Wikidata is now open for more than half a year without WMDE feedback. As a result it currently stays unrevolved. I think it would be great to either get feedback from the Wikidata developers or have a statement here that WMDE/Wikidata developers don't want to comment on it. ChristianKl14:05, 5 January 2018 (UTC)

You're right. It's been rotting on my todo list for too long :/ Pushing it up further and hope to have something before the end of the month. --Lydia Pintscher (WMDE) (talk) 14:30, 15 January 2018 (UTC)

Please convert Polish cultural heritage register number (P3424) from "external identifier" to "string" per review at Property talk:P3424.
--- Jura 08:59, 8 January 2018 (UTC)

Ok. I've opened phabricator:T184914 for it. --Lydia Pintscher (WMDE) (talk) 14:33, 15 January 2018 (UTC)

Description in the Whatchlist

Hello!

I recently begun to follow the modification in the Wikidata of articles in my Whatchlist (Spanish WP). However, it's almost impossible to understand most of the modification by only seeing the whatchlist: For example, I read on my Whatchlist:

  • (dif · hist) . . D Félix Urabayen (Q8963217); 09:48 . . Marklar2007 (discusión · contribuciones) (‎Se creó una afirmación: Property:P102: Q2351459)

While in the history of the wikidata item there is a much more understandable:

  • (cur | prev) 09:48, 6 January 2018‎ Marklar2007 (talk | contribs)‎ . . (16,791 bytes) (+414)‎ . . (‎Created claim: member of political party (P102): Republican Left (Q2351459)) (undo | thank)

Perhaps it's for the difficulty of traslating the item, but probably is better to have an English information than almost no information at all (that is the case now) Is it possible to get it better so the info in the Whatlist is more useful ?

Thanks!

--Martinmartin (talk) 10:54, 9 January 2018 (UTC)

Yeah we need to make some more changes there. We have phabricator:T115064 to track it. --Lydia Pintscher (WMDE) (talk) 14:49, 15 January 2018 (UTC)

webgetclaims bug

Hi, I was curious about the seating capacities and i notcied the APi call: https://www.wikidata.org/w/api.php?action=wbgetclaims&entity=Q1984022&property=P1083 does return +3200 as the value while the actual value is 102,455. the API returns the value as it was originally before renovations/expansions/reductions and does not return the current value. It seems to do it on pretty consistent basis (Q995161, Q1984022, Q1233077, etc...) Is it something expected, and is there another way to access the current seating capacity quantity?

thanks!  – The preceding unsigned comment was added by 2604:2000:1200:8017:503d:8008:65c3:4b03 (talk • contribs) at 10. 1. 2018, 00:20‎ (UTC).

The information needs to be updated in the item, the API just returns the available information. Matěj Suchánek (talk) 08:20, 10 January 2018 (UTC)


For instance for id Q1984022, Wikipedia shows 102,455 as the capacity on its page (https://en.wikipedia.org/wiki/Neyland_Stadium) and not 3200 as the API returns. Is there any sync between the data available on the wikipedia page and the wikidata item metadata, or do the item get updated in a completely independant manner? thanks again. – The preceding unsigned comment was added by 2604:2000:1200:8017:503d:8008:65c3:4b03 (talk • contribs) at 10 jan 2018 14:56‎ (UTC).

No, data isn't automatically synced from Wikipedia to Wikidata. An actual person needs to update that information. What is possible is to use the information from Wikidata in the enwiki article (of their local policy allows this), so only Wikidata needs to be updated to get the correct information on Wikidata and Wikipedia. Mbch331 (talk) 17:33, 10 January 2018 (UTC)

I got you. I created an account and corrected the venues capacities for the cases i noticed. Thanks!

Phase 3?

There are news about the "Phase 3" with Query namespace? --ValterVB (talk) 19:29, 10 January 2018 (UTC)

Jakob on my team has been working on one important piece of it over the last months and has been testing it with people at WikidataCon. It is a prototype for a query builder that doesn't require you to know SPARQL. I believe this is a crucial thing if we want Wikipedians to accept it. The current state is here. The next step is to look at the different options we have for the implementation strategy. We could for example create query entities that generate pages with the result that then can be transcluded into the Wikipedia articles. Or we could ask people to store the query in the article. Or something completely different. We need to figure out the options and discuss and evaluate them. I hope we can get to that this quarter. --Lydia Pintscher (WMDE) (talk) 15:09, 15 January 2018 (UTC)

René Lévesque

Recently I tried to go from the zh wiki page of René Lévesque (w:zh:瑞内·勒维克) to the corresponding en wiki page (w:en:René Lévesque), but it directed me to w:en:Montréal-Laurier, which does related to René Lévesque. The wikidata entries seems fine to me. Wondering what could happen there. GC MathTeacher (talk; talkzhwp) 02:25, 16 January 2018 (UTC)

The problem was in the zh article itself. There were three links to enwiki, however, they weren't prefixed with :, so the system saw them as interwikis instead of normal links. And local interwikis always take preference over Wikidata interwikis. Mbch331 (talk) 07:44, 16 January 2018 (UTC)
Thank you so much. I will try to fix them. GC MathTeacher (talk; talkzhwp) 03:53, 17 January 2018 (UTC)

WDQS: Map and Graph at the same time

I’m not sure if this is the right place to post this, but hopefully someone can forward it if not: On query.wikidata.org, it’s possible to show the result of a query as a graph or as a map. Apparently a mixture of both (locating items with known coordinates there with the other items floating around like in a normal graph view) isn’t possible? At least I’ve asked on WD:RAQ without response. So, I suggest adding such an option :-) --Nenntmichruhigip (talk) 07:57, 16 January 2018 (UTC)

No that's not possible currently. Can you explain a concrete case that you'd like to visualize so we can see if we can make it happen in the future? --Lydia Pintscher (WMDE) (talk) 09:21, 16 January 2018 (UTC)
I'm not sure that it's quite what User:Nenntmichruhigip is requesting, but a nice extension might be to be able to show icons or images near map coordinates, rather than just red dots -- something like eg the image in this tweet: https://twitter.com/Amazing_Maps/status/951189476059107328 or a map that showed landmarks by thumbnail. It could be quite a challenge to optimise the detailed placing of images, to reduce overlap. But maybe a library is available. Jheald (talk) 11:33, 16 January 2018 (UTC)
I’ve made a mockup for the result of this query: Picture on picload.org (because I didn’t know what license/categories to use on Commons). The items with coordinates have a red border, the others are supposed to be dragable (with a lot less bouncyness than the current graph view) and randomly placed somewhere at first (that’s why most of them are way off their actual location in that mockup). The names in the mockup are shortened for laziness, that of course wouldn’t be the case in an actual implementation. --Nenntmichruhigip (talk) 10:14, 19 January 2018 (UTC)

Hard to read titles

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

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)