What to do when this dreaded message stops you from opening the xliff or creating the target file (Save Target As) of your meticulously translated, edited, and QA-checked translation? Workarounds exist, but most are time-consuming and can allow errors to weasel their way into your translation. Here’s how to proceed and how to stop this error message once and for all:
Which fix you need boils down to whether you have access to the original source file, i.e., whether you saved the source document into Studio yourself or whether you opened a package you received.
Open xliff/create target file: single file (not part of a package sent to you)
Click “Yes” in response to the error’s question “Would you like to browse for this file” and select the original source file (i.e., .docx). You have to click the drop-down arrow to the right of the “Field name” or you can type “*” into the Field name area itself, otherwise you will not see your original file in the folder. [Make sure to click “Save” after the file opens in the Editor view if everything looks as you last left it.] To create target: If you have followed the steps explained here, you should now be able to “Save Target As” and create your clean target file. If not, see the helpful resources at the bottom of this article for possible workarounds.
Open xliff/create target file: package file
Click “No” in response to the error’s question “Would you like to browse for this file” and start working on the translation as usual within the Editor. Not all source files are automatically attached to a package, i.e., embedded into the xliff file, especially if they are larger files. You can ask the project manager who sent the package to send the source file. However, not being able to Preview or create target file (Save Target As) does not impact the package for delivery. Everything still comes through without errors for the project manager when you create and send your return package.
Helpful hint: For peace of mind, before you deliver the package with your completed translation, choose “Save Copy As” and save the xliff directly to your computer’s hard drive away from Studio-default storage locations (e.g., I save mine under Customer > Date-PO number > “Delivered”) for easy access to my final xliff should anything go wrong with project delivery or I need it to create a clean Translation Memory. [I also save my Return package to this same location so everything is organized.]
To address the issue upfront with any other packages this project manager might send you that include larger source files, you can ask the PM to increase the embedding size: File > Options > File Types > SDL XLIFF > General > Embedding [increase from default 20MB to its maximum of 100MB]. Once the PM makes this setting change, you shouldn’t ever see the “Dependency file not found” error in other packages from this PM provided the error was triggered by larger source documents.
What causes this error and how can I stop it from happening?
The “Dependency file not found” error is mostly caused by files being deleted that Studio needs in order to function properly. In the case of a non-package file situation, this is likely caused by your anti-virus software. When your computer is idle, your anti-virus software scans for temporary files and ends up deleting some that Studio needs. For Norton users, here is the easiest way to fix this: Open Norton interface > Click “Settings” > Tasks Scheduling > Uncheck “Windows Temporary Files” under Automatic Tasks > Apply > Close. SDL also lists exceptions that you can create under Task scheduling for certain folders. See KB# 3897.