Page MenuHomePhabricator

PropertySuggester does not show labels from fallback languages
Closed, DuplicatePublic


As a Wikidata editor, when adding new statements, I want to be able to understand which properties PropertySuggester is suggesting to me.

PropertySuggester doesn’t seem to return labels from fallback languages right now.

When adding a new statement on**en-ca**

The first four suggested properties have Canadian English labels; the other three do not, but they do have English labels, which should be used instead.

Request URL:



Acceptance criteria:

  • PropertySuggester suggestions show labels from fallback languages

Open questions:

Event Timeline

orangensaft on IRC also reports that labels are not shown after typing in a property ID (example: P186), but I haven’t been able to reproduce that yet.

That seems to trigger two API requests for some reason:

Though as far as I can tell, both of them return the label correctly. But still, maybe one of them sometimes doesn’t, and there’s a race condition which makes this harder to reproduce because half the time the API which isn’t broken wins?

Probably the same as the ancient task T112112?

It's not, right now, if you even right "GeoNames" in the box, you will still get P1566 for en-ca while you shouldn't (according to task description of the task you linked)

Confirming it is not an issue with the new store.

mysql:research@dbstore1005.eqiad.wmnet [wikidatawiki]> SELECT
    ->   wbpt_property_id as id,
    ->   wby_name as type,
    ->   wbxl_language as language,
    ->   wbx_text as text
    -> FROM wbt_property_terms
    -> LEFT JOIN wbt_term_in_lang ON wbpt_term_in_lang_id = wbtl_id
    -> LEFT JOIN wbt_type ON wbtl_type_id = wby_id
    -> LEFT JOIN wbt_text_in_lang ON wbtl_text_in_lang_id = wbxl_id
    -> LEFT JOIN wbt_text ON wbxl_text_id = wbx_id
    -> WHERE wbpt_property_id = 1566
    -> AND wby_name = 'label'
    -> AND wbxl_language = 'en';
| id   | type  | language | text        |
| 1566 | label | en       | GeoNames ID |
1 row in set (0.01 sec)

I managed to get a local reproduction so will keep digging

I dont believe this is a regression, at least not recently.

The same behaviour occurs for suggestions when using REL1_34

The code (for at least 6 years) appears to only ever have retrieved the requested language code.

The other behaviour is appears to be the fallback to search when not enough suggestions appear.
Example below using the exact same code

Moving out of the immediate campsite board and if a behaviour change is desired it can go through the normal product process & prioritization :)

Addshore lowered the priority of this task from High to Medium.

If a change in behaviour was seen it was likely due to the most recent batch of suggestions being loaded in T132839#5822858
As if something is suggested it will have fallback langs.
If something is not suggested and instead comes from the fallback search, then it will have fallback langs.