Under Community Review

Source file System field in SDLTMs

Hi,

Creating a new idea just for the Source file System field in Studio.

Please do consider having a Source file system field in SDLTMs which capture at least the file where that segment was first created. Filepath and name would be ideal but filename is already better. It's a very useful piece of information which is available in the TMX file but not visible in the SDLTM format.

There was a recommendation in a previous post to use the Record source plug-in for it but this is key functionality that is missing in Studio. Besides, the suggestion of a plug-in will not do much, as that is not something that can be deployed in TMS TMs.

Thank you once again for considering this enhancement.

Kind regards,

Miriam

Miriam Santos Freire
Parents

  • So to make this a bit more clear. What this idea is requesting is to have another System Field called Source File or something similar that records the name of the file that TU came from originally. Of course if the TU gets modified, it's a new TU, so the field needs to be updated. If the TU just gets used as a 100% match, the field stays the same. And that should be aligned across all products: Studio, GroupShare, TMS - at least - does this capture it

Comment

  • So to make this a bit more clear. What this idea is requesting is to have another System Field called Source File or something similar that records the name of the file that TU came from originally. Of course if the TU gets modified, it's a new TU, so the field needs to be updated. If the TU just gets used as a 100% match, the field stays the same. And that should be aligned across all products: Studio, GroupShare, TMS - at least - does this capture it

Children
  • in reply to Adrian Boloveschi

    HI , I am not sure if Miriam is still active in the community, so let me get back to you on this. Your summary above is basically correct:

     We would like a new system field called "Source file" or similar that stores the file name (and in TMS ideally job ID or task ID) that the TU originally came from. Then every time the TU is reused, the "Usage Count" increases and the "Last used on" and "Last used by" fields get updated as is already the case . And when the TU gets modified, the "Last modified on" and "Last modified by" fields get updated (as is already the case), as does the new "Source File" field.

    This will help immensely with root cause analysis when there are translation issues and in many other scenarios.

    What I have thought of only today and might be even more helpful, is if we could have 2 new system fields: one called something like "TU creation source file" that like the "Created by" and "Created on" fields stays static and one called "TU modification source file" or similar that like the "Last modified on" and "Last modified by" fields gets updated as and when required. That would really enable to trace translation histories fully. But if that would be harder to develop, just having one Source File field as per the original request would already be a massive improvement!

  • in reply to Neeltje Stuurman

    Excellent input! Thank you for this and I agree having those 2 fields would be even better. We will see what Product Management says - but for now, it's best if we make this idea popular and get community push for it.