If you need to run OmegaT on macOS with a set of custom options, it’s possible to do so by running java -jar --your_options /Applications/OmegaT.app/Contents/MacOS/Java/OmegaT.jar in Terminal. This is all great, but if your project is located in a folder that macOS considers restricted and asks you for permissions, such permissions will be granted to Java, not to OmegaT. It means that other Java programs will have those permissions too, even if you didn’t intend it to be so.
You can also add those options by editing the Configuration.properties (OmegaT configuration) as well as the Info.plist (Java configuration) files located inside the OmegaT.app package. But it means that OmegaT will run with them each time you start it, which might not be what you wanted (for instance, if you add a custom config folder or start OmegaT with --no-team option, you probably don’t want it be the new default).
A much better way is to start it using open: open /Applications/OmegaT.app -n --args --your_options
If you have OmegaT.app located elsewhere, just change the path. -n means that it will start a new instance, so you may have more than one projects open at a time. Anything that comes after --args will be interpreted as arguments (options) passed to OmegaT.
OmegaT comes bundled with several scripts. Some of them are of little practical use as they are included as examples for users willing to write their own scripts.
The bundled scripts are located in scripts subfolder of the folder where OmegaT is installed. Often the installation is done in a location where a regular user doesn’t have write permissions, which means adding and removing scripts can be complicated.
Luckily, OmegaT permits setting an arbitrary location for scripts. Do that! It can be any location where you can write to. It doesn’t matter if it contains no scripts at the moment: you can add only the ones you need, and only as you need them. It makes sense to place the scripts folder into the OmegaT config folder (the folder where OmegaT stores its settings) just for convenience.
But it can, of course, be any other folder.
Copy the scripts you need to the folder that was set for scripts. If you’re downloading from GitHub, you might need to show the desired script in raw format, and then save the page. If it saves as filename.groovy.txt, just remove the .txt part. If the file got saved in your Downloads folder, just move it into the folder set for your scripts.
In OmegaT, open Tools → Scripting, in the newly open Scripting window select the script you need (left part of the window) and hit Run (lower left corner).
If you need to run a script quite often, there is a way to assign shortcuts to up to 12 scripts: Select the script you want to run with a shortcut Right-click on one of the 12 buttons in the lower part of the Scripting window Select “Add Script”
The script thus installed is available under Tools, or can be run by pressing Control+Shift+Fn (Fn is a function key at the top of the keyboard, n is a number between 1 and 12, and the number on the button in the Scripting window corresponds to the number on the function key)
The earlier version of this script was described in this article. Here I’m announcing the update to the script which makes it possible to include:
Segment ID for each segment (applicable only for some file types)
Translator’s ID of the segment’s translation creator
Translator’s ID of the segment’s translation editor
Visual marks to show segments’ uniqueness or repetitions (grayish background, marks 1 or + in the dedicated column: for the first occurrence, or further instances of the repeated segment, respectfully)
Visual marks for alternative translations (different font color, mark a with a different background in the dedicated column)
Visual marks for untranslated segments (mark NT in the dedicated column)
Visual marks for paragraph boundaries (upper border over the source and target text which visually groups the text belonging to the same paragraph)
All of the above features are optional, though they are on by default. To disable or change them, editing the script is required, but all those lines are very easy to understand, they have comments, and are placed almost in the very beginning of the script:
Unlike the earlier version, the script produces the tabular output:
A few years ago I wrote a script that exported the whole OmegaT to an HTML table. I used it a lot myself, and I know quite a few other people found it helpful too. The problem with the table produced by that script was that it had no way to show repeated or alternatively translated segments. I’ve rewritten the script since, but never published an announcement about that new version. Now I did a few more changes, and thought that it’s about time to fix that omission.
It has been possible for quite some time now to choose which Glossary pane layout to use in OmegaT. Selection isn’t that great, only two layouts are provided: Default and Dictionary. But at the same time this feature had been introduced, it became possible to add custom layouts via plugins. I haven’t seen any, but the possibility is there. And just recently, Hiroshi Miura, a very prolific OmegaT developer, published a plugin skeleton just for this purpose. I used what he generously shared, and made an alternative compact layout for the Glossary pane.
It puts target terms right after the source term on the same line, and separates them only by a vertical bar and spaces. If there’s a comment for the term, it follows it immediately enclosed in square brackets. If OmegaT is set up to merge multiple target definitions for the same source term, and there are duplicated entries (i.e. two or more identical target terms for the same source term) with different comments, the comments will be separated by the vertical bar, but the term itself won’t be repeated.
To enable this layout in OmegaT, download the plugin (the ready-to-use jar is in the Releases section), put it into plugins subfolder in your OmegaT config folder, restart OmegaT, and select it under Preferences → Glossary → Glossary layout: → Compact Glossary Layout
Over the years of my daily use of OmegaT (I started using it back in 2009), I helped quite a few translators to make their first steps with the program. The funny thing is that almost every time a new person tries to learn the program, we change some of the same defaults to make it more usable and comfortable. So I thought it might be a good idea to collect those few initial setup changes here as a small series of posts so that anyone could refer to them at any point.
The first thing I always have new users change is the Editor behavior.
Below you’ll find a quick and dirty live preview solution for OmegaT on GNU/Linux.
In order for it to work, you’ll need any command line converter to convert your target files to PDF, and any PDF viewer to view the converted file. In the solution provided here Zathura PDF viewer is used. It is a very lightweight, keyboard-driven (albeit with vi-like keybindings) application that can invert document colors using a custom color scheme, and, most importantly, it reloads documents as they are changed, but keeps the previously open position, which makes it ideal for live previewing. Target files are converted using LibreOffice since I had it installed anyway; but any other command line tool that converts to PDF would do.