ProZ.com Translation Forums

http://omegat.org/ | This is what happened

WolfgangS — Fri, 25 Sep 2026 07:25:00 +0000

Forum: OmegaT support
Topic: http://omegat.org/
Poster: WolfgangS
Post title: This is what happened

[quote]CafeTran Trainer wrote:

What happened to [url removed] ? [/quote]

The OmegaT organization has been flagged on Github. The repository resources are temporarily unavailable.

If you need to download OmegaT, use the SourceForge site instead.

http://omegat.org/ | Site is back

CafeTran Trainer — Fri, 25 Sep 2026 04:35:00 +0000

Forum: OmegaT support
Topic: http://omegat.org/
Poster: CafeTran Trainer
Post title: Site is back

[quote]CafeTran Trainer wrote:

What happened to [url removed] ? [/quote]

Website is online again.

http://omegat.org/

CafeTran Trainer — Thu, 24 Sep 2026 13:10:00 +0000

Forum: OmegaT support
Topic: http://omegat.org/
Poster: CafeTran Trainer

What happened to [url removed] ?

OmegaT interoperability issue with SDLXLIFF | Making sense of SDLXLIFFs

Daniel Hug — Wed, 06 May 2026 14:23:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: Daniel Hug
Post title: Making sense of SDLXLIFFs

[quote]Epameinondas Soufleros wrote:

Unfortunately, I can't make heads or tails of this huge sdlxliff.[Edited at 2026-05-06 10:34 GMT] [/quote]

As far as I remember SDLXLIFFs are XML files without line breaks. You need a tool like EditPad Pro or Notepad++ to insert line breaks.

OmegaT interoperability issue with SDLXLIFF | CafeTran not good at interop either

Epameinondas Soufleros — Wed, 06 May 2026 09:32:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: Epameinondas Soufleros
Post title: CafeTran not good at interop either

Well, CafeTran conflates paired tags with unpaired tags and placeholders, and sometimes it omits them altogether, making you think that the source segment is missing words... This is even worse.

In any case, CafeTran tries to be too smart and offers a ton of words and phrases, with 90% of them being incorrect for Greek. I don't want to have to look at so many incorrect guesses and make edits to assembled matches that use them. I only need:
- a good grid that can be scrolled fast, that can be filtered and unfiltered quickly with a shortcut
- a TM pane with useful metadata
- a TB pane with useful metadata

I don't need everything but the kitchen sink shoved into an application. I don't need a gazillion panes and panels and pop-ups and sidebars fighting for my attention, especially when the info they show is incorrect, as is the case when one's target language is Greek.

OmegaT interoperability issue with SDLXLIFF | Status

CafeTran Trainer — Wed, 06 May 2026 09:24:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: CafeTran Trainer
Post title: Status

Thanks for the clarification!

For what it's worth, in CafeTran Espresso you can filter on:

Also relevant: if a user changes an MT translation in an SDLXLIFF file, this segment will be marked as edited in Trados. I'm not sure if the same is the case for AI-translated segments.

[Edited at 2026-05-06 09:28 GMT]

OmegaT interoperability issue with SDLXLIFF | I need the right balance of information

Epameinondas Soufleros — Wed, 06 May 2026 09:03:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: Epameinondas Soufleros
Post title: I need the right balance of information

I need to know if a segment was confirmed before I was assigned to work on it, if the target content it contains has come from machine translation that I need to modify, and so on. OmegaT conflates those and displays them simply as "Translated". If a segment has text on the target side, OmegaT considers it translated. Well, reality is not that simple. Segment statuses and states are crucial for my work, it seems.

Fifteen years ago, when most of my work arrived in the form of source documents that I imported myself into a CAT tool, OmegaT would have been awesome. Nowadays, with all this cacophony of CAT tools and TMS platforms, and (vendor-specific) XLIFFs moving back and forth, I need something different. Tough luck if one is trying to move away from Windows.

[Edited at 2026-05-06 10:36 GMT]

OmegaT interoperability issue with SDLXLIFF | What happened?

CafeTran Trainer — Wed, 06 May 2026 08:49:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: CafeTran Trainer
Post title: What happened?

[quote]Epameinondas Soufleros wrote:

Anyway, I will just steer clear of OmegaT for professional work. I have gathered too many obstacles already, and project development seems to have stalled. [/quote]

Once you were so enthusiastic about oT. What has changed? Other type of jobs?

OmegaT interoperability issue with SDLXLIFF | I can't

Epameinondas Soufleros — Wed, 06 May 2026 08:47:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: Epameinondas Soufleros
Post title: I can't

Unfortunately, I can't make heads or tails of this huge sdlxliff. It makes VS Code hang for a good minute and then it shows a document with endless lines of code. When I wrap the lines, everything appears as a huge block of indistinguishable elements. When I try to use an XML formatter against this document of 5108 lines, it seems to get stuck in an endless process.

