translated strings counts translations that may not be translated in Launchpad anymore

Carlos, I am not sure I understand this one. I suspect it's a duplicate of #173527, which we've discussed in #165218, but I'll wait for you to confirm that.

No, is not the same thing, In fact, i'm not sure it's really a bug, that's why I said that we should validate it.

The possible problem I see is that we get a message fully translated from upstream (packaged or imported) and, for some reason, someone removes its translation in Launchpad. Current statistics use what we got from upstream as the base 'translated' number and then, we add the new translated in Launchpad to get the total. In the case I just explained, we would still count that untranslated string as translated because we use the imported one as the base.

Is that more clear now?

Just some notes:

Such "double counting" would have to show up as an overlap between the current-count and the rosetta-count. (The two are added up to form the translated-count). There's an "AND NOT EXISTS"-style clause in the rosetta-count code that excludes messages that have an imported equivalent (which would already be included in in current-count). That clause is quite similar to the "WHERE" clause for current-count. So my impression is that this kind of overlap doesn't happen.

The most noticeable difference between the conditions for inclusion in current-count and exclusion from rosetta-count is that current-count includes only complete messages, whereas rosetta-count looks for imported ones that have _at least one_ plural form translated. But I think that's correct, since an incomplete translation doesn't really belong in the translated-count anyway.

Well, Carlos' point is that a string would not be translated in Launchpad (thus, not included in rosettaCount), yet translated upstream (and included in currentCount). So, a string which is not really translated is now counted as translated by a mere addition of rosettaCount and currentCount, and translatedCount ends up being 1 larger than it should be.

It sounds very likely that this is a problem in current RosettaStats code.

updateStatistics code in message sharing switchover code fixes this bug.

Fix for this was committed with message-sharing-switchover work.