List of patches

  1. Translation memory plugins :

    A Translation Memory plugin is a provider, like for Machine Translation plugins, except that the result appears in "Matches" pane, rather than in "Machine Translation". Contrarily to Machine Translation, TM providers return typically more than one result, and as the source is not exactly the same as what you are translating (unless you have 100% match), it appears with a score in the list.
    Now, list of the patches:

    1. introduce the concept of translation memory plugins;
      as an example, a copy of the MyMemory plugin has been adapted to the new API, and we did not remove the previous one so that you can activate both and enjoy the difference.Look here for the reasons why to prefer to use a translation memory provider, rather than a machine translation one.
    2. introduce the concept of project-scope plugin instances (i.e. the plugin does not have only one instance, but one per database); instances are described as properties files which you put in the tm/ directory but this is not a file format, because the file does not contain segments but parameters, usually to connect to a server;
      as an example, we provide a plugin which enables to read two resource bundles and create a list of memories entries, kept in RAM only;
    3. introduce the concept of browsable translation memory: in continuation to previous patch, a properties file which would be in tm/auto will be parsed for auto-population. Also each memory which is in the tm/ folder and implements this interface can be used in the search screen;
      Most providers should implement this interface. MyMemory is a notable exception, because their API provides no way to retreive the full contents of the database
    4. introduce the concept of searchable translation memory, meaning that it can be included in the search screen;
      All browsable memories are also searchable; the interface ISearchable is useful mostly if you have the possibility to do a faster search at server side, before letting OmegaT apply its own filters.
    5. introduce writeable translation memories;
      as an example we provide a support for the text memory format which is used by WordFast and Anaphaseus;
    6. Add possibility forISearchable interface to keep searches optional (i.e. the user can decide to skip one engine even if it implements the interface). This patch is fully optional.
    7. provides an implementation of translation memory using the Apache Lucene libraries: until now OmegaT only used Lucene for tokenizers, while with these patches, it can be used for original purpose, as an indexation engine.

  2. Project storage plugins

    1. introduce the concept of distant project save: instead of using project_save.tmx you have now the possibility to use an external provider. Contrarily to memory mode, you can have only one such instance in the project, and segments are necessarily saved using a context (segment number, or "default" or entry key) : we do no more fuzzy searches but exact, contextual searches.
    2. provide the previous feature also for alternative languages (very useful if the translators of the same document in two different target languages work at same time), using the directory tmx2source. You can have one instance per target language.
    3. can use your running OmegaT GUI as a server for other translators, based on Java-RMI

  3. Glossary plugins

    1. implement project-scope plugins for glossary : using a properties file instead of a -D directive, you can add several instances of the same engine and this is only valid for the current project
      As an example the patch includes a "local" version of TaaS plugin : all share the same API key and connection parameters, but for each project you may want to connect to the collection corresponding to the theme of your project.
    2. implement writeable glossary plugin : now you can replace glossary.txt by a shared provider instance