Pruning Recent Projects Menu in OmegaT

When you work on a bunch of smaller projects in OmegaT, or when you manage number of projects for your team, more often than not you end up with items in the Open Recent Project that are no longer available because the project folder was renamed or removed. To fix the issue, I put together a tiny script that checks each item in the list, and repopulates the list only with the projects that are still available.

The script is available at GitHub.com and SF.net.

It can be added to the scripts folder and run manually. If the script is placed into a subfolder named application_startup inside the scripts folder, it will run automatically each time OmegaT starts (not immediately, though, there’s usually a delay), and your Recent Projects menu will be always tidy.

Comments and bug reports are welcome.

Happy translating!

This script has been developed for cApStAn.be

Project-specific custom tags and flagged text

A number of OmegaT settings can be either global or project-specific. Unfortunately, custom tags and flagged text definitions are not in that category of settings. A way to work around this limitation is creating a set of config folders and using one of them depending on the requirements for a particular project. This is doable, but can get messy pretty fast. There was a long discussion about making these two settings project-specific too, but it hasn’t been in implemented in OmegaT as of yet.

I wrote a script that needs to be placed into a folder named project_changed inside your scripts folder. This script checks if there are two files inside the omegat subfolder of the currently open project: omegat.customtags and omegat.flaggedtext. If either or both files are found, the RegEx expressions in them will be used in the project. While the project is open, changing to the RegEx should be done in a normal way, through OmegaT preferences (Preferences > Tag Processing). If the definitions in the newly open project are different from the ones used before, the project will reload once upon initial loading. Global custom tags and flagged text definitions are stored in omegat.customtags and omegat.flaggedtext inside the OmegaT configuration folder.

There are a few minor drawbacks with this approach:

  • It is impossible to edit global definitions while no project is open. And if the project is open, it needs to contain no project-specific custom tags and flagged text definitions.
  • Project-specific files with the definitions need to be copied to the project manually. The GUI doesn’t indicate in any way whether these are global or project-specific. If the global definitions are a passable starting point, those two files can be copied from the config folder (they will be created there automatically and will be populated with whatever RegEx was saved in OmegaT when the script was activated for the very first time, or if those files were deleted).

The script can be found on GitHub and Sourceforge. Any comments, complains and praises are always welcome.

This script has been developed for cApStAn.be

OmegaT windows automatically open on startup

When OmegaT loads a project, it also pops up a window called “Project Files” that lists the supported source files in the project. It’s handy if you have multiple files, but I often find myself hitting Esc as soon as it pops up to get it out of the way. This window can be called up at any time by selecting Project > Project Files or pressing Ctrl+L/⌘+L, so it would be great if this automatic display of the window was disabled. There is no GUI option to do this in the preferences, but there is a “hidden” preference for that (meaning that it can’t be changed using GUI, but can be set directly in the OmegaT configuration file). The name of the preference is project_files_show_on_load, and it could be set to false by editing omegat.prefs in the OmegaT configuration folder. But if you don’t feel comfortable editing that file, I’ve put together a script that will toggle this preference between true and false. Just add it to the scripts folder. Each time it is run, the preference is toggled.

Another window I wish would open automatically every time OmegaT starts is the Scripting window. The way the whole scripting shebang is implemented in OmegaT makes it next to impossible to get the window to open with a keyboard shortcut. There is a menu item under Tools to open the Scripting window, but one can’t assign a key combination to run it without going to the menu. So here’s a script that opens the Scripting window whenever it runs. It makes almost no sense to put it directly in the scripts folder because you would have to open the Scripting window first to run the script. But if the script is placed in the application_startup subfolder of the scripts folder, the scripting window will open every time OmegaT is started.

Spellcheck menu

Here’s a script that jumps the caret to the closest misspelled word in the current segment (in the direction towards the beginning of the target text) and brings up the context menu that you usually get on a misspelled word. It allows to correct, add, or ignore misspelled words in the current segment without using the mouse or pressing arrows to move the caret to the required position in the text. If you’re familiar with Alt+F7 in MS Word, you get the idea. The script should be assigned to one of the 12 available script slots, and then it can be run by pressing Ctrl+Shift+Fn. If Alt+F7 in MS Word is something that you use often, it makes sense to assign it to the slot 7 and run it with Ctrl+Shift+7 to make it easier to remember.

