Problem

When an SDLXLIFF containing locked inline content is imported, pretranslated in translate5, and exported again, the exported file is corrupt and can no longer be opened in the originating CAT tool:

  ▎ Corrupt file: Missing locked content for 'Oasis.Xliff12.x'
  ▎ (error raised while parsing locked placeholders)

  In SDLXLIFF, locked (non-editable) content is rendered as <x id="lockedN" xid="lockTU_…"/> placeholders that reference dedicated lockTU_* trans-units. <source>, <seg-source> and <target> each have their own
  placeholder ids and their own lockTU_* trans-units, even though the locked content is identical.

  The affected segments are origin="not-translated" but already contain a valid target locked structure on import. Pretranslation only checks for translatable text, treats them as empty, and rebuilds the target from the
  source - discarding the target's own locked placeholders.

  Example (segment c9054c1e…, showing 2 of 4 locked placeholders):

  On import - seg-source and target have different placeholder ids and different lockTU_ (the valid SDLXLIFF shape):

  <seg-source>
    <x id="locked5" xid="lockTU_d9e9975d…"/>   <!-- source side -->
    <x id="locked6" xid="lockTU_ddcb0358…"/>
  </seg-source>
  <target>                                      <!-- origin="not-translated" -->
    <x id="locked9"  xid="lockTU_66781252…"/>  <!-- target's OWN ids + OWN lockTU -->
    <x id="locked10" xid="lockTU_73e2be48…"/>
  </target>

  After pretranslation + export - the target has been rebuilt from the source, so it now carries seg-source's ids (locked5/6), and the export regenerated fresh lockTU_:

  <seg-source>
    <x id="locked5" xid="lockTU_d9e9975d…"/>   <!-- unchanged -->
    <x id="locked6" xid="lockTU_ddcb0358…"/>
  </seg-source>
  <target>
    <x id="locked5" xid="lockTU_a0844b39…"/>   <!-- id now = seg-source's locked5; xid is brand-new -->
    <x id="locked6" xid="lockTU_cdbe38b6…"/>
  </target> 

  What goes wrong for this single segment:
  1. Pretranslation copies the source's locked placeholders into the target, so the target reuses the seg-source placeholder ids (locked5/6) instead of its own (locked9/10).
  2. Because seg-source and target now reference the same lockTU_ , RepairLockedReferences regenerates new lockTU_ trans-units for the target (in the full segment: lockTU_ count 12 -> 16).
  3. The target's original lockTU_* trans-units (lockTU_66781252…, lockTU_73e2be48…) are left orphaned (defined but referenced 0×).

  The reused placeholder ids and regenerated lockTU_* blocks break the editor's internal locked-content mapping, which expects the target to keep its own locked9/10 -> lockTU_66781252… references.

Solution

We will have to first test somehow the solution in the other tool.  Simple import of 2 files will validate if it works or not. The first file is the one containing the bug, and the second one is one pre-translated in translate5 and then exported. If the export works this is the solution.