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 2025/05.

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day.

Start a new discussion

Feature request: Non-reflexive property constraint

I've just edited Taleveras (Q17109355) to remove the nonsensical assertions that it is both its own subsidiary and parent company. This is sufficiently silly that should be constraints on the relevant properties, child organization/unit (P355) and parent organization/unit (P749), to stop this.

But having looked at the constraint definitions, I cannot find a way of doing this. Unless this already exists, I suggest a "not-reflexive property" constraint should be created, to enable to only the above, but also such absurdities as a person being their own parent, child, or an entity being its predecessor, successor etc.

(A more general feature might be the creation of an "acyclic property" constraint, which would necessarily also imply the non-reflexive property, but it would be far more diffcult to enforce than a simple subject ≠ object check, and hard to check in real time.)

The Anome (talk) 05:08, 8 April 2025 (UTC)

I think this corresponds to phab:T224837. --Matěj Suchánek (talk) 15:45, 17 April 2025 (UTC)

... and phab:T173771 now that we are at it. --Matěj Suchánek (talk) 15:48, 17 April 2025 (UTC)

May I suggest inverting this constraint? Claims are very rarely self-referential, so it makes more sense to do this check by default and have the constraint turn off the check. I also think this is a useful check to do for loops with one edge. Infrastruktur (talk) 16:22, 17 April 2025 (UTC)

Thanks for flagging this, The Anome. This ties directly into T224837, as Matěj noted, and I’ll update the ticket with this use case and request it be prioritized. Infrastruktur also suggested inverting the check - so I’ll add that recommendation too. If anyone has other examples or edge cases, please add them in that ticket. -Mohammed Abdulai (WMDE) (talk) 18:20, 25 April 2025 (UTC)

"Description" vs "Also known as" columns hard to discern (left vs right scripts)

(Vector legacy 2010 and Vector 2022)

For example on The Ord (Q133932930) if you expand the languages box there's two latin (left to right) scripts for "Also known as" and a single Arabic (right to left) description. While upon further inspection (and using a translation tool) it's clear that the Arabic text is a description ~"Hill in Scotland", it's not immediately clear that's the case. I believe it's possible that someone could confuse the Arabic description for the Arabic name of the object, especially if they're not familiar with the Wikidata user interface.

It's likely the case that there are other items with more language descriptions & Also known as aliases where this is clearer, but I thinks it's worth flagging this as a potential vector for confusion solely based on that item in it's present state.

A dividing line between the columns would be my first suggestion, although I can't imagine it would look pretty. Please let me know if I'm not being clear or if other examples are needed to illustrate my point. :) Tæppa (talk) 09:30, 20 April 2025 (UTC)

Hi @Tæppa, you’re right. In mixed-script contexts it’s tricky to tell which column is which. Before we loop in the UI team, could other editors share whether this is an issue for them or not. Please let us know here. -Mohammed Abdulai (WMDE) (talk) 18:43, 25 April 2025 (UTC)

Perhaps instead of a global UI modification a special "Preferences>Appearance" setting could be what's needed, where other applications/websites might have a set of "accessible" features to help visually impaired people. I think in this specific context it might benefit dyslexic people to have an option to have a line between the different columns.

For context, the item I linked to has since been updated, this is what it looked like when there was only an Arabic description with Latin script aliases:

https://www.wikidata.org/w/index.php?title=Q133932930&oldid=2339443236 Tæppa (talk) 02:12, 26 April 2025 (UTC)

Can't load L470

See Wikidata:Project_chat#Property_proposal_page_crashes_Wikidata?. The issue appears to be with L470. I cannot access the page, its history, or even the raw JSON. Bovlb (talk) 01:55, 28 April 2025 (UTC)

Lexeme:L470 - I see the same. ArthurPSmith (talk) 01:58, 28 April 2025 (UTC)

It loads for me now. I think this is caused by #I_cant_edit_research_projects_that_contributed_to_this_data_set_(P13459), judging from this comment and this edit. --Matěj Suchánek (talk) 06:35, 28 April 2025 (UTC)

SPARQL query for family name (P734) of Adam (Q70899) returns both "no value" and "unknown value"

Moved to Wikidata:Report a technical problem/WDQS and Search Lucas Werkmeister (WMDE) (talk) 09:03, 6 May 2025 (UTC)

UI issue with Vector 2010

Tracked in Phabricator
Task T393641
Resolved

Since today, there is a display issue with the suggested properties when using the Vector 2010 skin. They are all greyed out. Please refer to the attached screenshot for more details. Ayack (talk) 07:39, 8 May 2025 (UTC)

Yes this unfortunately broke as a side effect of making dark-mode work on Wikidata. The ticket to fix it is phab:T393641. Lydia Pintscher (WMDE) (talk) 08:25, 9 May 2025 (UTC)

@ symbol doesn't render in infoboxes in dark mode

(I've checked Vector Legacy 2010 & Vector 2022)

Per title, example @ the warning box on https://www.wikidata.org/wiki/Wikidata:Administrators%27_noticeboard (was curious about how many undeletion requests are there). The text, when copy pasting, reads "... Contact [...] or email oversightwikidata.org [...]." (where I've removed irrelevant text) however in dark mode the @ symbol is jet black (not the off-black seemingly used as the background of the infobox) and seemingly doesn't even copy correctly.

This may prevent some people from figuring out it's an email, and it's possible the issue expands to other "special symbols" in other contexts. I note that full stops and commas { . , ) are the same colour as the letters.

On 3 May 2025 @Physikerwelt: posted in the project chat (link here, will update if it archives), mentioning "MathML will be used to render math expressions". I wonder if this will fix this issue or if it's an adjacent issue you could advise on?

Cheers, Tæppa (talk) 03:56, 10 May 2025 (UTC)

This is not related to rendering of math. Physikerwelt (talk) 08:22, 11 May 2025 (UTC)

That @ sign is added by {{@}}. It looks like that template already has support for Vector 2022’s dark mode, but seemingly not for the dark mode gadget that you’re probably using. (FWIW, I think we’re relatively close to being able to enable Vector 2022’s dark mode on Wikidata.) Lucas Werkmeister (WMDE) (talk) 08:38, 12 May 2025 (UTC)

Cheers. If it's simply a known problem of the dark mode gadget (I use the default one in preferences) interacting with templates then I think this issue is resolved and can be archived. I also see now you use the template to prevent email addresses being scraped, which is understandable. Tæppa (talk) 04:18, 13 May 2025 (UTC)