Wikidata:Report a technical problem/Archive/2023/08

From Wikidata
Jump to navigation Jump to search


newspaper format (P3912)

This item broadsheet (Q665319) requires official name (P1448) and native label (P1705) but if I add these statements native label (P1705) will warn an entity should not have statements for both native label and title. Vice-versa if I delete title (P1476) broadsheet (Q665319) will require again title. EDIT I found the problem it's in newspaper format (P3912), item-requires-statement constraint (Q21503247). A user made these changes.-- Carnby (talk) 19:09, 12 August 2023 (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. Mohammed Sadat (WMDE) (talk) 08:09, 21 August 2023 (UTC)

Central login

Does anyone know why central login fails so often? It's very frustrating for wiki-nomads who wander from one wiki to another, to make an edit and find it's linked to an IP address instead of our account. All the best: Rich Farmbrough, 15:15, 30 July 2023 (UTC).

I think there was a Phabricator ticket specifically as to why SUL does not propagate to Wikidata, but it is there for a few years and by now it is clear that noone is going to do anything about it.--Ymblanter (talk) 18:59, 1 August 2023 (UTC)
The best tickets are the old ones! All the best: Rich Farmbrough, 18:04, 2 August 2023 (UTC).
As much as I am aware, central login for Wikidata works, but strict privacy settings of the browser or the usage of certain addons can break it. It is usually a good idea to check whether this is a local issue. ---MisterSynergy (talk) 18:17, 2 August 2023 (UTC)
What MisterSynergy said. T226797 and T202028 are related it seems. Try logging in using the incognito or private browsing mode of your browser. This mode often disables extensions, which can help pinpoint if an extension is causing the problem. -Mohammed Sadat (WMDE) (talk) 10:21, 11 August 2023 (UTC)
Strict cookie settings can also be a problem. See Wikidata:Project chat/Archive/2023/04#SUL not working well on Wikidata? for example. —MisterSynergy (talk) MisterSynergy (talk) 10:56, 11 August 2023 (UTC)

Wikidata's UI is unbearable

I just want to share my experience of using Wikidata within one day to edit incorrect site links in one item, moving them to another. Do anything you want with it. If this page is not the right place for such reports, please move it elsewhere. Sorry that I don't have time to post on Phabricator; probably there are some tasks there related to what I will say.

  1. I've opened Wikidata on this account that had only 5 edits in Wikidata. Before that, I used Wikidata on my other account User:Jack who built the house, which I now use only for interface admin–related tasks.
  2. I was about to fix some incorrect site links in Q6962596 which had site links to two unrelated sets of templates that originate from w:en:Template:Example and w:ru:Template:Example.
  3. Upon trying to remove irrelevant Wikipedia site links from the item, I got this error.
  4. This error has no indication whether it's permanent or not (can I just try again? "If [...], please do not submit this edit again" – so I can?).
  5. I tried to save again, but the error still popped up. "I guess I can't", thought I.
  6. Wrong. As I later found out, the edits were partly successful, but removed only one site link at a time.
  7. I assume this is somehow related to the fact that my edits were marked with "new editor removing a sitelink". 6 edits later my edits stopped being marked this way, and everything got a little easier.
  8. After I successfully removed irrelevant site links, I noticed that there are also... duplicates (in some sense) of these site links in the lead section of the page (under "In more languages") in the "Label" column.
  9. Good that I noticed the presence of the "All entered languages" link. Otherwise, I wouldn't have discovered that there are lots of these duplicates.
  10. By the way, the UI freezes for like 10 seconds when I click it and then click the pencil icon in the top right corner.
  11. By the way, if you, for any reason, click the spot where the cursor is, the list of languages will disappear, and you won't know where and why.
  12. Upon trying to remove these irrelevant labels as well, I bumped into another error message. At least this time it details what is wrong (anti-abuse measure).
  13. And then again, some labels got successfully removed, and there is no indication of this in the error message.
  14. I really, really hope these error messages are displayed only when new people delete something, not add. This would mean my case is somewhat an outlier (but not really).
  15. Knowing that some of my edits are lucky enough to get through, I then went ahead to add the site links that I removed from Q6962596 to a new item. I successfully created it (Q121271549) using a sidebar link in w:ru:Template:Example.
  16. But then the previous pattern resumed: some site links were added successfully, some ran into a rate limit.
  17. In the meanwhile, I bumped into another oddity of the Wikidata UI: if I type a language code in the language code input, often a language with a different language code is selected: I type se, "Sesotho sa Leboa" (language code "nso") is selected instead of the actual project with "se" language code. See the screenshot. This is the same experience that I had, like, 7 years ago. I'm 99% sure a task for fixing this exists on Phabricator for 10 years with "low" priority.
  18. Having no other options left, I decided to wait.
  19. After waiting for 3 hours, I found out that the error didn't go anywhere. Even partial edits didn't go through.
  20. Angry at that fact, I opened another tab with the same page and tried to make the same edits.
  21. And yay! The edits finally got through. (Would they have gotten through if I had done the same 3 hours ago instead of waiting? IDK.)
  22. Meanwhile in the old tab, the error continued to appear. Which is funny because the inputs had exactly the same content that I saved a minute ago in the new tab, so there was nothing to actually save.
  23. The only thing left was to remove incorrect labels from the original item.
  24. The tab with the original item continued to show an error.
  25. So I wanted to repeat the item 21 of this list and do the same.
  26. To no avail: this time there was an edit conflict. With what? An edit that was blocked by an abuse filter? (This can be because part of that edit got through.)
  27. And one copy of "Edit conflict" is enough.
  28. Then I bumped into the abuse filter a couple of times again, and several minutes ago, in the middle of writing this post, I finally finished what I started. The whole task took me a total of 6 hours.
  29. P.S. I was also shocked to find out that if I edit some section, forget to save the edits, and click some link to go to another page (or do this accidentally), no "You'll lose unsaved edits" confirmation will show up.

