New Trados 2024 SR1 - automatically changing Groupshare project names (locally, not on the server)

I have recently installed the new SR1 18.1.2.6370 upgrade and I immediately started having major issues.

All my server project names (on Groupshare 2017, which up until the update worked like a charm) suddently started... changing locally on my machine. When I download a server project from my server, it appears on my project list normally (initally). But then, after a second or two, it changes - and takes the name of the first server project on my list. If I have 20 server projects, all have identical names now.

To reiterate - when I download a server project, initially everything is just fine. The problems appears only after a few seconds. No matter if I download projects or if I create them myself - after a second or two of being on the list, all server projects change names. This happens for both my personal GS 2017 server and Groupshares from my clients (they use newer GS versions). This also happens if I manually change project names - after a second from the change they revert to the erroneously-assumed name, too. This means I cannot change the name of any server project at all.

This does not seem to affect local projects for some reason - those work normally. Until I publish them to the server - at which point they do change their names after a second or two, too.

I tried reinstalling Studio, I tried uninstalling and manually installing it again. For some reason SR1 stopped working as a Groupshare compatible tool for me. Has anyone else experienced this? Is there a workaround for this?

emoji
Parents
  • Hello everyone,

    We are currently experiencing the same project name duplication issue described above, and I’d like to add that this problem has also appeared in one of our major client environments using GroupShare.

    Unfortunately, at the moment, none of the available builds are fully operational for production use:

    • The original 2024 SR1 (18.1.2.6370) still changes all GroupShare project names locally after synchronization.

    • The CU1 and CU2 updates, while they partly address stability, have introduced new issues with terminology management — in particular, the glossary/termbase connection becomes unstable or non-functional.

    As a result, both versions (pre-CU and post-CU) are currently not reliable in workflows that depend on GroupShare and MultiTerm.

    We’ve reproduced these problems across multiple machines, user profiles, and server connections, and confirmed they are not related to local configuration or permissions.

    It would be very helpful if RWS could confirm:

    • Whether a hotfix or cumulative update is planned to address both the GroupShare metadata sync bug.

    • A timeline or roadmap for when a stable production build can be expected.

    Thank you,
    Giorgos Lourakis

    emoji
Reply
  • Hello everyone,

    We are currently experiencing the same project name duplication issue described above, and I’d like to add that this problem has also appeared in one of our major client environments using GroupShare.

    Unfortunately, at the moment, none of the available builds are fully operational for production use:

    • The original 2024 SR1 (18.1.2.6370) still changes all GroupShare project names locally after synchronization.

    • The CU1 and CU2 updates, while they partly address stability, have introduced new issues with terminology management — in particular, the glossary/termbase connection becomes unstable or non-functional.

    As a result, both versions (pre-CU and post-CU) are currently not reliable in workflows that depend on GroupShare and MultiTerm.

    We’ve reproduced these problems across multiple machines, user profiles, and server connections, and confirmed they are not related to local configuration or permissions.

    It would be very helpful if RWS could confirm:

    • Whether a hotfix or cumulative update is planned to address both the GroupShare metadata sync bug.

    • A timeline or roadmap for when a stable production build can be expected.

    Thank you,
    Giorgos Lourakis

    emoji
Children