Cyclotis inside OmegaT, compared to other solutions

If you want to share work between translators inside OmegaT, some other solutions exist. In this article we try to make the more objective comparaison between our solution and already existing ones. By objective, we mean that we are open to comments and will be happy to complete the comparaison even if it is not in our advantage. So that it is easier to read, we first describe it in a small table, then give more detail in plain text.

The compared solutions

Shared directory

Before version 2.6 of OmegaT, when users required information about sharing a project, they should have found several solutions based either on a shared directory (Windows CIFS, NFS, ...) or on a cloud solution (like Dropbox). In both cases the idea is to give the responsability to the operating system to make abstraction of the fact that your directory is distant. This works well if you want to share files which are not modified by OmegaT : TMX files in the tm/ directory, dictionnaries, some glossaries... Since OmegaT automatically reloads a file when it detects a modification, you have no synchronisation problem related to these files. However, the main file project_save.tmx is not really shareable this way. Solutions proposed, for example here, imply a manual copy of this file each time you want to synchronise with your collegues.

This is probably an obsolete solution, but we keep it here for comparison.

Git/SVN

In OmegaT 2.6 was introduced the possibility to use Git or Subversion to store a project shared by several users. This has the advantage of preventing you from any manual work except the creation of the project in the server (OmegaT can check out a project, but not do the initial import in the server). However, the synchronisation occurs only when you do a save (or if you let OmegaT do it regularly, usually every 5 minutes). This means that changes appearing during this interval of time are not visible, and in case you change the same segment, a window will open to require you to solve the conflict immediately.

Cyclotis

Cyclotis makes use of a SQL database in order to ensure an immediate synchronisation when you validate a segment. This makes conflicts highly unprobable, unless you are in the same segment at the same time. However, contrairly to Git/SVN, you cannot share the full project : if you want to share more than one TMX file, you will have to create as many instances of Cyclotis database as necessairly. And there is no way to share dictionnaries.

Note : a column about RMI mode would be similar to the last one (this is a variant of project mode), except that the inter-operability with other CAT tools is not implemented, and would probably be more difficult.

  Shared directory
(Windows share, cloud, ...)
Git/Subversion Cyclotis translation memory Cyclotis project memory
What you share Directories : tm/, ... All the project Contents of one memory Contents of project_save.tmx
What you do not share project_save.tmx (unless manual work)   Dictionnaries, project properties
Source and target files
project-save.tmx Translation memories
Synchronisation Manual At each save At each segment validation
External tools needed None A git or subversion server A PostgreSQL server
Integration inside OmegaT N/A Core OmegaT 2.6 or more

DGT-OmegaT (includes the plugin) or Patched OmegaT 4.3.2 (plugin is not yet compatible with OmegaT)

Compatibility with other CAT tools Using TMX format None (or read-only) Good Good (read-only)
When connection is lost N/A
(all is manual)
You work locally You work locally
You do not see distant work
Your work is not sent to the server
A message says that connection is lost
You work locally
When connection is back Re-synchronisation
(commit + fetch)
You see again segments from your colleagues
Only segments modified after the re-connection are sent to the server
You receive all what has changed in the distant database
Only segments modified after the re-connection are sent to the server

How you work

What you share and don't share

Git/Subversion modes in OmegaT work by sharing the entire project, including the files which are not supposed to change during the lifecycle of the project, such as source files and non-writable glossaries. Cyclotis instead, enables sharing the equivalent of one of the modifiable files: if you want to share several files, you have to create the same number of connections to the database (but the plugin will manage to open less physical connections if possible).

Memory mode enables to share the equivalent of one TMX file, the project mode shares an equivalent of project_save.tmx and glossary mode enables to share one glossary. About non-shared files, it is perfectly possible that you do not have the same source files, translation memories, dictionaries... than your colleagues connected to the same Cyclotis server: in this case the list of segments each user sees in the editor will differ, and some entries sent by your colleagues in the database may appear as orphans in your computer, but everything will work.

Synchronisation

Contrarily to Trados, here we do not need to make distinction between saving and visibility: all the proposed solutions make segments visible when they are saved, the difference is precisely, when they are saved.

With Git/Subversion feature, synchronization occurs each time the project is loaded or saved. This can be decided by the user, or based on a regular saving, by default set to five minutes.

In all Cyclotis modes, a new select query is done to the database each time you go to a new segment. In memory and glossary modes, the result is just used to be put in the corresponding pane, then it is lost. In project mode, the result is used to fill the project memory in the RAM : it is susceptible to overwrite what you already had done. Segments which are visible in the editor will immediately be updated, visually.

For project and memory modes, updates are done each time OmegaT updates the project memory: that is, when the user goes to another segment after having changed something in the editor. If you go to another segment without having done any change, project memory is not updated and Cyclotis receives nothing.

Integration in Omega-T

Git/Subversion modes have been integrated directly in the core of OmegaT since version 2.6. But remember that integration in OmegaT is only the client side: users have to find or install a server.

Cyclotis, on the contrary, is designed to be a plug-in and to stay like that. But this plugin works using an improved version of the API, which is not yet included in the core of OmegaT. We hope that their developers will finally accept to add these patches (but not the plugin) in the core, but in any case users will have to download and install the plugin in our site, because it is a different team.

Compatibility with other CAT tools

Git/SVN mode of OmegaT only enables sharing a project between instances of OmegaT itself, and since it requires the import of the full project, it is probably impossible to share with another tool, except eventually if the other tool only reads the TMX files, without writing to them.

The Trados plugin implements a working process which is very similar to OmegaT's memory mode. We already experimented the possibility to work in real time between one person using Trados and another using OmegaT: there are some points which should cause problems - mainly related to tags, because each tool has its own way to manage them - but it is probably possible to correct them, but with some efforts.

The project mode is specific to the plugin for OmegaT, because actually Trados does not give the API which would make possible to implement it for their plugin. And even if it were possible, one remaining problem would be that the two tools have a totally different way to manage the context (what identifies where a segment is) : in OmegaT, segments inserted by Trados would have a big chance to appear as orphans, while in Trados, we cannot say what would happen in such situation. So, if you use OmegaT in project mode, you can allow a Trados client to connect in read-only mode, but you should avoid read-write mode because the context would be lost.

When connection is lost

This is actually the only disadvantage we can admit for Cyclotis against Git/Subversion: we did not yet consider special actions for this case.

Git and Subversion should have no problem to re-synchronize, even years after. The only problem is that you have to manually resolve conflicts.

Cyclotis on the contrary, always considers that the database has the most recent translation for each segment : when you are not connected, not only you don't see other's people work, but your work will not be sent when the connection comes back. That is a point we may change in the future.

 

Add new comment