Opened 6 years ago

Closed 4 years ago

#3397 closed defect (bug) (worksforme)

Translate: Plugins listed on Waiting filter not part of general Plugins list

Reported by: garrett-eclipse's profile garrett-eclipse Owned by:
Milestone: Priority: normal
Component: Translate Site & Plugins Keywords:



This is quite minor but I noticed there was two plugins listed in the Waiting view when I got to the en_CA page;
Screen -

They both (Admin Footer Version && JSM's Force SSL / HTTPS) are at 96% so would expect them at the top of the Plugins view when the filter is set to 'Percent Completed (most first)', but I don't find either of them there so it seems they get removed from the general list;
Screen -


Attachments (2)

Screen Shot 2018-01-22 at 2.22.36 PM.png (316.9 KB) - added by garrett-eclipse 6 years ago.
Waiting View
Screen Shot 2018-01-22 at 2.22.22 PM.png (356.3 KB) - added by garrett-eclipse 6 years ago.
Plugins Percent Completed Most First

Download all attachments as: .zip

Change History (11)

6 years ago

Plugins Percent Completed Most First

#1 @obenland
6 years ago

Maybe they get dropped from that view because they have waiting/fuzzy strings? It looks like none of the plugins there have more than 0.

Maybe @dd32 knows?

#2 @dd32
6 years ago

This is probably a data-sync issue (which might sort it self out in a few hours) - Querying GlotPress is super slow so there's an extra table which gets sync'd on a cron or after a translation event occurs which the sorting is based upon.

Unfortunately Debug Bar doesn't work on translate for me right now, so I can't see the queries to debug it right this moment.

#3 @garrett-eclipse
6 years ago

Thanks @dd32
I'll leave these untouched for now. How long should I leave this before it's deemed to not be a sync issue?

Since I last checked on the Waiting tab I now see the WordPress for iOS, and looking at the Apps tab it's listed there with the same percent;

And on the Percent Complete list there's another plugin that wasn't there before but not the two that are in the Waiting queue.

I'll check back on this tomorrow and let you know if any more discrepencies.


#4 @dd32
6 years ago

This is indeed a data-sync error of some form, but I don't know what exactly.


  • only shows plugins which are untranslated strings, A 100% translated plugin will not show here.
  • The plugins in question have no untranslated strings in the DB table. I believe that's as a waiting string doesn't count as untranslated. There's a bit of bad logic behind it, that we can't really avoid. If "StringA" is untranslated, but there's a waiting translation for "StringB" (which is already translated) it'll have untranslated = 0, waiting = 1, even though it should be untranslated = 1, waiting = 1. That's due to how impossible it is to query GlotPress for this data.

After looking at this, I don't think there's anything to fix here, activity on translating the plugins will probably fix any issues and the cron job (which I have no idea when it runs) will probably catch the rest.

The queries behind these filters are taking 20-30s each for me, so I'd be more inclined to remove these filters than change it.

#5 follow-up: @garrett-eclipse
6 years ago

Thanks @dd32 I appreciate you looking into this.
Would it make sense to open a ticket with GlotPress to prompt a revisit on the GlotPress handling of data in these cases?

#6 in reply to: ↑ 5 @dd32
6 years ago

Replying to garrett-eclipse:

Thanks @dd32 I appreciate you looking into this.
Would it make sense to open a ticket with GlotPress to prompt a revisit on the GlotPress handling of data in these cases?

Nah, there's nothing wrong with how GlotPress is storing data, it's just that you can't sort/filter by these kind of data points with any ease when you have 90k Projects with 170 languages (inc variants) providing 5 million original strings and 50 million translations :)

Unfortunately that all actually means our summary table has ended up at 14million rows too (90k Projects x 170 languages) which affects query performance as well.
We probably need to re-do our summary table to account for inactive projects (ie. so that if Plugin A in language X has no activity, it's not in the summary table affecting performance of other queries)

#7 @garrett-eclipse
6 years ago

Sounds good @dd32... well actually sounds overwhelming ;) but I'll leave performance optimizations to you. I do like the concept of dropping inactive projects from the queries, maybe they can be segregated into their own tab removing them from the main filters but still having them accessible.

This ticket was mentioned in Slack in #polyglots by ocean90. View the logs.

6 years ago

#9 @dd32
4 years ago

  • Resolution set to worksforme
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.