I could do something not the right way (correct me if you can then; I now already know that there is a gadget for moving site links between items), but this is not the point. This is just an experience of a user well-familiar with Wikimedia projects (I'm not even a novice – what would have been if I had been one?) and an occasional editor on Wikidata. And this is, again, a description of what I had to endure while trying to fix incorrect site links in one item. I can only imagine what people who contribute to thousands of items for long periods of time are going through. You guys have my utmost respect. JWBTH (talk) 05:28, 7 August 2023 (UTC)

Nice post outlining pain-points and why the UI is barely adequate. Some of them relates to rate-limits that only applies for users that are not autoconfirmed, but the experience for new users matter. As a bare minimum error messages should be easily comprehensible. I apologize for the bear-puns, I could not help myself. Infrastruktur (talk) 19:44, 7 August 2023 (UTC)
Thank you for sharing your detailed experience with Wikidata's UI. We're noting your feedback and acknowledging the challenges you've faced. We will look into this and take it as input for the current initial planning for improvements of the Item UI. -Mohammed Sadat (WMDE) (talk) 10:49, 11 August 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

I created The carnival of philosophy : philosophy, politics and science in Hegel and Marx, intending it as a doctoral thesis, but it got misclassified as something else, and it is not at all obvious how to correctly reclassify it. —Anomalocaris (talk) 20:19, 15 August 2023 (UTC)

@Anomalocaris. It seems that other editors have already resolved the issue. Just a friendly reminder: if you wish to discuss the content on individual Items, please use Wikidata:Project chat. This page is primarily meant for technical discussions. Thanks! - -Mohammed Sadat (WMDE) (talk) 08:25, 21 August 2023 (UTC)

Dorchester (Q503331)

The page is locked so can you add a new entry . https://el.wikipedia.org/wiki/Ντόρτσεστερ Thank you! MavrosPagos (talk) 17:47, 9 August 2023 (UTC)

@MavrosPagos: It appears that Q503331 is currently semi-protected, limiting edits to autoconfirmed users—those with accounts at least 4 days old and having made at least 50 edits. You may request the community at Wikidata:Project chat to make this edit use. This page mainly focuses on technical discussions. -Mohammed Sadat (WMDE) (talk) 09:39, 21 August 2023 (UTC)

When using the Query Service Julian Dates are getting converted to Gregorian Dates

Tracked in Phabricator
Task T246731

When running a query that collects dates (e.g.https://w.wiki/6rSi) Julian dates are being converted. Date values in Wikidata using the Julian calendar are being displayed/converted to Gregorian calendar in the Wikidata Query service results. This 'conversion' is adding 10 days in the query results. e.g. if date of death = 4 January 1647 (Julian calendar) on Wikidata item (Q43395584) then it is displayed in query results as 1647-01-14T00:00:00Z. https://w.wiki/6rSi

I think this 'conversion' shouldn't happen and query service results should return the date as it is on the item.

I have reported this bug and a phabricator ticket has been created. Delane13 (talk) 11:05, 8 August 2023 (UTC)

Thank you. -Mohammed Sadat (WMDE) (talk) 10:55, 11 August 2023 (UTC)
In our case we have all our dates from the Julian calendar.... this means when our site is pulling the dates of Scottish witchcraft investigations from Wikidata, even though they are in Julian calendar, they are auto converted to Gregorian and displaying as such. We could write a script to reconvert back to Julian calendar but this seems a) an unnecessary extra step and b) is additionally complicated given that the auto conversion only seems to apply to date precisions of DD-MM-YY and not MM-YY (month-year only precision , which is still returned as a full date - 1644-07-01T00:00:00Z) and nor YY (year only precision ,which is returned in format 1662-01-01T00:00:00Z). This added complication means we'd need to figure out how to write a script to handle the precision issue as many of the thousands of dates we are displaying have different precisions (historical dates such as these means we sometimes only have a year to go by or a month and a year but happily there are many also with the full day-month-year precision). The nature of the format that the queries returns gives no indication of the precision therefore is hard to the distinguish when the precision is MM-YY or when is actually the first of the moth (01-MM-YY). This complication makes it quite hard for a script to handle. Any input on a way forward would be beneficial as at the moment we are trying to work out how to undo the auto conversion (and handle all the precision exceptions) and display our dates in the Julian calendar as recorded. Delane13 (talk) 15:52, 22 August 2023 (UTC)

