Wikidata:Report a technical problem

Report a problemHow to report a problemHelp with PhabricatorGet involvedWDQS and Search

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 2026/10.

On this page all sections tagged with {{Section resolved|1=~~~~}} after 1 day are automatically archived.

Start a new discussion

Preferences for Default time period in watchlist not respected

Hello,

In https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-watchlist I have selected:

• Default time period in watchlist for manually added pages: 6 months
• Add pages and files I edit to my watchlist
  • Default time period: 3 months.

But when I make a simple edit (to an item which was not in my watchlist) with the Wikidata user interface (example), the item is permanently added to my watchlist.

Wikidata should respect my preferences for Default time period in watchlist: 3 months.

Regards, NicoScribe (talk) 16:28, 1 September 2026 (UTC)

Hi @NicoScribe, thank you for the report. I've tested this on my end and the preferences seem to be working as expected (when I edit an Item, it's added to my watchlist for the default time period I've set).Could you confirm which skin are you using? Do you have any gadgets or user scripts enabled that might affect watchlist behaviour?

Has anyone else experienced this and can reproduce it? If so, please share your setup details so we can file a ticket to investigate. -Mohammed Abdulai (WMDE) (talk) 09:52, 14 September 2026 (UTC)

@Mohammed Abdulai (WMDE): thank you for your answer!

My context is:

• in Preferences/Appearance/Skin I have: Vector legacy (2010)
• in Preferences/Gadgets I have:
  • Merge
  • Move
  • moveClaim
  • Search
  • AuthorityControl
  • Site ID to interwiki
  • Protection indicators
  • relateditems
  • Rearrange Values
  • Redirect image links to Commons for files that are hosted there.
  • NewSection
  • FormWizard
  • Watchlist Notice
  • Adds a button to RFD for parsing unparsed sections to bypass the parser's template limit.
• and I also use m:User:NicoScribe/global.js.

This is strange because, as I recall, my preferences were never respected on 1 September 2026, but they were respected only in some cases on 13 September 2026. So, today, I changed my preferences for watchlist:

• Default time period in watchlist for manually added pages: 1 year (this is my unique local exception compared to my global preferences (where my value is Permanent for this line))
• Add pages and files I edit to my watchlist
  • Default time period: 3 months.
• Add pages I create and files I upload to my watchlist
  • Default time period: Permanent.
• Add pages where I have performed a rollback to my watchlist
  • Default time period: 6 months.

Now that I had different values (1y, 3m, 6m) which are not Permanent, I made the following edits (to items which were not in my watchlist) with the Wikidata user interface:

• I manually added Help:Ranking to my watchlist → OK: 1 year
• here I used rollback in main namespace → OK: 6 months
• here I used rollback in Translations namespace → OK: 6 months
• here I added a description in main namespace → KO: Permanent
• here I changed a description in main namespace → KO: Permanent
• here I added a label in main namespace → KO: Permanent
• here I changed a label in main namespace → KO: Permanent
• here I added a claim in main namespace → KO: Permanent
• here I changed a claim in main namespace → KO: Permanent
• here I removed a claim in main namespace → KO: Permanent
• here I added a sitelink in main namespace → KO: Permanent
• here I undid a change of description in main namespace → KO: Permanent
• here I undid a change of label in main namespace → KO: Permanent
• here I undid a change of claim in main namespace → KO: Permanent
• here I edited a page in Help namespace → OK: 3 months.

--NicoScribe (talk) 14:39, 14 September 2026 (UTC)

Today, I made edits (I changed descriptions of items in main namespace):

• after unselecting everything in Preferences/Gadgets → KO: Permanent
• after chosing the skin Vector (2022) → KO: Permanent
• after chosing the skin MinervaNeue → KO: Permanent
• after chosing the skin MonoBook → KO: Permanent
• after chosing the skin Timeless → KO: Permanent

--NicoScribe (talk) 22:29, 16 September 2026 (UTC)

@Mohammed Abdulai (WMDE): do you have news? --NicoScribe (talk) 10:16, 1 October 2026 (UTC)

@NicoScribe: Could you please file a ticket on Phabricator? This doesn't seem to be an issue specific to Wikidata so someone outside our team would need to look at it. We also can not reproduce it in our testing unfortunately so narrowing it down is hard. (I'd file the ticket but it'd better if the people looking at it can ask you questions directly.) Lydia Pintscher (WMDE) (talk) 17:19, 8 October 2026 (UTC)

@Lydia Pintscher (WMDE): thank you, I have created Phabricator:T440767. --NicoScribe (talk) 21:25, 9 October 2026 (UTC)

Property searching isn't language-specific

I'm not sure how to explain this so I'll do it bug-style, explaining what happens when I do something and what I expected it to do instead.

Go to an item. Press + add statement. There is a box called property with some suggestions in a drop down. Type way and the properties with way are listed. Seven possibles are listed, however 3 of these are not in English. I would expect search to either only come up with English results, or to at least put the English results first. My browser language is British English. The results for way are:

• subclass of (P279) which has an alias way of. Y
• archive URL (P1065) which has an alias wayback machine. Y
• via (P2825) which has an alias waystation. Y
• owned by (P127) wayır is the translation in Dimli. Y
• start of work period (P2031) wayah kerja (mulai) is the translation in Javanese. Y
• owner of (P1830) Wayırê is the translation in Dimli. Y
• OpenStreetMap way ID (P10689) it gives way OpenStreetMap in brackets, which seems to be Indonesian. However this is the one I was looking for so Y.

