When you ask SDL for a solution to share work on a same project between translators, almost two solutions are provided. Here is a short comparison between them and our proposal. Since we did not have a license to test Groupshare, what we can say is only based on hypothesis and some presentations found on the internet. Do not hesitate to help us to fill the missing information.

Note: in this table, the column "Groupshare" explores the use of Groupshare in Trados Studio: usage of Groupshare's web editor is out of the scope of this document.

Price

Groupshare has a separate license, meaning that if you want to use it, you have to buy a specific license even if you already bought Trados Studio itself. And also this tool depends on Microsoft SQL Server: we do not know whenever it is compatible with any free version of the tool, so we can suppose that you have to buy a license for it as well.

Cyclotis is entirely based on free software, and is FLOSS software as well : if you can download and install a server yourself, it will have no further cost. But another solution is also to buy memories in the SaaS service: in this case you only pay depending on how much memories or space you use, and you can stop whenever you want.

What you share

A SDL project contains translatable files (converted to sdlxliff), translation memories (sdltm files or translation providers referenced in the configuration file), and glossaries. As far as we understood using internet presentations, GroupShare includes three sharing modes : translation memories, terminology and translation projects. The first mode sounds very similar to what Cyclotis plugin actually provides. The second one already exists in OmegaT plugin, and a very similar behaviour will probably be implemented in the plugin for Studio 2015 if they give us the API for that, as they promised some months ago. About the third mode, as we did not really test it, we can only speak about what we saw in internet presentations. In this mode, a translatable file can be locked by the user, modified, then committed. Or it can be modified then committed, but with the risk of conflict - and presentations don't say what happens in this case. From a programmer point of view, it sounds very similar to using Revision Control System, aka RCS - yes, the 30-year old tool based on locking system, not even CVS or Subversion, which includes merging mechanism and conflict resolution! If really you want to do this, why not a plugin for RCS integration (or CVS or Subversion, after all)? This is what OmegaT did and even if what we propose is an alternative, we admit that in some cases this is a good solution. In the plugin for OmegaT, Cyclotis can also be used to share the project memory. This solution cannot be ported to Trados Studio yet, since the "translation provider API" is not designed for that.

Saving and synchronisation

If you don't use SDLTM in write mode at all, your modifications remain exclusively in memory until you explicitly use CTRL + S. On the other hand, all the 3 solutions described in this document implement saving of the segment just after validation. So, they all ensure that you don't loose your segments in case of computer failure.

But the fact that a segment is saved does not mean that it is visible, almost in the case of SDLTM: segments are only visible after the index has been updated, and according to Trados documentation, this occurs only every 20 minutes. You can probably reduce this time but not without impact on performances. On the contrary, Cyclotis does update its index in real time, so there is no difference between the moment a segment is saved and when it is visible for everyone.

For Groupshare, as far as I can understand from the documentation, the two situations are possible: if you share a memory, the behaviour will be almost similar to Cyclotis; if you share an SDLXLIFF, then you must lock it, like in RCS, and synchronisation will only occur when you commit the modified file. This also adds risk of conflict, in which case you will have to decide for some segments whenever you keep your translation or the one of the colleague.

Interaction with other CAT tools

SDLTM is a proprietary format based on an open source one: you can open it in any tool compliant with SQLite databases, but the indexes are not documented so the only solution will be to do a scan of all contents of the tables, without optimisation. Groupshare is based on SQL Server, and may be accessed by other CAT tools in the same conditions: connecting to the SQL database and scanning the tables, without real access to the indexes since they are not documented. Cyclotis memory populated by Trados Studio is perfectly readable by other CAT tools having the corresponding plugin: all plugins share the same query mechanism. There may be some differences in the behaviour, due for example to the fact that each tool has its own way to manage tags and segmentation, but it works, and in real-time.

What to do when connection is lost

Here we can say that situation is similar for each given solution: if really the connection is lost during your work, you will have to manually inactivate the provider, and re-activate it when the connection is back. The behaviour is the same because all tools are based on the "translation provider API".

When the connection is back, you have the possibility to use the Trados feature "update project memories" to re-synchronize with the database. But remember that segments are sent with the date of the re-synchronisation, not the date the segment was really translated: this can have some consequences depending on which policy you adopted about similar segments.

One advantage of Cyclotis, however, almost against sharing SDLTM in a CIFS, is when you want to use it over a very slow connection, such as a proxy or a VPN. That is because Cyclotis is based on a real client/server database, the plugin has with the server only the really required interactions - sending a segment and receiving a list of segments. SQLite, on which SDLTM format is based, is not really designed for sharing via a network, it makes interactions as a file, so it probably sends and receives a lot of unnecessary data. This case has really been experimented and described by our clients as a situation where Cyclotis is significantly better than SDLTM shared. But we could not make the same test with Groupshare, so we cannot say if it would have the same performances as Cyclotis or not.

Conclusion

Inside SDL Trados, Cyclotis will probably never be as well integrated as GroupShare, since the API does not give us all information. But our solution is almost better than using a shared sdltm file, and less expensive.