Jump to content

Wikidata:Report a technical problem

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

Start a new discussion

Property searching isn't language-specific

[edit]

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:

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

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)Reply
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)Reply
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)Reply
Actually I wonder if it is searching on alias rather than the property name. Secretlondon (talk) 17:23, 6 October 2026 (UTC)Reply
  • Hi folks, thank you for bringing this up. We need to check with our devs whether searching across all languages is working as designed (it most likely is!). The current behavior ensures people can find properties even if the label is missing in their language (which is especially helpful for small languages and mul), hence showing too many results can be useful rather than too few.
However, your point about the ranking is fair. Implementing language-aware ranking would be a feature request. The best result should not appear last just because it matches the label while others match aliases. If there is community support for it, we can look into improving it better. -Mohammed Abdulai (WMDE) (talk) 15:39, 20 October 2026 (UTC)Reply
I think this area is too low traffic to get a consensus, however this is one of the many usability issues for those of us who edit and add data manually. Secretlondon (talk) 10:43, 27 October 2026 (UTC)Reply

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

[edit]

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)Reply

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

MediaWiki:Wikibase-SortedProperties - external identifiers

[edit]

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)Reply

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)Reply
"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)Reply

Horace Lecoq de Boisbaudran (Horace Lecoq de Boisbaudran (Q3140465), Horace Lecoq de Boisbaudran (Q30438440))

[edit]

It’s impossible to connect this... something is getting stuck in a loop... Abraham (talk) 04:37, 14 October 2026 (UTC)Reply

These items cannot be merged, because of different sitelink to commons. maybe they can be merged on commons, then remove one of them and then merge. JAn Dudík (talk) 06:07, 14 October 2026 (UTC)Reply
This is a Commons problem because the categorisation is a mess. One links to commons:Category:Horace Lecoq de Boisbaudran, the other links to commons:Category:Horace Lecoq de Boisbaudran (artist), which is a subcategory of the first, but also the first is a subcategory of second. It's a loop! Secretlondon (talk) 10:35, 16 October 2026 (UTC)Reply
@Abraham: I have fixed the Commons problem and merged the categories. Wikidata:Project chat might have been a better venue for this. TSventon (talk) 11:23, 21 October 2026 (UTC)Reply

WDQS refused to run

[edit]

I am a bit puzzled that the shorten URL from query service embedded in a HTML page ran fine for a long time. Recently (Sep-Oct 2026), no result was returned from the query service. Embedded iframe script below:

<iframe src="https://w.wiki/4eCF" width="100%"height="500" frameborder="0"></iframe>

I have also captured a screenshot. But unsure where to attach. Will someone help decipher the issue please? Thank you very much.

jshieh (talk) 09:00, 27 October 2026 (UTC)Reply

Karolinka (plwiki:Karolinka (Smorgonie) (Q133756696), Karolinka (rejon smorgoński) (Q133756697))

[edit]

It’s impossible to connect this... something is getting stuck in a loop... Both entries describe the same location in Belarus, a part of a village Abraham (talk) 15:59, 1 November 2026 (UTC)Reply

Are you trying to merge? You cannot with links to two different articles on pl wikipedia. Secretlondon (talk) 16:23, 1 November 2026 (UTC)Reply