Anyway, I will just steer clear of OmegaT for professional work. I have gathered too many obstacles already, and project development seems to have stalled.

Trados Studio is bearable once I turn off UPlift and AutoSuggest and other bells and whistles that only create mental fog and slow down my computer.

[Edited at 2026-05-06 10:34 GMT]

OmegaT interoperability issue with SDLXLIFF | Could you show some of the plain XLIFF content?

Daniel Hug — Wed, 06 May 2026 07:00:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: Daniel Hug
Post title: Could you show some of the plain XLIFF content?

[quote]Epameinondas Soufleros wrote:

The OmegaT editor for some reason shows a previous version of the target-language text, even though its other panes (Fuzzy Matches, Segment Properties) show the latest one.

Therefore, I assume that it picks up the wrong elements from within SDLXLIFF (XLIFF files contain "alt-trans" elements, which represent matches pulled from TMs or other resources during pre-translation).

[Edited at 2026-04-29 09:07 GMT]

[Edited at 2026-04-29 09:19 GMT] [/quote]

Could you show some lines from the plain text of the SDLXLIFF file, and then a screenshot how OmegaT 6.0 displays them?

OmegaT interoperability issue with SDLXLIFF | Correct text

Epameinondas Soufleros — Wed, 29 Apr 2026 08:57:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: Epameinondas Soufleros
Post title: Correct text

By "correct text", I mean the latest version of the target-language text. I received an SDLXLIFF with automatic translations. I edited and confirmed those segments (Translated state). I took this updated/edited/modified document and put it into OmegaT. It showed the target-language text that had been inserted by MT, not the text that I typed and confirmed. I did not use the wrong file, which is corroborated by the fact that other CAT tools show the expected target-language text.

The OmegaT editor for some reason shows a previous version of the target-language text, even though its other panes (Fuzzy Matches, Segment Properties) show the latest one.

Therefore, I assume that it picks up the wrong elements from within SDLXLIFF (XLIFF files contain "alt-trans" elements, which represent matches pulled from TMs or other resources during pre-translation).

The issue with CAT tools that don't have segment statuses and states is that they assume that a translator will always start with a blank document. That's the scenario they always show in their webinars. But reality is much more complex than that: most documents arrive pre-filled with matches from translation memories or machine translation. The former are usually confirmed and either locked or unlocked, while the latter are not confirmed, in a draft state. OmegaT shows all of these with a yellow background, which means they are translated according to it. So, I can't differentiate between (a) segments that came from a TM and the client does not want me to touch and (b) segments that came from MT and I need to edit.

