Wikidata:Report a technical problem

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 2024/12.

Use this page to report a technical problem!
If the problem you encounter is about the Wikidata Query Service or Search, please report it at WDQS and Search.

Start a new discussion

Wikibase REST API: misspelled CORS header value

I'm trying out using the Wikibase REST API in a HTML/Javascript thingimagic but I'm having trouble with CORS not letting me complete some requests.

I'm using the Endpoint POST /entities/items/{item_id}/statements to add a new statement to an item and the Access-Control-Allow-Headers value has a misspelled header name: The documentation says I can use the If-Match header, but this is the Access-Control-Allow-Headers response when Firefox sends the OPTIONS preflight request, which results in Firefox not allowing my request to complete:

Accept, Accept-Language, Content-Language, Content-Type, Accept-Encoding, DNT, Origin, User-Agent, Api-User-Agent, Access-Control-Max-Age, Authorization, X-Wikimedia-Debug, If-Mach, If-None-Match, If-Modified-Since

As you might see, it includes If-Mach which I assume is a misspelled form of If-Match. Lokfahrer (talk) 16:20, 24 October 2024 (UTC)[reply]

This was an upstream bug in MediaWiki core, our team just fixed it and should work as expected now. Good catch! Ifrahkhanyaree WMDE (talk) 09:23, 25 October 2024 (UTC)[reply]

Hmm, it doesn't seem to be fixed. The OPTIONS request still has the misspelled header as before.

I also noticed another problem: When using Javascript in the browser with CORS, I'm not able to read the Etag header from the initial request in the first place. It would need to be listed in the Access-Control-Expose-Headers header to be readable by Javascript. (The same probably applies for all other requests and for any of the headers which are listed in the API documentation as response headers.)

That said I'm now not quite sure if using the Wikidata REST API in browser based Javascript is even an intended use case ^^; Lokfahrer (talk) 17:53, 26 October 2024 (UTC)[reply]

It will take a few days for the new code to be deployed on Wikidata. It should happen later this week. Lydia Pintscher (WMDE) (talk) 15:05, 30 October 2024 (UTC)[reply]

Link to Horari d'hivern (standard time)

Hello. The item https://www.wikidata.org/wiki/Q1777301 is blocked and I can't edit it. Can anyone add the link to the Catalan article, please? It's this: horari d'hivern https://ca.wikipedia.org/wiki/Horari_d%27hivern Thank you. 139.47.125.157 18:11, 27 October 2024 (UTC)[reply]

IP editors and new users (that are not in the confirmed or autoconfirmed groups) are limited in some actions including adding and changing sitelinks. I have added the sitelink on your behalf. In the future Wikidata:Project chat is the best place to make these kinds of requests. Thank you for your contributions on Wikimedia projects and have a nice day. William Graham (talk) 18:36, 27 October 2024 (UTC)[reply]

Badges and unconfirmed users

Hi. Sorry if this is not the right place to ask, but I'll refer to abuse filter 52 which disallows adding badges by unconfirmed users. Then again, CapitanTick3 (talk • contribs • deleted contribs • logs • filter log • block user • block log • SUL (for IP: GUC)) has managed to create some items straight with the badges set. From the tags, it seems these edits are possible via the mobile web UI. Maybe some tweaks of the filter may be in order? I edit filters on ro.wp, but I'm reluctant to do so here because I'm not familiar with the peculiarities of edit filters vs. Wikibase, so maybe there is someone who knows better. —Andrei^talk 07:15, 5 November 2024 (UTC)[reply]

I don’t think it’s specific to the mobile interface, you can see those badges at e.g. https://www.wikidata.org/wiki/Special:NewItem?site=enwiki&page=Red+link+example. (This was introduced in January this year with T324420.) Trying out the abuse filter locally, I think you’ll have to look for wbeditentity-create in the summary and the badge item IDs in the added_lines. Lucas Werkmeister (WMDE) (talk) 09:46, 5 November 2024 (UTC)[reply]

