Will XLIFF support be fixed?
The Storyline translation article states that XLIFF is one of the export/import options for localization. However, there's another article that says it doesn't work.
This functionality is very important to VMware. Translating Excel files with a "Do not translate" column is very awkward. Most localization vendors will use a translation management system to process such files. When Excel files are parsed for translation ALL text will be extracted for translation, including the "do not translate" text. Some tools can avoid this but only if the "do not translate" text has a special format applied that the tool knows to ignore. The special format requires an additional, human pre-processing step to prepare the file, thus taking more time. When this option is not possible, the English source strings may need to be copied into another format or simply have the "do not translate" column removed before translation. In this case, a post-processing step is required to copy the translations back into the Excel file along with the "do not translate" column. This is cumbersome and can result in errors especially in the case where a translation may have accidental whitespace added such as a tab or newline that can shift translations into adjacent cells. Only a linguist can detect such errors.
My apologies for the long explanation but it is important to understand the drawbacks of this Excel format. These inconveniences may seem minor. However, consider a corporation that has more than 10 million words being translated yearly. These inconveniences really add up and result in slower time to market or increased cost.
XLIFF is an industry standard translation format and can be validated against a schema. It is highly structured and supported by all professional CAT tools and translation management systems. Most tools have filters that can process XLIFF out of the box without any pre or post-processing.
Please consider fixing support for XLIFF as this would help us to optimize our localization processes.