Page MenuHomePhabricator

PropertySuggester does not show labels from fallback languages
Closed, DuplicatePublic

Description

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

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

Example:
When adding a new statement on https://www.wikidata.org/wiki/Q4115189?uselang=**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: https://www.wikidata.org/w/api.php?action=wbsgetsuggestions&search=&context=item&format=json&language=en-ca&entity=Q4115189

Screenshots/mockups:

BDD
GIVEN
AND
WHEN
AND
THEN
AND

Acceptance criteria:

  • PropertySuggester suggestions show labels from fallback languages

Open questions:

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 23 2020, 5:14 PM

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?

Restricted Application added a project: User-Addshore. · View Herald TranscriptJan 24 2020, 7:44 AM

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)

It works fine locally:

Macro ops-problems:

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.
https://github.com/wikimedia/mediawiki-extensions-PropertySuggester/blame/bbc3d8f5778f8b3e72f83a3e324b05d8da317598/src/PropertySuggester/ResultBuilder.php#L41

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 removed Addshore as the assignee of this task.Jan 24 2020, 10:35 AM
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.