Translations statistics not being updated

The verify-pofile-stats and verify-pofile-stats-daily seem to have been disabled without replacement. That would be a serious problem for the Translations app.

We do have POFileStatsJob now, but those seem to be generated only for a POFile that has just had a translations editing form submitted. I don't see any code to update statistics for the other POFiles for the same language in the same sharing set. We relied on the statistics updater to maintain those, since doing it inline would have slowed down the page too much. We updated just the view's POFile so that at least statistics would reflect a user's latest changes — something that we seem to have lost with the introduction of POFileStatsJob.

(The script also had another purpose: it may be possible for database isolation paradoxes to skew statistics. It's a healthy thing to scrub such data from time to time)

Meanwhile, it also looks as if the imports code in POFile and POTemplate was never converted to use POFileStatsJob. The updates made there also need to trigger statistics updates for sharing templates. What we have now is needlessly asymmetric — fix the problem in one place and it remains in the other places.

This brings into question the design of POFileStatsJob. It updates the statistics for a single POFile, but when do we ever need that? It's always an entire sharing set (either in a given language or in all languages) that needs to be updated. Looking up the extent of that set before creating multiple jobs would defeat at least part of the jobs' purpose: to offload the work to an offline process.

So a POFileStatsJob ought to cover an entire sharing set, not just one POFile. The problem there is that a sharing set is an emergent property of a POTemplate, without a good identifier. We could use a POFile as a representative of a sharing set and make the job update stats for the entire set, but that would leave the POTemplate import code to figure out exactly what POFiles to update — a fairly complex and expensive job.

A more direct approximation could be “source package name or product, template name, optional language.” But our existing sharing-set code was made to find sharing templates; using those to map out the higher-level contexts is probably putting the cart before the horse.

Perhaps the best we could do is to make POFileStatsJob hold a representative POTemplate, plus an optional Language. The job itself can figure out the rest from there.