Not Considering

Hi - as Paul says, this is a process issue ("get it right at the source") and it might be impossible to address in the PDF filter in the CAT tool. It's of course unfortunate that this mindset is not a given in today's organizations ("we should always send source files to translation") but it's probably difficult if not impossible to address this downstream in the CAT Tool rather than upstream in an organization's process.

Support for list item values in Interactive PDF forms

We are an in-house translation department at a large organisation, and we are often asked to translate blank PDF forms for distribution in various languages. We have found that Studio (2022 SR1) does not handle Interactive PDF forms in the same way as PDF forms that were created on the basis of a Word form that was subsequently converted to PDF.

Interactive PDFs are PDF files to which interactive elements such as form fields are added afterwards, for example in Adobe Acrobat Pro. (See https://www.adobe.com/acrobat/hub/how-to-make-a-pdf-interactive.html#:~:text=Interactive%20PDFs%20are%20documents%20that,for%20teachers%20and%20instructional%20designers.) 

Example

Say we get a PDF form with field "Are special safety measures required?" where the user can choose "Yes", "No" or "To be assessed" from a dropdown list. The default option is "Yes":

If the PDF form was originally an MS Word form, you can get Studio to present "Yes", "No" and "To be assessed" as segments for translation in the project, and your target file will contain the translated field including a choice of those three options, of which "Yes" is selected by default but the user of the translated form can change it to "No" or to "To be assessed".

(This behaviour is controlled by the Common option "List item values" for Content Controls in file type settings for PDF files.)

By contrast, if the PDF form was created as an Interactive PDF form (see attached example PDF file), the resulting Studio project only includes a segment for "Yes" (= the default value), and the target file does not offer the functionality to change that to "No" or to "To be assessed".

With a simple 3-entry list, that's not a huge problem, but some of the forms we are asked to translate contain numerous lists containing up to 50 options. Our current workaround takes hours and is very error-prone: we create a separate file for list values, where me manually type all the list item values that are needed for the translation. We add that file to the project for translation. When we generate the final target file, we manually re-create each dropdown field and add all the list item values one by one.

PDF

  • I think Interactive PDFs should be considered a different file type - a file type that Studio currently doesn't support.

  • Yes, unfortunately our organisation is huge and we simply can't control the applications that people use to create the documents that we end up translating. We do ask for Word files if available, but sometimes the document was created quite a while ago by someone who no longer works in the same position or has left the organisation; and sometimes they used Adobe Acrobat / Adobe Forms instead of Word. (I also suspect that SAP offers - or used to offer - functionality to create online forms and they come out as Interactive PDFs.)

  •  

    I don't know how complex this would be given a PDF can be created from any file and may even offer form support from any format, and then the format you get from translating is always Word irrespective of what the original format was.  So I think this isn't anything we would do... although  may offer a better response.

    I think the best approach, especially if you have the Word file is always to translate the Word and not the PDF.  PDF translation should be a last resort.