Wikidata

Wikidata:Report a technical problem/Archive/2022/10

< Wikidata:Report a technical problem‎ | Archive‎ | 2022
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.


CIDR notation in deleted contributions

With Special:Contributions, we can use CIDR notation, e.g. Special:Contributions/5.210.73.6/24, but with SpecialDeletedContributions we cannot (e.g. Special:DeletedContributions/5.210.73.6/24). This would be extremely useful for tracking spammers. Would it be hard to make this work? Thanks, Bovlb (talk) 22:03, 1 October 2022 (UTC)

Having dealt with a similar question recently, I think this is not easily possible. CIDR searching works via mw:Manual:Ip changes table which does not hold information about deleted revisions as much as I am aware. —MisterSynergy (talk) 18:09, 2 October 2022 (UTC)

Search of structured discussions

Many users and some central noticeboards are using structured discussions. As I understand it, these are invisible to search, which seems like a problem. I am informed that the configuration parameter $wgFlowSearchEnabled might resolve this, but it's technically experimental. What do people think? Bovlb (talk) 15:35, 26 September 2022 (UTC)

I’m afraid it’s not that simple – the experimental code for supporting search in Flow was so badly broken that it was recently removed entirely (T317513). Lucas Werkmeister (WMDE) (talk) 16:02, 26 September 2022 (UTC)
@ Lucas Werkmeister (WMDE): That's a pity. Is there any way to boost the priority of resolving this? Bovlb (talk) 16:26, 26 September 2022 (UTC)
I understand that Flow was dropped in favor of the new talk page interface, but there are several use cases where Flow is more practical (especially in entreprise wiki). +1 on my part for resuming development on that wonderful extension. We're even willing to devote some coding resources to it if the WMF is on board with the project. Tinss (talk) 17:55, 26 September 2022 (UTC)
@Lucas Werkmeister (WMDE) 2600:6C5D:200:6C83:5E0:C5BC:1003:57FB 04:54, 3 October 2022 (UTC)
As far as I’m aware, mw:Extension:Flow is considered a technological dead end (you can see traces of this on-wiki too, e.g. in how Topic histories and diffs look nothing like those of other pages). I wouldn’t expect anyone at the WMF to be excited about putting more work into it, to be honest. (As someone who’s previously converted his own talk page to Flow, I hope that there’s some kind of plan for the longer-term future of existing Flow pages, perhaps by converting them back into regular wikitext pages, but I don’t know anything about that.) Lucas Werkmeister (WMDE) (talk) 12:35, 4 October 2022 (UTC)
Technological dead end it may be, it is in use in many places. We either need to support it or to have a transition strategy.
While we're at it, it appears that structured discussions may not generate appropriate variables for the abuse filter, making it impossible to apply abuse filters to all user talk pages. Bovlb (talk) 15:37, 4 October 2022 (UTC)
Indeed, it may be dead to the WMF, but it's user-friendliness (it uses patterns that are commonplace elsewhere on the web) makes it a very good choice for enterprise wiki. At least it works for now so the status-quo can be maintained. If support for it ends up being dropped entirely, coding a conversion maintenance script would not be too difficult for me. @Bovlb, if you are willing to get the search and abuse filter working again on Structured Discussions, I can be your code reviewer on gerrit. Tinss (talk) 16:01, 5 October 2022 (UTC)

iOS Safari or Chrome cannot add statements

Using a iOS mobile device; using either Chrome or Safari browsers, the option to add statements to a wikidata entry is not available- no "+" sign or whatever. Can create an entry but once created I cannot add statements. I can modify the description, but no way to add properties.  – The preceding unsigned comment was added by Muell132 (talk • contribs).

This might explain why we see so many empty items being created. Bovlb (talk) 15:23, 5 October 2022 (UTC)

Changes in search result display

There is a discussion at Wikidata:Project_chat#changes_in_search_result_display that would benefit from input from technical staff. Please discuss there, not here. Bovlb (talk) 16:29, 7 October 2022 (UTC)