How to change photoes in Wikidata Infobox

I changed the photo in https://www.wikidata.org/wiki/Q714984 to change the photo in Category:Yanbian Korean Autonomous Prefecture Wikidata Infobx, but it remains unchanged. Could anyone please tell me how to make the change take effect on Category:Yanbian Korean Autonomous Prefecture? EditQ (talk) 09:02, 13 August 2023 (UTC)

@EditQ: I see that this is now resolved. For future reference, you can purge the page by adding ?action=purge to the end of the URL. This will clear the page cache and refresh the data from Wikidata. -Mohammed Sadat (WMDE) (talk) 08:05, 21 August 2023 (UTC)
Thanks for your reply. I have antoher question. How to add a photo to "Wikidata Infobox"? For example, [1] doesn't have a photo. How to add one? EditQ (talk) 12:13, 22 August 2023 (UTC)
Similarly like it's done in Yanbian Korean Autonomous Prefecture (Q714984). It's already been done. --Matěj Suchánek (talk) 19:59, 23 August 2023 (UTC)

Problem creating new items

Hi there,

I've encountered an interesting problem today: I tried to add a series of new items via mix'n'match and left it running in the background (because this has been taking a long time lately, if it doesn't fail altogether). Meanwhile, I tried to manually add another unrelated item and got this error message in bold, red letter: "As an anti-abuse measure, you are limited from performing this action too many times in a short space of time, and you have exceeded this limit. Please try again in a few minutes." How many is "too many"? Via mix'n'match I'm trying to add some 30 items right now (for 5 minutes at least), and in this space of time one more items should be no problem.

Anybody got any idea why this might be and what I could do?

Many thanks, Jonathan Groß (talk) 11:30, 6 August 2023 (UTC)