Secretlondon (talk) 18:38, 14 September 2026 (UTC)

This is in Safari 26.5.2, if that's useful. Not tried other browsers, but I suspect this is server end. Secretlondon (talk) 19:00, 14 September 2026 (UTC)

I don't think that's a bug, as long as the best results show on top. It's probably intended behavior to deal with cases where people are using languages that are less frequently used. ChristianKl ❪✉❫ 09:39, 26 September 2026 (UTC)

The best results are not showing on top. The best result is actually last as it is the only one with the keyword in the name, rather than in an alias. Secretlondon (talk) 11:08, 26 September 2026 (UTC)

Actually I wonder if it is searching on alias rather than the property name. Secretlondon (talk) 17:23, 6 October 2026 (UTC)

Q88466423

https://www.wikidata.org/wiki/Talk:Q88466423 Lorenz Ernst (talk) 06:46, 20 September 2026 (UTC)

This is not a technical problem. It's a data issue with two different people being in the same item. Bitte Wikidata:Forum auf Deutsch. Secretlondon (talk) 11:10, 26 September 2026 (UTC)

thx & done --Lorenz Ernst (talk) 12:16, 26 September 2026 (UTC)

Deprecated statements in database reports

Hi, can you please have a look at this discussion? It would be lovely if we could have a solution for the issue. Thanks! Bencemac (talk) 17:24, 26 September 2026 (UTC)

Hi @Bencemac. Yeah that sounds sensible. That needs to be fixed in the bot by Ivan as mentioned in the discussion you linked. Unfortunately the code is still not open as far as I know so there isn't anything other people can do to fix it I fear besides reimplementing it. Lydia Pintscher (WMDE) (talk) 08:23, 28 September 2026 (UTC)

Duplicate wikidata entries on the same person

I recently created a new wikidata entry Albert Lindquest Q141595669 to go with the English wikipedia article I created at Albert Lindquest. I did not realize that someone had already created Alan Lindquest Q96628571 which was one of his many other names (the least often used). I would like to merge Alan Lindquest to Albert Lindquest, but I find the Help:Merge page confusing and have no idea how to successfully do this. Any help would be appreciated. Apologies if this isn't the right forum for this type of thing. I find wikidata.org difficult to navigate. 4meter4 (talk) 17:25, 29 September 2026 (UTC)

I've done this for you. It's probably better to ask on WD:Project Chat for this kind of thing. Secretlondon (talk) 05:02, 30 September 2026 (UTC)

Lexeme with invalid language deleted 10 months ago but still in WDQS

L1548780: no description

It would be nice to get the deletion synced in the WDQS as it assigned the following item as language, which has label 'English' but is a US town, not the language, so now we will have this non-language returned when selecting languages used in lexemes until the sync occurs

English (Q2017605): town in and the county seat of Sterling Township, Crawford County, Indiana, United States

See phab:T407702 (edit: number corrected) which suggests there is a script that can be run for this. Thanks

- FreqWork (talk) 16:47, 2 October 2026 (UTC)

Pinging @GModena_(WMF). Lydia Pintscher (WMDE) (talk) 17:16, 8 October 2026 (UTC)

MediaWiki:Wikibase-SortedProperties - external identifiers

MediaWiki:Wikibase-SortedProperties - please split out the section MediaWiki:Wikibase-SortedProperties#IDs with datatype_"external-id" to a new page, named e.g.

1. MediaWiki:Wikibase-SortedProperties-datatype-external-id (in case other datatypes get a separate page, the prefix MediaWiki:Wikibase-SortedProperties-datatype- would help to list them next to each other in an alphabetical listing. There could theoretically be completely different splits, e.g. by entity type)
2. MediaWiki:Wikibase-SortedProperties-identifier

Category:Properties with external-id-datatype - 10644 pages and growing

By splitting out identifiers

1. make MediaWiki:Wikibase-SortedProperties easier to access
2. make MediaWiki:Wikibase-SortedProperties easier to discuss on its talk page by having identifier talk elsewhere

make diff pages for MediaWiki:Wikibase-SortedProperties more usable - less interference by differences from the identifier section

1. FUTURE: prepare for automatic sorting, e.g. by label of choice - Wikidata currently sorts those identifiers that are not in a specific group by English label - without a need to add these automatically added properties at all to the page

The easiest part should be to simply split without any further features. That would already be a big help.

-- GF2609 (talk) 16:33, 5 October 2026 (UTC)

This is not technically possible at the moment, see Wikidata:Report a technical problem/Archive/2025/11#MediaWiki:Wikibase-SortedProperties - move external-ids to MediaWiki:Wikibase-SortedPropertiesIDs. Lucas Werkmeister (WMDE) (talk) 08:31, 6 October 2026 (UTC)

"not technically possible at the moment" - the request is about making it technically possible.

Can you create a bug report in phabricator?

Regarding the reply at the other page: "The property order system doesn't parse wikitext transclusions"

The external ID properties already get a special treatment in the Wikibase software, they are displayed in an extra section. It doesn't seem to be Wikidata-specific, as there is no setting in that sort page that enforces that separation.

The problem at the other hand could be Wikidata-specific, as other installations maybe don't host such a large number of external identifier properties.

The current system is problematic for Wikidata contributors because external identifier properties:

1. exist in a high quantity
2. are added frequently

GF2609 (talk) 09:13, 6 October 2026 (UTC)

Q204327 bug at zhwiki?

w:zh:奥斯莫比, why the English link to Template:General Motors not the English version of Oldsmobile? Hyins - Talk 08:37, 12 Oct 2026 (UTC)