One of the ways to translate LiveCycle Designer PDFs is using XLIFF. Since an XDP file is essentially an XML file the process is to run an XSLT transformation over the XDP to extract all the text strings. Not just the captions, but also all the tooltips, screenreader texts, image alt’s etc. Then you can send the generated document with strings to a translator, and some time later you get a translation back that you can merge into your template using a different XSLT transformation. The whole process is described pretty well in Using XLIFF for translating Adobe® LiveCycle® Designer ES form designs on Adobe DevNet.
While putting together a few extra exercises for the LiveCycle ES2 Designer Specialist training I stumbled over something weird in the XSLT templates from Adobe. While the tools for translating XLIFF files all presume the original string is in the source element and the translated string is in the target element, the Adobe XSLT templates presume the translated string is put back into the source element. So for an English to Dutch translation tools create:
<trans-unit id="09DD30F3-CE03-4FF1-92D3-067126FF904E" resname="09DD30F3-CE03-4FF1-92D3-067126FF904E">
<source>Awesome!</source>
<target>Keigaaf!</target>
</trans-unit>
But the XSLT templates Adobe distributes with LiveCycle Designer (look in the%programfiles%\Adobe\Adobe LiveCycle Workbench ES2\Adobe LiveCycle Designer ES2\FormTranslation\ folder) expect:
<trans-unit id="09DD30F3-CE03-4FF1-92D3-067126FF904E" resname="09DD30F3-CE03-4FF1-92D3-067126FF904E">
<source>Keigaaf!</source>
</trans-unit>
Luckily this is easy to fix (once you figure out what is going on) by changing the XSLT template for merging the translations back into the XDP file to select the target node instead of the source node at line 66 of mergestrings.xslt:
<xslt:variable name="translatedNode" select="$s2x[@id=$idToGet][1]/target" />
A version of mergestrings.xslt with this change is available for download.