Page MenuHomePhabricator

Tags with no label in the UI language should still be posted to the API with status "not-displayed"
Closed, ResolvedPublic

Description

We're currently filtering out suggestions with no text, i.e. no label in the user's UI language. This is causing those tags to maintain a status of 0 (unreviewed) after other tags have been published for an image, while all tags visible to the user will have a status of -1 or 1. Since we're querying for images with at least one tag in state 0, images that have been previously tagged may show up in the CAT tool, with no tags to show to the user, causing confusion.

We need to remove text-less suggestions from the UI but submit them as "not-displayed" to the API if the user submits other tags.

Event Timeline

AnneT created this task.Apr 20 2020, 7:17 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 20 2020, 7:17 PM
AnneT renamed this task from Tags with no label in the UI language should still be posted to the API when other tags are published to Tags with no label in the UI language should still be posted to the API with status "not-displayed".Apr 20 2020, 8:27 PM
AnneT updated the task description. (Show Details)
AnneT updated the task description. (Show Details)

Change 591183 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/MachineVision@master] Set review state for tags not displayed to user

https://gerrit.wikimedia.org/r/591183

Change 591183 merged by jenkins-bot:
[mediawiki/extensions/MachineVision@master] Set review state for tags not displayed to user

https://gerrit.wikimedia.org/r/591183

betalabs commons doesn't have the cases with mvl_review = '-4' ; commonswiki in production shows 71 records with mvl_review = '-4' when supposedly wmf.30 was in place:

mysql:research@dbstore1004.eqiad.wmnet [commonswiki]> select  min(from_unixtime(truncate(mvl_reviewed_time/10000, 0))) MIN_Time, max(from_unixtime(truncate(mvl_reviewed_time/10000, 0))) as MAX_Time from machine_vision_label where mvl_review='-4';
+---------------------+---------------------+
| MIN_Time            | MAX_Time            |
+---------------------+---------------------+
| 2020-04-29 13:54:17 | 2020-04-30 17:26:28 |
+---------------------+---------------------+
1 row in set (2.66 sec)
Ramsey-WMF added a subscriber: Ramsey-WMF.

How can we reliably test this on production?

Images that feature tree branches prominently seem to consistently produce the behavior. These images often come back with Q6484949 as a suggested tag, but that item no longer exists (looks like it was merged with the entry for "branch" some time back).

This image in the public queue currently has the associated non-displayable tag as one of its suggestions, if you can get to it in the popular tab: https://commons.wikimedia.org/wiki/File:Eenzame_boom_op_het_strand._Locatie_Mirnser_Klif_02.jpg

Or upload a similar image yourself and you'll probably see it.

One quick way to determine whether the MachineVision interface has detected any non-displayable tags is to navigate to Special:SuggestedTags and use the ?debug=true url params so that you can inspect the app using the Vue Devtools (you'll need to install them in your browser first). Once you've done that, you can open the Vue inspector in the sidebar and switch over to the Vuex tab, and you should be able to see an array of currentImageNonDisplayableSuggestions complete with the ID the suggestion is trying to display. Someone else will have to chime in with the best way to get the corresponding server logs after you submit votes that contain "non displayable" tags, but this is what you'll be able to see on the front-end. Also, you could check the API requests being sent from the browser to ensure that non-displayable suggestions are being handled there.

Ramsey-WMF reassigned this task from AnneT to Etonkovidova.Jun 8 2020, 4:24 PM

Hi @Etonkovidova . Please see Eric's note above for how to test this fully on production, and let him know if you have trouble 😺

Etonkovidova closed this task as Resolved.Tue, Jun 23, 12:20 AM

Thanks, @egardner
Yes, Q6484949 was merged with Q2923673.

On commonswiki wmf.37 I followed the instructions above - looking for the pictures similar to File:Eenzame_boom_op_het_strand._Locatie_Mirnser_Klif_02.jpg - and using Vue.js Dev tools.

For the image File:Fagus_sylvatica_Herbstlaub_02.JPG the result was:

currentImageNonDisplayableSuggestions:Array[1]
0:Object
alias:null
confirmed:false
custom:false
description:null
text:undefined
wikidataId:"Q6484949"

I'm marking the issue as Resolved but will do some additional checking.