Projects deleted in Groupshare are deleted in Studio (when Studio connects to the server)

Under Community Review

You have to delete the projects from the GroupShare Webui and from the the project folder in the My Documents folder as well.

Under Community Review
  • Hi  - When you delete a project in GroupShare from the WebUI, the projects gets deleted from the server. In Studio you always have a local copy of one/more files or the entire project. It would not be the best practice to allow what you're asking for to happen. Imagine someone else deletes a GroupShare project that you have open on your machine. Or that 5 people have open. That action would lead to deletion for files/data from people's computers. The behavior right now is that if the project gets deleted from GroupShare, there is a red dot appearing near the project name in Studio to indicate that. Also if you look in the bottom part of the screen in the Publication Status, you will see "Unpublished from server". So then you can decide what to do with it. Let me know what you think about this under the light of this new information.

  • Thanks for the input Adrian. I'm interested in data management and right now there is a lot of interest in GDPR in Europe. This is why I'd like a central function to clean up legacy data. If that is not useful to the way other organisations work then a client-side clean up could also be an option, where options can be selected then a cleanup task run.

  • Hi Maurice,

    I see where this concern comes from now. However, I still think that deleting files from users computers is outside the scope or purpose of GroupShare. You could implement something like this from an IT perspective. This is what I would imagine: let's say you have 50 translators that work with GroupShare projects in your company. Have the same local path (example: C:\SDL\Projects) on each user's machine where they download GroupShare projects. Make sure this is a local folder though, not a network drive. Then, at each restart of the machine, you make a scheduled task to delete the content of that folder and also delete the projects.xml file (C:\Users\aboloveschi\Documents\Studio 2017\Projects) where Studio keeps the list of open projects. This will mean that the translators will open Studio and it will have a blank list of projects and they need to open again whatever project they were working on from GroupShare. Since all the work is saved in GroupShare, I don't see any reason for this approach to not work. It's just a few extra clicks for translators in the morning.

  • Oops, I forgot to edit the path in my last message and I can't edit that message.

    C:\Users\[USERNAME]\Documents\Studio 2017\Projects




  • Thanks. I am looking at deleting files with modified dates older then 30 days. Will this work OK with the projects.xml index file?

  • If you want to automate this a bit more, you could also set this parameter:

    <Setting Id="RecentProjectFolder">C:\SDL\Projects</Setting>

    from this file: UserSettings.xml found here:

    C:\Users\[USERNAME]\AppData\Roaming\SDL\SDL Trados Studio\

    And that will be the path that is automatically suggested by Studio when they open a GroupShare project.

  • I don't think deleting individual files is a good idea. You could have one project folder that has files in it with different time stamps, so you could potentially just be deleting some files from a project folder. Also, you would have the projects.xml file that contains the list of open project in Studio - you can either delete this file and then Studio creates a new, empty one or not delete it. I don't know of a easy way to just delete some entries from it so that you synchronize that with whatever files you are deleting. So I think this approach is risky. You won't lose data, but you may have your users report errors in Studio.

  • However, if we delete the whole folder and not only 'old' files then we will delete any work that has not been checked in to GroupShare.

  • Hi Maurice,

    The translation is saved into GroupShare also before checking in, each time the file is saved. Studio now has the AutoSave option, which by default is set to 10 minutes, but you can modify that under File - Options - Editor. So a file that is checkout and is being edited does not have to be checked back in for the server version of it to be updated, it just has to be saved.

    However, I recommend you coach your translators to always check back the files in the GroupShare project at the end of the day or at the end of any work session and not leave the files checked out to them. They can leave the files in the same GroupShare phase, so it's visible to anyone looking at that project who should be working on the file so there is no need to keep it check-out to show that. It's just a better practice in general.

    Therefore, if the file deletion would occur each morning when they turn their computers on, there would be no work lost.

    Let me know if you have further questions.

  • Hi. That's not the case for me (on Studio 14.1.10011.20356, GS.2017.SR1.1088). If I save then close then delete the projects folder then reopen the application and reconnect to GS and re-open the project, the translations are lost.

  • Hi Maurice,

    Indeed, when you re-open the GroupShare project, it is empty. The translation is not lost though - the sdlxliff on the GroupShare server is updated correctly when you save. If you do Cancel check-out and then do again Check out - you get the updated sdlxliff or if you open the project on a different machine or in Online Editor, the translations are there. Let me look into this a bit more and get back to you on that. In the meantime, we can operate on the assumption that the file would need to be checked in by the user at the end of their workday and you would need to coach the users to follow this process.