Error during merge of Measurement of the Higgs boson mass from the H → γ γ and H → Z Z * → 4 ℓ channels in p p collisions at center-of-mass energies of 7 and 8 TeV with the ATLAS detector (Q27349821) and Measurement of the Higgs boson mass from the H → γ γ and H → Z Z * → 4 ℓ channels in p p collisions at center-of-mass energies of 7 and 8 TeV with the ATLAS detector (Q110449462)

As reported here, it's not possible to merge Measurement of the Higgs boson mass from the H → γ γ and H → Z Z * → 4 ℓ channels in p p collisions at center-of-mass energies of 7 and 8 TeV with the ATLAS detector (Q27349821) and Measurement of the Higgs boson mass from the H → γ γ and H → Z Z * → 4 ℓ channels in p p collisions at center-of-mass energies of 7 and 8 TeV with the ATLAS detector (Q110449462). The error we get is: [2a3948e9-31f8-4326-aec2-2bde42c811f3] Caught exception of type Wikibase\Lib\Store\EntityContentTooBigException. Mbch331 (talk) 11:12, 15 October 2022 (UTC)

@Mbch331: These items are very big. Try removing some statements on one of them, or blanking it completely before merging. -Mohammed Sadat (WMDE) (talk) 11:09, 17 October 2022 (UTC)
It did help. Finally managed to merge them. Mbch331 (talk) 20:44, 17 October 2022 (UTC)

Korean search method is inconvenient, it's problem to search

Can I change the related settings? or should I ask to sysops?

I searched some words in Korean on wikidata, but many results bring only spaced words, like many european languages. Korean language is not separated by only spacing. it's same with other east asian languages, like Chinese or Japanese. for example, when I search "北京"(Beijing), it will bring "北京站"(Beijing station) and "北京大学"(Beijing university) etc.

but current wikidata search system is very different general Korean search system. for example, I want search about "제넷" it means "genet", but many names are not spaced. "유럽제넷"(Common genet), "케이프제넷"(Cape genet), "서발린제넷"(Servaline genet) etc... when I searched these things, the search engine bring to me only a word with a spaced, like "제넷 골드스타인"(Jenette Goldstein)

it's very fatal to search in Korean languages. one of problem, for search more efficiently, every time search with Korean word with postposition. if I search about "포유류"(mammals), I can't get many search results. Korean language is a agglutinative language, people have to put a lot of postposition combine on it to search properly in this kind of environment. like "포유류의"(of' mammal), "포유류에"(in mammal), "포유류에게"(to mammal) etc.

This search system is very inefficient to Korean. I want to Korean search system in the same way as Chinese and Japanese, but I can't find the related settings. other languages that use the same system as Korean can do the same. I want to make Wikidata a more convenient site for future users. Thank you for reading this long article! ―파란여우 (BlueFox) (토론 (talk)) 13:02, 15 October 2022 (UTC)

@AquAFox: Thanks for bringing this issue to our attention. How are you performing the search: are you using the entity suggester at the top or Special:Search? -Mohammed Sadat (WMDE) (talk) 11:12, 17 October 2022 (UTC)
I used Special:Search. Thank you for your answer! ―파란여우 (BlueFox) (토론 (talk)) 12:10, 17 October 2022 (UTC)
I asked because the Search platform team at the Wikimedia Foundation handles Special:Search. Let's move this conversation to WDQS and Search. -Mohammed Sadat (WMDE) (talk) 15:42, 20 October 2022 (UTC)

in query service ui, linechar view mode, tip flash all the time.

in my query, when i move a mouse to any data point, the tip will flash all the time, which will be stopped only if i move mouse just above the data point. is there a solution for this? 240E:390:987:7C91:880D:A8F8:3D11:35B7 14:48, 31 October 2022 (UTC)

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Report_a_technical_problem/Archive/2022/10&oldid=1776473212"