Description of problem:

Reinstating an old string from a Properties file should reinstate any corresponding translations, just as it does for Gettext files.

If you upload a POT file, translate it, then change one of the source strings, and push it, it is considered to be a new string.  The translation becomes hidden, but it is available as part of the translation memory.

If you later resurrect/reinstate the source string (eg by pushing the original POT file again), the corresponding translation is reinstated automatically.  This makes pushing source files quite safe, because if you make a mistake, you can always push the old source file and get back your translations.

However, this is not true for project which contain XLIFF/Properties files.  

Because the resId is the same as the trans-unit id (in XLIFF) or the property key, the new source string is recognised as a new version of the same textflow.  (This is something we can't do with POT files.)  When it happens for XLIFF/Properties files, we keep the translation of the old source string, and we mark it fuzzy, because if the source string is similar, the translation is probably similar too, which should make this a good fuzzy match.

The problem is, if the earlier source string is uploaded again (eg by pushing the original Properties file), we leave the translation as it is.  (Actually, if the new string has been translated, we mark the new translation as fuzzy.)  What we should do is resurrect the translation which previously applied to this source string.