Context menu with spelling suggestions called by the script

As usual, the script can be downloaded from two locations:

Any comments or suggestions are always welcome. If you find it useful, there’s an easy way to say thank you.

Launching external apps and scripts from OmegaT

OmegaT can launch external programs and scripts and pass certain project-specific data as parameters, and this is quite useful.
There are three ways to do this:

  1. External searches (global or project specific)
  2. Post-processing commands (global or project specific)
  3. OmegaT scripts

External searches can pass the text selected in OmegaT’s editor to the web browser as a URL to open. Such URLs consist of a fixed part (e.g. https://en.wikipedia.org/wiki/) and the selected text inserted somewhere in the URL instead of the placeholder ({target} in the External Search configuration). It’s also possible to open any other program instead of a web browser. This makes sense if the program you want to run is a dictionary application or other reference software that can accept parameters from standard input. An excellent example of such software is Goldendict.
What this approach lacks is the capability to pass other useful information, such as project languages or file locations. Not a big problem, especially if you are translating from one or two languages. But even with two, if you want to use a multilingual resource, it becomes necessary to create a separate external searches for each language, though the difference often is just a language code. There are ways to work around this limitation, but I’ll perhaps discuss that another time.

Post-processing commands have a much bigger list of supported variables, and they are great for tasks like file format conversion or live preview. Despite their versatility, these commands cannot receive input directly from OmegaT’s editor. Moreover, they only execute when generating target files, making them less suitable for tasks like lookups or note-taking that may need to be performed multiple times even while working on a single segment.

With OmegaT scripts it’s possible to execute an external application and pass almost anything related to the project: source and target text of the current segment, selection in the editor, paths to the various files in the project that OmegaT is aware of, project languages along with their country variants, current file, and more.
Years ago I did write a script exactly for that purpose, and I think it was my very first script in Groovy. It’s quite straightforward: it only collects a whole bunch of variables and passes them to an external script or app that can decide how to handle them. That external part was written with Linux in mind. GNU/Linux readily provides Bash shell (or a number of other shells to chose from) that makes it possible to combine multiple components into a practical routine tailored to specific requirements, and Zenity, a handy utility that simplifies the creation of basic GUI dialog windows for seamless interaction with Bash scripts. The concept was very simple: OmegaT gets all the needed variables and launches my Bash+Zenity script. This script, in turn, presents a list of various actions, and once a choice is made, the corresponding action is executed. It worked beautifully (at least according to my definition of beauty). Over time, the list of actions expanded, and I relied on it daily.
Recently I switched to macOS, and at first those thing were badly missed while working in OmegaT. But it turned out that Zenity is available through Homebrew, while Bash is already available out of the box. Thus, the only task remaining was making sure my old creation is compatible with both operating systems.

So here I present that combination now working equally well on Linux and macOS.

Nota bene:

  • <omegat_config> below refers to OmegaT configuration folder. You can access it by pressing OptionsAccess Configuration Folder in OmegaT.

  • If the window called Scripting that pops up by pressing ToolsScripting is empty for some reason, you may want to go to <omegat_config> and create a folder called scripts there (note the plural).
    Then in the Scripting window, click FileSet Scripts Folder…, and select the newly created folder (under Linux and Mac, you can simply drag the folder onto buttons in the file chooser, and that folder will be selected automatically)

  • Any new scripts should be placed into this folder. If you need any of the scripts bundled with OmegaT (there are a few useful ones), copy them over from where OmegaT is installed (OmegaT.app/Contents/Java/scripts on Mac)

So, here we go:

  1. Add the Groovy script to your OmegaT scripts.
    • The script is called utils_external_opener.groovy, and it can be downloaded here and here.
    • The script expects an executable called opener to be located in folder <omegat_config>/external-openers/. It will not continue if neither that folder, nor the executable is found. See p. 2 for details about that external part.
    • When the groovy script is successfully run, it creates a file called opener.vars in <omegat_config>/external-openers/. It is a plain text file containing the collected variables in this simple format:
      variable='value'
    • The script then executes <omegat_config>/external-openers/opener and passes the location of the opener.vars to it.
  2. Copy my opener to <omegat_config>/external-openers/
    • To do so, download the zip file containing the external launcher from here or here.
      Place the zip inside <omegat_config> and unpack there. It will create <omegat_config>/external-openers with the file opener. After that, the zip file can be deleted.
    • opener is a Bash script that doesn’t do anything useful on it’s own. It simply lists everything it finds in <omegat_config>/external-openers/actions/ via a selection list dialog (if you used the zip file, the subfolder actions/ and its contents were added too). Once the selection is made, the selected item is executed. Items under <omegat_config>/external-openers/actions/ can be scripts written in various scripting languages (as long as your OS knows how to execute them), or compiled binaries, but not application bundles.
    • I offer three such action scripts: “Open Directories”, “Rename target files”, and “Web Lookup”. “Rename target files” asks several questions when it’s executed, the other two present further list (but that’s as far as the lists go in the bundle I here present). The Web Lookup works with the selected text, or, if no selection is made, with current segment’s source text. Wikipedia languages, and DeepL and Google language pairs are taken from the current project language settings.
    • Make sure that <omegat_config>/external-openers/opener and everything under <omegat_config>/external-openers/actions/ is set to be executable.
  3. Make sure Zenity is installed.
    • On macOS, you may need to enable Homebrew and install Zenity with
      brew install ncruces/tap/zenity
      (this is a Zenity rewrite that doesn’t depend on GTK+; I haven’t checked the GTK+ version available through Homebrew and Macports.)
    • On Linux, Zenity is most likely already installed, but if not, just install it using your package manager.
  4. There’s Bash and Zenity for Windows, but there’s no time whatsoever to make sure this setup runs on Windows too. If anyone is interested to check and adapt it as needed, I’ll be happy to incorporate their findings.
  5. The script described here makes the following OmegaT info accessible to the external opener:
    • selected text (if nothing selected, the current segment’s source will be used)
    • URL-encoded selected text
    • current segment’s target
    • URL-encoded target
    • current segment source
    • URL-encoded source
    • project’s path
    • path to the omegat subfolder of the current project
    • path to the current project source folder
    • path to the current project target folder
    • path to the current project tm folder
    • path to the current project glossaries folder
    • path to the current project dictionaries folder
    • path to the current file open in the editor
    • path to the writable glossary
    • path to the OmegaT configuration folder
    • path to the OmegaT scripts folder
    • source language code
    • target language code
    • source language country variant
    • target language country variant
    • source language name
    • target language
    • language in which OmegaT is run

If you have questions, you can always leave them in comments. Happy translating!

Merge and split segments in OmegaT

This article is about performing merging and splitting segments in OmegaT using a convenient groovy script.

Continue reading

Select Source Text in OmegaT

There might be a number of situations when the whole text of the current segment’s source is needed for something other than translation itself: performing concordance or web search, writing a translation note in another application, asking your client or project manager about the text, etc.

Currently, in OmegaT it can be achieved in several fairly easy ways:

  • Selecting the text with the mouse (but who wants to do that?)
  • Inserting the source text into the target area (Ctrl+Shift+I or Ctrl+Shift+R) and selecting the text there
  • Unlocking the text caret with F2, and then using arrow buttons and Shift to select the text
    (If you want to have the caret unlocked by default when you start OmegaT, there’s a way to do it)

All that is fine, but it would be much nicer to have a simple shortcut to select that source text, similar to what Ctrl+A does (which in OmegaT Editor selects everything only in the target field, or the complete textual contents of other panes if the got focus). I’ve written a simple script that does just that, and though scripts can be bound only to Ctrl+Shift+F[1-12] keys, it’s better than not having a shortcut at all. Hopefully, this function might appear in OmegaT itself, but before it happened, here you have it:
Get it from SF.net
Get it from GitHub

To learn how to install and use OmegaT scripts, see this quick guide.

Happy selecting!

Jumping between segments in OmegaT

Going to the segment you need is quite easy in OmegaT (in most cases, but when it’s not, there is the wonderful scripting functionality).

Continue reading

Export #OmegaT Project to Excel (UPDATE)

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
  • Segment notes
  • 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:

Scripting window with the script options in focus

Unlike the earlier version, the script produces the tabular output:

Segment #Source TextTarget TextUniq/AlSegment IDCreatorChangerNote

The script can be downloaded from
SF.net repository
GitHub repository

To learn how to install and use OmegaT scripts, see this quick guide.

Comments, suggestions, complaints, and donations are always welcome!

Happy spreadsheeting!

Export OmegaT project to an HTML table

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.

Continue reading