The rate limit does applies to both manual and tool-assisted edits like mix'n'match. However, I'm not certain about the exact values for page creations or edits per minute. @Lucas, could you help with this information? -Mohammed Sadat (WMDE) (talk) 10:36, 11 August 2023 (UTC)
You can see the rate limits that apply to you in the API. I think the limit for edits for non-new users is 90 edits per minute. Lucas Werkmeister (WMDE) (talk) 10:50, 11 August 2023 (UTC)
Thanks for the answers. @Lucas Werkmeister (WMDE): I don*t think I've ever exceeded this limit. With this specific catalogue link, even creating a single item fails.
What's more: The new MnM catalogues added after 1 August 2023 are not being converted and show up as empty. Where is the bottleneck there? Are there any pages that show what is running, using resources on Toolforge at any given time? Are there places to report problems outside of the developers' user pages? Jonathan Groß (talk) 06:44, 17 August 2023 (UTC)
@Jonathan Groß: the bottleneck is the "jobs" queue of Mix'n'match, which frequently gets completely stuck in the last months; from main page, open the menu which is just left the language menu and select "jobs"; there are (https://mix-n-match.toolforge.org/#/jobs) 283 jobs queued and 6 running (theoretically); to the import of your catalogue is queued, as you can see from the "action" menu of the catalogue itself selecting "jobs". It seems, this time, that the jobs have stopped working around 11 August. No place to report problems outside User talk:Magnus Manske (or pinging him on Twitter, which for stuck jobs often works well). --Epìdosis 06:58, 17 August 2023 (UTC)
OTOH Magnus's tool's jobs becoming stuck is a well known failure mode which WMDE could, but serially chooses not to, interest itself in. We're left to play a stupid game of Where's Wally when we could instead have a professionally run service delivery which users of MnM and QS deserve. On this current MnM issue, I pinged MM some time ago on twitter and reported on his bitbucket, but nada. --Tagishsimon (talk) 14:49, 18 August 2023 (UTC)
It's the tubes Sir, they're clogged. :-) Infrastruktur (talk) 16:00, 18 August 2023 (UTC)
MnM jobs were being processed this morning - about 70 completed - but it seems to be dead again, most likely coincident with an autoscrape job being commenced at 14:37:10. As if anyone cares. Which, patently, they do not. https://mix-n-match.toolforge.org/#/jobs --Tagishsimon (talk) 15:42, 21 August 2023 (UTC)
@Lydia Pintscher (WMDE): Any idea what WMDE staff could do to help with the issue? I realise that Magnus maintains his tools himself, but I strongly assume there are issues on Toolforge itself relating to the problem that could (and should) be fixed. Jonathan Groß (talk) 10:27, 19 August 2023 (UTC)
I'm honestly not sure but I'll ask around. Lydia Pintscher (WMDE) (talk) 12:22, 27 August 2023 (UTC)

Taxon vs. adtaxon

Discussion here.-- Carnby (talk) 11:09, 27 August 2023 (UTC)

Boloboi

Español: Un cordial saludo a todos. Quiero reportar un problema con el usuario Boloboi. Actualmente, éste usuario está bloqueado de Wikipedia, por realizar ediciones arbitrarias a diferentes artículos, además de hacer caso omiso a la recomendación del bibliotecario BetoCG. En estos momentos, Boloboi sigue haciendo lo mismo, pero ahora en Wikidata. La situación es agotadora.

English: A cordial greeting to all. I want to report a problem with the user Boloboi. Currently, this user is blocked from Wikipedia, for making arbitrary edits to different articles, in addition to ignoring the recommendation of the librarian @BetoCG. At the moment, Boloboi continues to do the same, but now on Wikidata. The situation is exhausting. Californipedia (talk) 21:00, 27 August 2023 (UTC)

@Californipedia You should report this at Wikidata:Administrators' noticeboard. -- William Graham (talk) 23:33, 27 August 2023 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Report_a_technical_problem/Archive/2023/08&oldid=1979503896"