OmegaT Documentation

OmegaT is a professional computer-assisted translation (CAT) tool. It is a local application that does not require an internet connection and does not send data to online services unless explicitly configured by the user.

Key Capabilities

• Translation Memory: Flexible support with real-time matching.
• Collaboration: Supports TMX sharing and fully shared projects.
• File Formats: Supports industry standards including XLIFF, TMX, TTX, PO, HTML, and DOCX.
• Assistance Tools: Autocompletion (based on history, predictions, glossaries, and tags), glossaries, spell checking, and grammar checking.
• Language Support: Unicode and Right-to-Left (RTL) support.
• Extensibility: Supports plugins and scripting.
• Machine Translation: Easy access to MT services.

System Requirements

OmegaT runs on any operating system that supports the Java Runtime Environment (JRE), including Linux, macOS, and Windows.

The OmegaT project follows a structured directory layout for source code, tests, documentation, and sub-modules.

Main Source Code

• src/main/java: Contains the primary OmegaT Java source code.
• src/main/schemas: Contains XML schemas used for JAXB code generation.
• src/test: Contains unit and regression tests, organized into java and resources sub-folders.
• src/testFixtures: Provides base test code shared across multiple sub-projects.
• test-integration: Contains integration tests. The test-integration/docker folder includes a Dockerfile for setting up test server and client environments for automated testing.

Documentation

Documentation is managed using Markdown and the Sphinx processing system. Key directories include:

• src/docs/manual: User manuals and start guides.
• src/docs/developer: Developer notes (Markdown files).
• src/docs/greeting: HTML content shown on the OmegaT startup screen.
• src/docs/tips: HTML files for 'Tips of the Day'.
• src/docs/template, src/docs/style, and src/docs/xsl: Files used to generate the HTML/PDF manual output.

Sub-modules and Plugins

• tipoftheday: A sub-project implemented as an OmegaT plugin. It uses a standard Maven source tree structure and is configured via its own build.gradle file. Content for the 'Tip of the Day' dialog is stored in the docs folder and must be indexed in tips.yaml when new content is added.

In Team Projects, OmegaT uses the team sync feature to manage versioning and conflicts. When you save, OmegaT attempts to sync with the remote repository (indicated by the status message TEAM_SYNCHRONIZE).

If the remote file has been modified by other translators, OmegaT detects the difference and creates a timestamped backup to prevent overwriting work. After a sync-driven save, you may see three files:

1. project_save.tmx.bak: The state of the file immediately before the current save.
2. project_save.tmx.YYYYMMDDhhmm.bak: A timestamped backup of the file as it existed after the translator's previous work, preserved because a remote change was detected.
3. project_save.tmx: The final merged file containing translations from both the local user and other team members.

Note: If no other translators have modified the remote file, the timestamped .YYYYMMDDhhmm.bak file is not created.

OmegaT uses Gradle's built-in dependency verification to protect against supply chain attacks (such as hijacked packages or man-in-the-middle substitutions). The system validates the SHA-256 checksum of every downloaded artifact against known-good values stored in gradle/verification-metadata.xml. If an artifact's hash does not match the recorded value, the build fails immediately before any code is compiled or executed.

Key security properties of this setup:

• Metadata Verification: Both POM files and Gradle module metadata (.module files) are verified (verify-metadata: true) to prevent attacks that manipulate dependency resolution graphs.
• Checksum-based Safety: Protects against compromised repositories, cache poisoning, and artifact substitution.
• Exclusions: Source (-sources.jar) and Javadoc (-javadoc.jar) JARs are globally trusted and excluded from checksum verification because they contain no executable code and are difficult to track in metadata.

<!-- The verification metadata is located at: -->
gradle/verification-metadata.xml

OmegaT uses a Type-Based ClassLoader Isolation strategy to manage plugins. Instead of a single shared ClassLoader for all plugins (which causes dependency conflicts) or a unique ClassLoader for every single plugin (which can break resource sharing), OmegaT groups plugins by their PluginType.

Each PluginType is assigned its own MainClassLoader via an EnumMap. This allows plugins of the same type to share necessary resources while providing isolation between different categories of plugins.

Grouping Logic

• Theme plugins: Share one ClassLoader to allow registration of Look-and-Feel (LaF) classes with the global Swing UIManager.
• Language plugins: Share one ClassLoader to facilitate sharing dictionaries with the core library and other language modules.
• Filter plugins: Share one ClassLoader.
• Other types: Follow the same pattern of grouping by type.

Implications for Plugin Developers

• Intra-type interference: Because plugins of the same type share a ClassLoader, they can access each other's classes. You should be aware that your plugin might interact with other plugins of the same type.
• Dependency Conflicts: If two plugins of the same type require different versions of the same library, a conflict may occur because they share the same namespace.
• Fault Propagation: A memory leak or bug in one plugin can affect other plugins within the same PluginType group.

// Internal implementation mechanism for type-based isolation
EnumMap<PluginType, MainClassLoader> MAINCLASSLOADERS;