(Somewhere in between lies Wordfast Anywhere, which does not have confirmation check-marks or a Translation-Revision-Approval workflow, but can identify automatically translated segments in an XLIFF and mark them as "Provisional". The user must be aware of this feature and perform the operation manually. It would be much better if this was done by default upon import, or at least offered as an option in Pandora's Box.)

[Edited at 2026-04-29 09:03 GMT]

[Edited at 2026-04-29 09:07 GMT]

[Edited at 2026-04-29 09:19 GMT]

OmegaT interoperability issue with SDLXLIFF | @Epameinondas

Samuel Murray — Wed, 29 Apr 2026 08:44:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: Samuel Murray
Post title: @Epameinondas

[quote]Epameinondas Soufleros wrote:
So, I switched to the Okapi filter (latest version: 1.48). Now, most segments showed the latest target text (the one I had confirmed and saved in Trados Studio). The exception were those segments that had come from machine translation, for which the editor showed the initial text that had come from MT. ... [/quote]
Yup, so far, everything sounds normal. Is this not what you had expected to happen? What did you expect would happen?

[quote]No matter what I tried, I could not make the correct text to show up inside the editor. [/quote]
What do you mean by "the correct text"?

[Edited at 2026-04-29 08:45 GMT]

OmegaT interoperability issue with SDLXLIFF

Epameinondas Soufleros — Tue, 28 Apr 2026 16:59:00 +0000

Forum: OmegaT support
Topic: OmegaT interoperability issue with SDLXLIFF
Poster: Epameinondas Soufleros

So, I received a Trados Studio package. I opened it in Studio and started working on it. The project manager had performed pre-translation against a TM, and then automatic translation (machine translation) for segments that could not be found in the TM.

After I had completed more than half of the job, I took the SDLXLIFF file from the target language folder of the Trados Studio project and dropped it into an OmegaT project. Here's the issue: The OmegaT editor showed all target segments with the text they had when I received the job, instead of showing the target text as modified, confirmed and saved by me.

This happened using the default SDLXLIFF file filter of OmegaT. So, I switched to the Okapi filter (latest version: 1.48). Now, most segments showed the latest target text (the one I had confirmed and saved in Trados Studio). The exception were those segments that had come from machine translation, for which the editor showed the initial text that had come from MT. In contrast, the Fuzzy Matches pane, the Segment Properties pane and the Comments pane showed the text as modified, confirmed and saved by me!

No matter what I tried, I could not make the correct text to show up inside the editor. I deleted project_save.tmx, I exported the latest version of the TM from Trados Studio and placed it in the "Enforce" subfolder of the OmegaT project, I tried versions 6.0.1, 6.0.2, 6.1… No luck with any of these solutions.

When I imported the very same SDLXLIFF document into Swordfish and Wordfast Pro, it showed correctly. (Extra points to WF here for differentiating between paired and unpaired tags, which aids comprehension a lot. Extra points to Swordfish for picking up context notes contained in SDLXLIFF cxt elements, which no other tool can do—Rodolfo Raya was able to implement the feature in a single day after I proposed it to him.)

The above issue, along with OmegaT's lack of segment states (Draft, Confirmed, Translated, Revised, Approved and whatnot) and statuses (Pre-translated, Assembled, Propagated, Machine-translated and so on) make the tool less than ideal for anyone trying to work on Trados Studio jobs in OmegaT.

The OmegaT free and open-source project is an admirable endeavour, of course, and its performance on all platforms is unmatched. I'm just pointing out that it might not be for more complex use cases and for carrying out work that was prepared in a different tool.

[Edited at 2026-04-28 17:05 GMT]

OmegaT 6.1 Beta Mac ARM | DeepL plugin is released as an individual project

Hiroshi Miura — Sun, 26 Apr 2026 02:35:00 +0000

Forum: OmegaT support
Topic: OmegaT 6.1 Beta Mac ARM
Poster: Hiroshi Miura
Post title: DeepL plugin is released as an individual project

You can find an up-to-date DeepL plugin at [url removed]

A bundled DeepL connector in OmegaT 6.0.1 and before does not work because of the old API deprecation by DeepL.com.

OmegaT 6.1 Beta Mac ARM | It does not fit in with my vision of the world

Epameinondas Soufleros — Wed, 03 Dec 2025 11:46:00 +0000

Forum: OmegaT support
Topic: OmegaT 6.1 Beta Mac ARM
Poster: Epameinondas Soufleros
Post title: It does not fit in with my vision of the world

Machine translation is simply incompatible with my vision of the world. It is not what I had in mind when I was studying to become a translator.

Instead of conforming to this despicable reality, I choose to adapt reality to my world-view.

I am a man of principle or—as someone might put it—a romantic fool that will be left behind by ‘progress’.

OmegaT 6.1 Beta Mac ARM | Why

CafeTran Trainer — Wed, 03 Dec 2025 11:03:00 +0000

Forum: OmegaT support
Topic: OmegaT 6.1 Beta Mac ARM
Poster: CafeTran Trainer
Post title: Why

[quote]Epameinondas Soufleros wrote:

I have not tried it myself, as I do not use machine translation of any kind. [/quote]

What are your arguments against using MT?

OmegaT 6.1 Beta Mac ARM | I couldn't find it in the list, though

WolfgangS — Tue, 02 Dec 2025 14:25:00 +0000

Forum: OmegaT support
Topic: OmegaT 6.1 Beta Mac ARM
Poster: WolfgangS
Post title: I couldn't find it in the list, though

[quote]Epameinondas Soufleros wrote:

Searching the OmegaT list of feature requests, it appears that DeepL support has been implemented.

I have not tried it myself, as I do not use machine translation of any kind.

[Edited at 2025-12-02 11:38 GMT] [/quote]

I reverted back to 6.0.1 where DeepL is in the MT list.

OmegaT 6.1 Beta Mac ARM | Wow!

WolfgangS — Tue, 02 Dec 2025 14:17:00 +0000

Forum: OmegaT support
Topic: OmegaT 6.1 Beta Mac ARM
Poster: WolfgangS
Post title: Wow!

[quote]Epameinondas Soufleros wrote:

Straight form the source:

6.1.0 vs 6.0.0

Implemented requests:

- Improve TMX validation error reporting: Show detailed parser errors in dialog instead of only in log file
- Tokenizer to support the snowball generated stemming mode
- Support Windows 11 and Linux on ARM64 for development environment
- Word selection according to the language of Source/Target by clicking in the editor pane
- Spell checker dictionary as a language module
- HunspellTokenizer to support stopwords
- Po: put prural source term in comment when nplural=1 langguages
- Support ngrams for local LT server jar launcher
- Localize UI for genuine dialogs in various languages
- Log filename to be date-time based
- TMX writer output in 6.1 should be the same as in 6.0
- Support Morfologik spell checker and use LT bundled dictionary
- Support U*ix variants
- Alternative translation highlight
- Add timestamp to log
- Apertium MT now sends whole locale code to server instead of only the language code
- Support for Stardict's Pango content type
- AbstractFilter should handle BOM when create reader
-Trim authentication details in team projects
- Provide package "deb" and "rpm" as distribution format for linux
- Download team project with a shallow history
- Give a selection of perHost/PerRespo credentials treatment
- Enforce checkstyles and suppress it for auto-generated files
- ResourceBundle Filter: default not to escape Unicode character
- Make repository connectors as plugin
- Make language libraries in LanguageTools as module
- ResourceBundle filter: "Don't translate NOI18N comment" feature optional
- Use SLF4J as logging facade framework
- SVN/Team project should respect access URL specified
- team: apache HttpClient for git connection
- Request to add new API to allow plugins/modules to add menu item in requested place
- Team: SVN support svn+ssh protocol with key authentication
- Team: SVN: Replacing trilead-ssh2 with Apache sshd
- Ensure that OmegaT functions properly under Java 21
- Better error message for omegat.project failure
- Generate JSON format stastics file when save
- Build System: update gradle version to 7.5.1
- Generate and compile TXT and JSON file when committing target files
- Ensure that OmegaT functions properly under Java 17
- MT: IBM watson accept 50KB text
- GUI: automatically adapt colour scheme to OS colour preference on Windows and macOS
- Update LanguageTool to latest version (6.1)
- Visual confirmation that dictionary was searched
- Remove TaaS terminology lookup
- Update to Gradle 7.3.3 or later
- Clarify requirements for DeepL API key
- Team feature: SSH support id_ecdsa and id_ed25519 for default key
- Use Jackson library as XML parser
- Add nashorn javascript engine[Java 17 compatibility]
- If multiple versions of the same plugin are present, only the latest is loaded
- Add Spell checker as a type of plugin
- [fuzzy] option in "Check issues"
- Use repository mappings in a local project
- Remove "Restore defaults" button where it has no function
- Upgrade to LanguageTool 6.5
- Upgrade to LanguageTool 3.6
- Improve TBX parsing
- Support SRX format
- Support M1/M2 Mac natively and distribute with Arm64 JRE.
- Distribution with Linux aarch64 JRE

Bug fixes:

- .PO filter bug: display issue when a msgctxt spans several lines
- Unable to import a team project to a path containing Chinese characters
- Wrong root element name for stats.xml
- NPE at program exit
- Sometimes called SegmentProperties.onEntryActivated after closed a project
- Mismatch in method name causes exception when selecting "Open Writable Glossary File"
- Spellchecker raised NPE when writing word list file
- Uncaught exception in weekly build (2025-01-18)
- Fix the IllegalArgumentError on sort with filter(Objects::nonNull)
- OmegaT failed to start if there are 'jar' file w/o manifest in plugin folder
- aligner average distance can be {0} which expected a numeric value
- fix: Glossary sort order: Change src length sort condition and use Language Dependent sorter
- Preferences/CutomColorSelector don't show notification immediately when modifying color
- Speller: morfologik: LT bundled dictionary not found in Dutch
- Console-stats command failed with error
- Removal of MED package save/load feature
- Failed to load "en-AU" LT language by IllegalArgumentException
- filter: bundle: when charsert configuration is US_ASCII, force unicode escape
- OmegaT 6.1 does not write startup message in log file
- Color customize UI label for marker come from tm/mt/ folder
- Fix behaviour where git repos would be recognised as SVN
- OmegaT does not show entreis of stardict-JMDict dictionary
- Links with ending parens in glossary panes
- Short glossary items are not recognized with Korean source
- Debug log in some classes are broken
- XLIFF1 filter produce broken trasnalated file
- sdlxliff filter does not display (some) comments
- When restart GUI on deb/rpm packaged OmegaT, it failed with java not found
- Preference to enable "Project specific External Command" is lost
- Windows launcher does not launch when witout_JRE installer used
- Glossary popups behavior changed unintended way
- OmegaT does not use cached MT result for translated segments
- Match statistics are affected by fuzzy match threshold
- PluginInstaller throws NPE in certain condition
- Issue window cause exception
- java.nio.charset.UnmappableCharacterException: Input length = 1
- Repository mapping with SVN cause error
- OmegaT 6.1 macos-arm version does not launch on macOS arm machine
- OmegaT 6.1 macos-arm version does not launch on macOS arm machine
- distribution for macOS only run on Java runtime 11
- Links that contain non ascii characters are not properly handled in glossary dialog
- CI: weekly release failed with permission error inside docker image
- OmegaT failed to start in specific case
- Unit tests failed on Windows
- OmegaT creates xlf file that other CAT tools cannot read ("MESSAGE: There are multiple root elements. Line 375, position 2.")
- Unable to use XLIFF file as TM
- OmegaT does not handle line breaks correctly on Windows
- OmegaT 6.1 with JRE does not work out of the box on Windows
- Broken gradle tasks on Debian
- Selection of match for pre-translation varies through different OS's
- Critical errors are logged, but no longer shown to the user
- Google2 Translate MT connector failed to parse response
- linux-install.sh script not aware of its location
- Incompatible among LanguageTool@6 and lucene-gosen@5 from omegat-org
- Error 403 when accessing different repo with different creds in same domain
- Integration test(docker) failure with 503
- Option-arrow not working in arm macOS
- Regular expression for custom tags
- Content of notes elements are not displayed correctly with Xliff filter
- ProjectFile has unwanted XML element otherAttributes
- If project memory is updated during load via tm/auto or tm/enforce, set project as modified
so that save also updates project_save.tmx
- Languagetool crashes when reloading the project
- Stardict dictionary displays apostrophe as html entity code
- Font does not scale on HiDPI display on Linux
- build/release: Windows binary signature with PKCS#11 HSM
- Team(git): when connecting new server, connection failed
- The COMPILE event is fired after the target commit
- Passphrase for SSH key is stored with key= [url removed]
- OmegaT ask passphrase to connect git+ssh server but dialog label is user/pass
- TipOfTheDay dialog do not close with enter/escape
- Team project failed to merge changes with TMXMerge
- Useless warning log from CSS parser library
- OmegaT cannot load a project and error dialog with FileSystemLoopException
- Default filters settings don't initialize options
- Error when trying to backup the project file on Windows
- Docker setup of Integration test is not working for Subversion
- Translation memories are not correctly reloaded after team synchronization
- Project not loaded if it contains DTD internal entities
- SRX conf file is produced with localized name of language
- Backup file does not created in no-team project
- Fixed "null" file names in search results when "Display: file names" checkbox was unchecked
- MT engines show JSON parser error as translated text
- Very slow segment switching with a lot of duplicates
- Duplication of some files in the distributed packages
- OpenSSH new key format and ECDSA/ED25519 keys
- Fails to load TM using tags
- Autosuggestion and IME malfunctioning
- Ctrl+Z incorrectly erases contents of segment Note
- Manually assigned shortcuts open parent folders instead of files
- Team projects not saving properly or stopping synchronization
- Lucene 5.2 does not work under WebStart
- JNA encoding issue on non-UTF-8 platforms
- The LaTeX filter should use \item as a delimiter
- Incorrect display of RTL segments in the Fuzzy Matches pane
- Quick stats don't reset if there are no more source files
- Print Exception with Invalid URL in "Import From MediaWiki..
- First session message in log not localised

Localization Updates:

- Catalan localization updated to 6.1 (UI, readme, documentation)
- Dutch localization updated to 6.1 (UI, readme, documentation)
- French localization updated to 6.1 (UI, documentation)
- Italian localization updated to 6.1 (UI, readme, documentation)
- Japanese localization updated to 6.1 (UI, readme, documentation) [/quote]

Wow again!

OmegaT 6.1 Beta Mac ARM | OmegaT 6.1 (beta) vs OmegaT 6.0

Epameinondas Soufleros — Tue, 02 Dec 2025 12:10:00 +0000

Forum: OmegaT support
Topic: OmegaT 6.1 Beta Mac ARM
Poster: Epameinondas Soufleros
Post title: OmegaT 6.1 (beta) vs OmegaT 6.0

Straight form the source:

6.1.0 vs 6.0.0

Implemented requests:

- Improve TMX validation error reporting: Show detailed parser errors in dialog instead of only in log file
- Tokenizer to support the snowball generated stemming mode
- Support Windows 11 and Linux on ARM64 for development environment
- Word selection according to the language of Source/Target by clicking in the editor pane
- Spell checker dictionary as a language module
- HunspellTokenizer to support stopwords
- Po: put prural source term in comment when nplural=1 langguages
- Support ngrams for local LT server jar launcher
- Localize UI for genuine dialogs in various languages
- Log filename to be date-time based
- TMX writer output in 6.1 should be the same as in 6.0
- Support Morfologik spell checker and use LT bundled dictionary
- Support U*ix variants
- Alternative translation highlight
- Add timestamp to log
- Apertium MT now sends whole locale code to server instead of only the language code
- Support for Stardict's Pango content type
- AbstractFilter should handle BOM when create reader
-Trim authentication details in team projects
- Provide package "deb" and "rpm" as distribution format for linux
- Download team project with a shallow history
- Give a selection of perHost/PerRespo credentials treatment
- Enforce checkstyles and suppress it for auto-generated files
- ResourceBundle Filter: default not to escape Unicode character
- Make repository connectors as plugin
- Make language libraries in LanguageTools as module
- ResourceBundle filter: "Don't translate NOI18N comment" feature optional
- Use SLF4J as logging facade framework
- SVN/Team project should respect access URL specified
- team: apache HttpClient for git connection
- Request to add new API to allow plugins/modules to add menu item in requested place
- Team: SVN support svn+ssh protocol with key authentication
- Team: SVN: Replacing trilead-ssh2 with Apache sshd
- Ensure that OmegaT functions properly under Java 21
- Better error message for omegat.project failure
- Generate JSON format stastics file when save
- Build System: update gradle version to 7.5.1
- Generate and compile TXT and JSON file when committing target files
- Ensure that OmegaT functions properly under Java 17
- MT: IBM watson accept 50KB text
- GUI: automatically adapt colour scheme to OS colour preference on Windows and macOS
- Update LanguageTool to latest version (6.1)
- Visual confirmation that dictionary was searched
- Remove TaaS terminology lookup
- Update to Gradle 7.3.3 or later
- Clarify requirements for DeepL API key
- Team feature: SSH support id_ecdsa and id_ed25519 for default key
- Use Jackson library as XML parser
- Add nashorn javascript engine[Java 17 compatibility]
- If multiple versions of the same plugin are present, only the latest is loaded
- Add Spell checker as a type of plugin
- [fuzzy] option in "Check issues"
- Use repository mappings in a local project
- Remove "Restore defaults" button where it has no function
- Upgrade to LanguageTool 6.5
- Upgrade to LanguageTool 3.6
- Improve TBX parsing
- Support SRX format
- Support M1/M2 Mac natively and distribute with Arm64 JRE.
- Distribution with Linux aarch64 JRE

Bug fixes:

- .PO filter bug: display issue when a msgctxt spans several lines
- Unable to import a team project to a path containing Chinese characters
- Wrong root element name for stats.xml
- NPE at program exit
- Sometimes called SegmentProperties.onEntryActivated after closed a project
- Mismatch in method name causes exception when selecting "Open Writable Glossary File"
- Spellchecker raised NPE when writing word list file
- Uncaught exception in weekly build (2025-01-18)
- Fix the IllegalArgumentError on sort with filter(Objects::nonNull)
- OmegaT failed to start if there are 'jar' file w/o manifest in plugin folder
- aligner average distance can be {0} which expected a numeric value
- fix: Glossary sort order: Change src length sort condition and use Language Dependent sorter
- Preferences/CutomColorSelector don't show notification immediately when modifying color
- Speller: morfologik: LT bundled dictionary not found in Dutch
- Console-stats command failed with error
- Removal of MED package save/load feature
- Failed to load "en-AU" LT language by IllegalArgumentException
- filter: bundle: when charsert configuration is US_ASCII, force unicode escape
- OmegaT 6.1 does not write startup message in log file
- Color customize UI label for marker come from tm/mt/ folder
- Fix behaviour where git repos would be recognised as SVN
- OmegaT does not show entreis of stardict-JMDict dictionary
- Links with ending parens in glossary panes
- Short glossary items are not recognized with Korean source
- Debug log in some classes are broken
- XLIFF1 filter produce broken trasnalated file
- sdlxliff filter does not display (some) comments
- When restart GUI on deb/rpm packaged OmegaT, it failed with java not found
- Preference to enable "Project specific External Command" is lost
- Windows launcher does not launch when witout_JRE installer used
- Glossary popups behavior changed unintended way
- OmegaT does not use cached MT result for translated segments
- Match statistics are affected by fuzzy match threshold
- PluginInstaller throws NPE in certain condition
- Issue window cause exception
- java.nio.charset.UnmappableCharacterException: Input length = 1
- Repository mapping with SVN cause error
- OmegaT 6.1 macos-arm version does not launch on macOS arm machine
- OmegaT 6.1 macos-arm version does not launch on macOS arm machine
- distribution for macOS only run on Java runtime 11
- Links that contain non ascii characters are not properly handled in glossary dialog
- CI: weekly release failed with permission error inside docker image
- OmegaT failed to start in specific case
- Unit tests failed on Windows
- OmegaT creates xlf file that other CAT tools cannot read ("MESSAGE: There are multiple root elements. Line 375, position 2.")
- Unable to use XLIFF file as TM
- OmegaT does not handle line breaks correctly on Windows
- OmegaT 6.1 with JRE does not work out of the box on Windows
- Broken gradle tasks on Debian
- Selection of match for pre-translation varies through different OS's
- Critical errors are logged, but no longer shown to the user
- Google2 Translate MT connector failed to parse response
- linux-install.sh script not aware of its location
- Incompatible among LanguageTool@6 and lucene-gosen@5 from omegat-org
- Error 403 when accessing different repo with different creds in same domain
- Integration test(docker) failure with 503
- Option-arrow not working in arm macOS
- Regular expression for custom tags
- Content of notes elements are not displayed correctly with Xliff filter
- ProjectFile has unwanted XML element otherAttributes
- If project memory is updated during load via tm/auto or tm/enforce, set project as modified
so that save also updates project_save.tmx
- Languagetool crashes when reloading the project
- Stardict dictionary displays apostrophe as html entity code
- Font does not scale on HiDPI display on Linux
- build/release: Windows binary signature with PKCS#11 HSM
- Team(git): when connecting new server, connection failed
- The COMPILE event is fired after the target commit
- Passphrase for SSH key is stored with key= [url removed]
- OmegaT ask passphrase to connect git+ssh server but dialog label is user/pass
- TipOfTheDay dialog do not close with enter/escape
- Team project failed to merge changes with TMXMerge
- Useless warning log from CSS parser library
- OmegaT cannot load a project and error dialog with FileSystemLoopException
- Default filters settings don't initialize options
- Error when trying to backup the project file on Windows
- Docker setup of Integration test is not working for Subversion
- Translation memories are not correctly reloaded after team synchronization
- Project not loaded if it contains DTD internal entities
- SRX conf file is produced with localized name of language
- Backup file does not created in no-team project
- Fixed "null" file names in search results when "Display: file names" checkbox was unchecked
- MT engines show JSON parser error as translated text
- Very slow segment switching with a lot of duplicates
- Duplication of some files in the distributed packages
- OpenSSH new key format and ECDSA/ED25519 keys
- Fails to load TM using tags
- Autosuggestion and IME malfunctioning
- Ctrl+Z incorrectly erases contents of segment Note
- Manually assigned shortcuts open parent folders instead of files
- Team projects not saving properly or stopping synchronization
- Lucene 5.2 does not work under WebStart
- JNA encoding issue on non-UTF-8 platforms
- The LaTeX filter should use \item as a delimiter
- Incorrect display of RTL segments in the Fuzzy Matches pane
- Quick stats don't reset if there are no more source files
- Print Exception with Invalid URL in "Import From MediaWiki..
- First session message in log not localised

Localization Updates:

- Catalan localization updated to 6.1 (UI, readme, documentation)
- Dutch localization updated to 6.1 (UI, readme, documentation)
- French localization updated to 6.1 (UI, documentation)
- Italian localization updated to 6.1 (UI, readme, documentation)
- Japanese localization updated to 6.1 (UI, readme, documentation)

OmegaT 6.1 Beta Mac ARM | What's new?

CafeTran Trainer — Tue, 02 Dec 2025 11:45:00 +0000

Forum: OmegaT support
Topic: OmegaT 6.1 Beta Mac ARM
Poster: CafeTran Trainer
Post title: What's new?

[quote]WolfgangS wrote:

I have downloaded the above mentioned release and realized that DeepL is not among the MT engins available.
What about the final release? [/quote]

What's new in 6.1 compared to 6.0.1?

OmegaT 6.1 Beta Mac ARM | It should be there

Epameinondas Soufleros — Tue, 02 Dec 2025 11:37:00 +0000

Forum: OmegaT support
Topic: OmegaT 6.1 Beta Mac ARM
Poster: Epameinondas Soufleros
Post title: It should be there

Searching the OmegaT list of feature requests, it appears that DeepL support has been implemented.

I have not tried it myself, as I do not use machine translation of any kind.

[Edited at 2025-12-02 11:38 GMT]

OmegaT 6.1 Beta Mac ARM

WolfgangS — Tue, 02 Dec 2025 09:59:00 +0000

Forum: OmegaT support
Topic: OmegaT 6.1 Beta Mac ARM
Poster: WolfgangS

I have downloaded the above mentioned release and realized that DeepL is not among the MT engins available.
What about the final release?

Open a Studio package with Omega T | Sure

Novian Cahyadi (X) — Mon, 30 Jun 2025 12:11:00 +0000

Forum: OmegaT support
Topic: Open a Studio package with Omega T
Poster: Novian Cahyadi (X)
Post title: Sure

[quote]Samuel Murray wrote:
I'm not sure if simply translating the SDLXLIFF file inside the SLDPPX file and re-zipping it and changing the file extension to SDXLRPX would always be sufficient. The SDLPROJ file in a return package is different from that of a forward package. It contains GUIDs and time stamps that get updated when the return package is created. [/quote]

You're more knowledgeable than I am when it comes to OmegaT, so I'll take your word for it.

Open a Studio package with Omega T | SDLRPX

Samuel Murray — Mon, 30 Jun 2025 11:15:00 +0000

Forum: OmegaT support
Topic: Open a Studio package with Omega T
Poster: Samuel Murray
Post title: SDLRPX

[quote]Novian Cahyadi wrote:
Anyway, OmegaT 6.0.1 can open SDLPPX directly. It still can't create a return package, however. If required, you can rename the translated package file extension to SDLRPX. [/quote]
I'm not sure if simply translating the SDLXLIFF file inside the SLDPPX file and re-zipping it and changing the file extension to SDXLRPX would always be sufficient. The SDLPROJ file in a return package is different from that of a forward package. It contains GUIDs and time stamps that get updated when the return package is created.

Open a Studio package with Omega T | Necroposting

Novian Cahyadi (X) — Mon, 30 Jun 2025 02:37:00 +0000

Forum: OmegaT support
Topic: Open a Studio package with Omega T
Poster: Novian Cahyadi (X)
Post title: Necroposting

Why resurrect a 1-year-old thread?

Anyway, OmegaT 6.0.1 can open SDLPPX directly. It still can't create a return package, however. If required, you can rename the translated package file extension to SDLRPX.

[Edited at 2025-06-30 12:09 GMT]

Open a Studio package with Omega T | I can do it

Johannes Wuelk — Sun, 29 Jun 2025 23:03:00 +0000

Forum: OmegaT support
Topic: Open a Studio package with Omega T
Poster: Johannes Wuelk
Post title: I can do it

[quote]Enrico Selleri wrote:

Can you do that for me? I really can't. [/quote]

I can do it in case you still need it. I translate Trados packages with OmegaT all the time.
I extract the sdlxliff from the renamed zip, translate that in OmegaT (requirement: okapi filters or similar plugin).

Then (optional) repackage the sdlxliff in a return package (rename finished zip to sdlrpx).

This is just a rough summary, I can go more into details if desired.
I also wrote a bash script that helps me to do these steps more automated/convenient.

Help! I work with Omega T 6.0 but my customer requires a bilingual file.What can I do? | @Enrico

Samuel Murray — Mon, 23 Jun 2025 11:23:00 +0000

Forum: OmegaT support
Topic: Help! I work with Omega T 6.0 but my customer requires a bilingual file.What can I do?
Poster: Samuel Murray
Post title: @Enrico

[quote]Enrico Selleri wrote:
Help! I work with Omega T 6.0 but my customer requires a bilingual file.What can I do? [/quote]
Many different files can be called "bilingual files" but there is at least a chance that the client is asking for a bilingual file in XML or XLIFF format, which OmegaT can't produce.

Really, if the client had wanted a bilingual file such as an XLIFF file, and if they had wanted it for a specific type of CAT tool, they should have specified that before you started the translation.

The groovy script suggested by Alinea.doc creates a table in HTML format, which is technically speaking a bilingual file. I've used the script with success, for situations where a two-column bilingual table is required. You can often also open the resulting HTML file in Microsoft Word or Excel and convert it into a DOCX or XLSX file.

It is also possible that the client wants a file that they can use do re-generate the translated file with. The HTML file mentioned above can't do that. It's also possible that the client will edit your bilingual file and then send you the edited version in the expectation that you will be able to import it and then recreate the translated file. The HTML file mentioned above can't do that. But the HTML file is, strictly speaking, a bilingual file.

It's possible that the client will want to load the bilingual file into a QA checking tool to run various quality control checks on it. I don't think the HTML file mentioned above will make that possible. However, QA tools can often perform QA on TMX files, so you might also want to supply the export TMX file to the client for this purpose.

[Edited at 2025-06-23 11:26 GMT]

Help! I work with Omega T 6.0 but my customer requires a bilingual file.What can I do? | Script

CafeTran Trainer — Mon, 23 Jun 2025 11:12:00 +0000

Forum: OmegaT support
Topic: Help! I work with Omega T 6.0 but my customer requires a bilingual file.What can I do?
Poster: CafeTran Trainer
Post title: Script

Download (copy) this script:

[url removed]

Put the file write_table.groovy somewhere in your Documents folder.

Run this:

Then this:

Finally, click "Run"

Help! I work with Omega T 6.0 but my customer requires a bilingual file.What can I do?

Enrico Selleri — Mon, 23 Jun 2025 09:28:00 +0000

Forum: OmegaT support
Topic: Help! I work with Omega T 6.0 but my customer requires a bilingual file.What can I do?
Poster: Enrico Selleri

Problems with the target text on Omega T | Tools - Check issues

Epameinondas Soufleros — Sun, 25 May 2025 13:44:00 +0000

Forum: OmegaT support
Topic: Problems with the target text on Omega T
Poster: Epameinondas Soufleros
Post title: Tools - Check issues

You can go to Tools > Check issues or press Ctrl+Shift+V