In the patches for OmegaT we introduced the possibility to share the project memory via an external provider. Patches P1 and P2 contain the API - meaning, the interfaces - and modifications of the code to make the link with the provider. You can write an additional implementation, if you want. Actualy, there are then two implementations of this API : using Cyclotis server (which is in the plugin), or using RMI (patch P3). Now, let's describe this feature from the point of view of the user already connected via one of these solutions.

Contrairly to OmegaT's Git/SVN access, here we emulate a distant version of project_save.tmx only : people may have similar contents in the source, tm or glossary folders, or not. The behaviour is similar to what happens when you take the file project_save.tmx from one project and put it in a new one: entries which exist in the sources of the new project (either default with same source, or alternatives with exactly same entry key) will appear as already translated, while entries which do not exist in the new project are now considered as "orphan entries". New entries are refreshed each time you go to a new segment: this means that once you moved from a segment to another, you may see new segments appearing in green (already translated) because in the meantime, one of your colleagues connected to the same project memory did translate them. Note that when we say "them", since we are speaking about the project memory, the rule to consider that two clients are referring to the same segment are those which OmegaT uses for project save: segments are the same if and only if they have the same source and either the same key or both are default translations.

The properties file is named project_save.properties, there can be only one in the project. When you (re-)load the project, first it reads project_save.tmx, if it exists, then it asks the server to retreive all its contents: we consider that the server is supposed always to have the best translations. The reason for that is that when you open the project, another user should already be connected and may have done new translations or corrections. Entries which are in the project_save.tmx will still be in memory, unless they have been replaced by an entry from the server, but they will not be sent to the server unless you modify them (remember that OmegaT only updates project_save.tmx for modified translations).

The patch P2 makes possible to add the properties file for other languages, exactly as TMX files in tm/tmx2source directory. This is the only case where this connection is read-only. In this case you can have one distinct properties file per language.

About conflicts:

Git/SVN modes implement a conflict resolution in case two people gave a different translation for the same segment. Distant project memory does not. Again remember that we have no latency: if a distant user translated one segment which comes later in your project, you will immediately see it when you go to another segment, even if it is precisely this segment you are just going to. The only case where a real conflict could occur is if you open a segment for editing just before the distant user validated exactly the same. And in this case, the distant memory keeps only the last entered translation: your colleague will not receive a notification, but if he looks carefully, he may notice that the translation displayed in the editor has changed when he went to another segment. It is really difficult to detect such a case, because the client does not inform the server when he enters in a segment. Maybe we will consider the possibility to find a better solution in the future.

About auto-populating directories (tm/auto and tm/enforce) :

Each time you (re)load a project, this directory is parsed again; empty entries which have a match in these files are translated automatically. When connected to a server, during this auto-population the corresponding entries are sent to the server. However, if you already used this feature in OmegaT, you may have noticed that it never added orphan entries, because it only populates existing segments. The same behaviour will remain with the server: only entries which exist in your project will be auto-populated in the server, meaning that a distant user connected to the same project memory will not receive entries which are orphan in your side but not in his one.

About orphan segments:

In OmegaT, when a segment is present in the project-save but corresponding to none of the existing source segments (either compared by source or by entry key), it is referred as "orphan". Such segment will never appear in the editor but may appear in the searches and fuzzy matches. But in any case, they are in the RAM of running OmegaT. The problem with distant server is that the project-save may be reused by a lot of projects, meaning that there will be a lot of orphan segments (because they are locally orphan, but corresponding to something which exists in other projects). And since project-save memory does not work by fuzzy matching, searches in these segments cannot be optimized as for distant translation memories. That is a good reason why the patches given for OmegaT give the possibility (to be configured in the properties file) to ignore distant orphan segments, to save some memory at client side when the same server-side memory is reused by a lot of distinct projects.

Default behaviour is to accept the same number of ofphan segments as the project size itself - if there are more, they are not saved. But doing this, you loose the possibility to see these segments in matches pane and search window, so we provide an alternative: with Cyclotis server it is also possible to add a translation memory provider which does its searches in the orphan segments of the project-save memory. This is not yet possible for RMI version, but we may add it in the future.