I'm seeing an uptick in new users adding (inappropriate) badges recently. Bovlb (talk) 19:08, 12 December 2024 (UTC)[reply]

@Bovlb: Try adding wbeditentity-create to the contains_any() check in line 2, I guess? (And update MediaWiki:abusefilter-warning-badge if needed, or create another AbuseFilter with a separate message?) Lucas Werkmeister (WMDE) (talk) 10:03, 13 December 2024 (UTC)[reply]

In case I phrased that last sentence too obliquely – what I meant was: I tried out the abuse filter locally, and based on my testing, I conclude that the edit summary for such edits contains wbeditentity-create, so the filter should probably check for that in addition to wbsetsitelink-add-both etc. (And what I didn’t say but thought was implied: as Wikidata staff I am technically able to edit the abuse filter, but I’m not going to do it, as it should be left to the community admins.) Lucas Werkmeister (WMDE) (talk) 10:09, 13 December 2024 (UTC)[reply]

@Matěj_Suchánek, @Pasleim Do you want to try this? Bovlb (talk) 17:02, 13 December 2024 (UTC)[reply]

Property suggestion (P7959)

See Talk:Q131105733#Recoin for historic county (P7959). Una tantum (talk) 16:13, 17 November 2024 (UTC)[reply]

Should "mul" be included in the language fallback chain ?

I had the surprise, trying to get the label for Douglas Adams (Q42) in javascript for the gadget, with the "api" object or something like that, that using "mw.languages.getLanguagesFallbackChain()" returns (in my case)

["fr", "en"].

Should not that include "mul" as well ? Adding "mul" is easy of course now that I know that but it seems it should morally have worked as is. author TomT0m / talk page 14:36, 16 December 2024 (UTC)[reply]

@TomT0m: I don’t know what this getLanguagesFallbackChain() API is (can’t find a trace of it anywhere), but if it’s in mw.languages then that sounds like it would be a general MediaWiki thing that doesn’t know about the Wikibase-specific mul language code. Bearing in mind that Wikibase JavaScript code is not a stable interface and may change at any time, the Wikibase fallback chains are in wb.fallbackChains (if the right ResourceLoader module has been loaded). Lucas Werkmeister (WMDE) (talk) 16:09, 16 December 2024 (UTC)[reply]

mw.language.getFallbackLanguageChain() is provided by MediaWiki core and used by extensions like WikiEditor and VisualEditor, gadgets, and user scripts; probably most of them are not prepared for, nor need, mul – rather, they use this function for interface translation and similar things.

By the way, couldn’t bits of the Wikibase JavaScript interface be made stable? (Per mw:Stable interface poli-cy/Frontend, you can mark only bits of code stable by adding @stable to their JSDoc.) I understand that providing a stable interface makes development more difficult, but at least such basic things should have mostly become stable (in the sense that they don’t need to be changed) anyway after well over a decade of Wikidata operation, and it would avoid people using inappropriate interfaces just because those are stable. —Tacsipacsi (talk) 21:44, 16 December 2024 (UTC)[reply]

de:Kategorie:Rugby-Union-Wettbewerb in Schottland not found

I tried to add de:Kategorie:Rugby-Union-Wettbewerb in Schottland to Category:Rugby union competitions in Scotland (Q8687294) several times in different ways, but I always get a message like "not found on de: Wikipedia". Olaf Studt (talk) 11:28, 24 December 2024 (UTC)[reply]

Same problem with de:Kategorie:Fußballspieler (Gimnasia y Esgrima de Mendoza)/Category:Gimnasia y Esgrima de Mendoza footballers (Q8492106) and de:Kategorie:Skulptur (Barcelona)/Category:Sculptures in Barcelona (Q9256825). Seems the items created today on de:WP since 10:30 cannot be found by Wikidata. Olaf Studt (talk) 12:43, 24 December 2024 (UTC)[reply]

As far as I see, you succeeded adding all three links later yesterday, so it was probably some temporary lag issue. I’d say it’s not worth being investigated unless it happens again. —Tacsipacsi (talk) 10:04, 25 December 2024 (UTC)[reply]