Implement entity de-obsoletion

[functionzz]

In the recently merged #3965, we implemented Resource obsoletion and de-obsoletion. The next step is to work on Entity de-obsoletion following the de-obsoletion of a Resource.

The entities which are the same between the Resource that exists in Pontoon (Resource A) and the one that is being "added back in" via sync (Resource B) should be de-obsoleted. Entities that do not exist in Resource A should be created.

Further discussion is likely needed on the particulars of the implementation and design.

UPDATE: May 8, 2026 at 0745 UTC by @mathjazz (simplified the proposal)

[eemeli]

@flodolo I have a vague recollection of some prior discussion from around the time of the sync refactor work that we would not be implementing entity de-obsoletion, but relying instead on translation memory for entities that go away and then come back (which is what we're now doing).

Should the work proposed here be done, changing the current situation?

[flodolo]

I think I have a follow-up question: are we checking that the entity is exactly the same before deobsoleting it, or just relying on the identifier? The latter would be problematic.

[mathjazz]

I think I have a follow-up question: are we checking that the entity is exactly the same before deobsoleting it, or just relying on the identifier? The latter would be problematic.

We should also check the content.

[awakenwithamber]

In the recently merged #3965, we implemented Resource obsoletion and de-obsoletion. The next step is to work on Entity de-obsoletion following the de-obsoletion of a Resource.

The entities which are the same between the Resource that exists in Pontoon (Resource A) and the one that is being "added back in" via sync (Resource B) should be de-obsoleted. Entities that do not exist in Resource A should be created.

Further discussion is likely needed on the particulars of the implementation and design.

UPDATE: May 8, 2026 at 0745 UTC by @mathjazz (simplified the proposal)

This is a fantastic next step and exactly how I believe Entity restoration should work.

When a previously obsolete Resource is reintroduced through sync (Resource B), the system should compare its entities against the corresponding Resource already stored in Pontoon (Resource A).

For any entities that already exist in Resource A and match entities from Resource B, those entities should simply be de-obsoleted rather than recreated. This preserves their existing translations, history, comments, approvals, and metadata while restoring them to active status.

If an entity exists in Resource B but does not exist in Resource A, a new Entity should be created as part of the sync process.

This approach mirrors the Resource de-obsoletion logic implemented in #3965 and ensures that valuable translation work is retained whenever strings are reintroduced after being temporarily removed.

In summary:

1. Compare entities from the synced Resource (Resource B) to the existing obsolete Resource in Pontoon (Resource A).
2. Matching entities should be de-obsoleted.
3. Non-matching entities should be created as new.
4. Existing translations and metadata should remain intact for restored entities.

I agree that some additional discussion may be helpful regarding how entity matching should be determined (for example by key, string, path, or other identifying attributes), but the overall proposal is clear, logical, and consistent with how translators would expect restored content to behave.

This enhancement would prevent unnecessary loss of translation history and make synchronization significantly more robust.