Under Community Review

Identify structure mismatch during back-conversion

At present, it doesn't bother Trados if some content is missing from a translated file: the structure mismatch is not identified nor flagged by Studio during back-conversion, and  the only way to realize if the file is missing content at production level is noticing if the size of the original file sent for translation is different from that of the delivered file, which is too risky.

Only after trying to compare the file to the linguist and from the linguist did Engineering team get get an error:

 Error dialog box in Trados Studio titled 'xliffCompare' showing a structure mismatch error for a file named 'Annual Report HIV Duo_xliff.xlf from_linguist.sdlxliff'. It indicates the inability to locate the corresponding paragraph ID in the updated file.

Is there a way for the structure mismatch to be identified and flagged during back-conversion?

Daniela Aronica
Parents

  •  

    With all the many file types Studio can handle, and the amount of conversions taking place (XLSX -> XLF -> SDLXLIFF?) it's not clear to me exactly what you want Studio to do, at which point. If a translator misses translating an Exel cell there will be an error (that is the default at least). How do all these conversoins take place, and why?

    Daniel

  • in reply to Daniel Hug

      Let me give you some more context for this project specifically. The source file was an XLIFF file downloaded from XTM, and prepared on Studio to work offline. Once translation was completed, Engineering took care of importing the return package in the studio project, and generating the target XLIFF that we would later need to import back onto XTM. During back-conversion on Studio, only a few added/missing tags in segments were flagged and fixed by Engineering team but no other issues were detected. Hence, target XTM XLIFF could be generated without hiccups. We realized that there were some issues with the file because we would get errors when importing the target back on XTM.

    Upon further investigation and calls with the team, we noticed that the size of the studio file sent to the linguist was much bigger than that of the file received by the linguist: for some reason many segments were missing in their return package, and this was never flagged by Studio. I was wondering if there was any way that Studio could flag that segments are missing in a return package, perhaps without allowing to generate the target file and giving an error, instead?

    This would have helped PMO identifying that there was an issue with the delivery from the beginning. Let me know if it's clearer. :)

Comment
  • in reply to Daniel Hug

      Let me give you some more context for this project specifically. The source file was an XLIFF file downloaded from XTM, and prepared on Studio to work offline. Once translation was completed, Engineering took care of importing the return package in the studio project, and generating the target XLIFF that we would later need to import back onto XTM. During back-conversion on Studio, only a few added/missing tags in segments were flagged and fixed by Engineering team but no other issues were detected. Hence, target XTM XLIFF could be generated without hiccups. We realized that there were some issues with the file because we would get errors when importing the target back on XTM.

    Upon further investigation and calls with the team, we noticed that the size of the studio file sent to the linguist was much bigger than that of the file received by the linguist: for some reason many segments were missing in their return package, and this was never flagged by Studio. I was wondering if there was any way that Studio could flag that segments are missing in a return package, perhaps without allowing to generate the target file and giving an error, instead?

    This would have helped PMO identifying that there was an issue with the delivery from the beginning. Let me know if it's clearer. :)

Children
  • in reply to Daniela Aronica

     

    To be completely honest, this is more for XTM to clarify what is wrong - I doubt that in this case Studio did something unexpected. 

  • in reply to Patrik Mazanek

    Thanks, Patrik. I thought it was worth bringing this to your attention because the issue was indeed due to the missing content in the vendor's studio return package.

    Once the vendor redelivered the complete package, the corresponding generated target could be imported onto XTM without errors. XTM here was just flagging that something was wrong with the file, but the whole production of the file was carried out on Studio. Hence, it is worth investigating how some segments got "lost" in the process of creating a return package, and why the missing segments were not flagged when it was imported into the main Studio project , as I'd normally expect Studio to flag with an error if the content of a return package doesn't match the structure of the original project fie. 

    I had already raised a ticket for this anyway, but I figured it could also be a nice idea to leave a post for the community to brainstorm and gather feedback on the matter. Slight smile

  • in reply to Daniela Aronica

     

    You'd have to look at the files at each step of the conversion process and find out where the segments (?) got "lost". What exactly got lost? TUs? Segments? File conversions is something I did tons of, and honestly, I find intriguing and enjoyable - but there is often more to it than meets the eye. This might be a matter of getting some settings right. Or of building the comparison step into each workflow that had so many file conversions.