Maxprograms is back, take 2.

Free software by a world class XLIFF expert

I first wrote about Maxprograms in 2007. That was after Rodolfo M. Raya left Heartsome to pursue his activity as the Maxprograms software company. I’ve been meaning to write about his work for a long time now, especially since he decided to put all his products on Github, thus allowing translators to get the code, build the things, get the updates and run them on their side, for free.

Maxprograms also offers a lot of technical articles on the subjects of DITA, XLIFF and XML in localization. Check the page here if you are interested.

Rodolfo M. Raya is an editor of the XLIFF 2.0 specification and is a member of the OASIS XLIFF technical committee. He is also co-author of A Practical Guide to XLIFF 2.0.

April 15, 2023 update: Rodolfo has updated the build requirements.

• JDK 17 or newer is required for compiling and building
• Apache Ant 1.10.12 or newer
• Node.js 18.15.0 LTS or newer
• TypeScript 5.0.0 or newer

I've updated the version numbers below. Make sure you check the various requirements on the respective repository pages.

July 4, 2021 update: all of Maxprograms products are now available under an OSI approved Open Source license

Most of Maxprograms' products come with an easy-to-use installer and only the packages listed in italics below do not, because in their case an installer is not relevant.

If you check the repository list at https://github.com/rmraya?tab=repositories you will see the following software packages (among others). I added the product page on Maxprograms' site (the "..." links) to make it easier for you to find extra information:

• Eclipse Public License 1.0 (OSI approved)
  • Fluenta (DITA translation manager) ...
  • Swordfish (standards based XLIFF CAT, supports Trados Studio packages) ...
  • TMXEditor (TMX editor, as the name suggests) ...
  • Stingray (document aligner) ...
  • XLIFFManager (GUI for OpenXLIFF) ...
  • OpenXLIFF (command line utility to create, merge, validate XLIFF files) ...
  • TMXValidator (validator/cleaner for TMX files) ...
  • TMEngine (translation memory engine) ...
  • SRXEditor (SRX editor) ...
  • MVDServer (simple web server) ...
  • XLIFFValidation (web-based XLIFF validation tool) ...
  • RemoteTM (remote TM server) ...
• MIT (FSF and OSI approved)
  • Conversa (DITA publisher) ...
  • KeysAnalyzer (DITA keys analyzer) ...

A "normal" freelance translator would use Swordfish as an XLIFF translation editor/project manager. With eventually TMXEditor to work on client TMX, Stingray to align file sets, and TMXValidator to check and clean TMX files.

More advanced users, or PMs would use XLIFFManager or OpenXLIFF, along with XLIFFValidation and SRXEditor.

DITA specialists would use Fluenta, Conversa and KeyzAnalyzers.

Users who want to self-host services would use XLIFFValidation, MVDServer, RemoteTM.

Maxprograms' packages offer pretty much anything a translator would need, in very cleanly packaged solutions, with excellent user support, either community-based (on groups.io), or directly from Maxprograms if you are a subscriber.

And if your main translation editor in not Swordfish, you can still benefit from all the other packages depending on your needs.

DIY software

Fluenta, Swordfish, TMXEditor and Stingray are subscription-based, but allow translators to run the software for free from the source code (RemoteTM is proposed as a "software as a service" hosted by Maxprograms, but you can host it on your own server if you want).

What that means is that the packaged installer comes as a subscription, but if you don’t mind using Terminal to run your software, which is, let’s be honest, not much of a hurdle, you can use the software, access its updates, eventually make modifications for your own use, etc. for free.

The requirements to download, build and run the software are all given on each product’s Github repository, but here is the gist:

• JDK 17 or newer for compiling and building (https://adoptopenjdk.net)
• Apache Ant 1.10.12 or newer (https://ant.apache.org/)
• Node.js 18.15.0 LTS or newer (https://nodejs.org/)
• TypeScript 5.0.0 or newer (https://www.typescriptlang.org/)

Ant, Node.js and Typescript are also available from Homebrew (https://brew.sh).

To build the software you’ll need to checkout (clone) the repositories. You also need to make sure that Ant uses Java 17 to build the package.

Rodolfo gives all the steps for building (for ex. Stingray):

    $ git clone https://github.com/rmraya/Stingray.git
    $ cd Stingray
    $ ant
    $ npm install
    $ npm start

Java ?

Maxprograms' applications used to be multiplatform Java only applications. Now they use a combination of Java and Javascript (even if the names are close, the two languages are totally unrelated) see below for Rodolfo's explanations.

Apple used to ship Java when macOS was young. It was in fact one of its selling points. Apple has stopped distributing Java a long time ago and now suggests that users install Oracle Java. Changes in the Oracle license and the availability of free Java distributions have allowed users to still benefit from Java without having to pay for a commercial user license.

Even after installing Adoptium's JDK, your machine will still prefer to use an older Java version if you have one installed on your machine.

Which means that if you run:

$ echo $JAVA_HOME

in Terminal and it won’t point to Java 17, you won’t be able to build the software.

On my machine, the above command gives

/Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home

A short investigation shows that the newly installed Java 17 is here:

/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/

The way to have ant use Java 17 instead of Java 11 for the build process is simply to give ant the right pointer:

$ export JAVA_HOME=/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/; ant

Once you’re done with the process, you can export your Java_Home back to its original value, just to be on the safe side. You’ll need to point to Java 17 only to build the software after a code update ($ git pull).

Back to the command line

Once you’ve run

$ npm install

you’re free to launch the application any time you want with

$ npm start

That’s it. This procedure works for Swordfish, Stingray, TMXEditor.

You can also create an Applescript that packages the whole process into a nice application that you can use to launch the various packages as you'd launch standard macOS applications.

A simple Applescript to do that could be:

use AppleScript version "2.4" -- Yosemite (10.10) or later use scripting additions set SwordfishPath to "/path/to/Swordfish/local/repository" set myCommand to "cd " & SwordfishPath & "; npm start" tell application "Terminal"'s front window delay 0.1 do script myCommand in its last tab end tell

↑ Electron ?

Maxprograms' applications used to be Java only applications. But Oracle (Java's main caretaker) neglect of GUI libraries led to a not very satisfactory situation for Java GUI application developers. Here is Rodolfo's rationale for his move away from Java-based GUI libraries:

I use HTML + JavaScript + CSS for the UI and Java for core libraries. In essence, my apps are web pages running on a Java server.

NodeJS provides access to Chrome's V8 JavaScript Engine. Electron is a bridge that provides native windowing environment for JavaScript pages displayed on top of Chrome.

JavaScript is a powerful language, but it is dangerously sloppy. Instead of coding directly on JavaScript, I use TypeScript (which is a safer language) and "transpile" my code to JavaScript for deployment.

I have not switched completely to TypeScript because there aren't good XML libraries for JavaScript. All translation standards are defined using XML and Java is still the best option for handling them. The good news is that JLIFF (a JSON-based version of XLIFF) is currently in development.

Why switch to HTML + CSS for the UI if Java is a cross-platform tool?, you may ask. The answer is simple: Java dropped its major UI libraries.

Initially, Java shipped with AWT, a horrible toolkit with poor design and feature lacking. AWT was so bad that two options replaced it: Swing (originally developed by Sun and currently used by OmegaT) and SWT (the one I used in Swordfish, developed by Eclipse Foundation).

Oracle deprecated Swing in Java 8 and replaced it with JavaFX. When Java 9 was released, JavaFX was abandoned and development moved to its own open-source project, away from Oracle.

The Eclipse Foundation, which developed and maintained SWT for years, stopped improving SWT when JavaFX appeared. It did not fully embrace JavaFX and SWT is languishing since then.

With SWT dying, I looked at JavaFX. It tries to mimic HTML + CSS without success. Not good enough. The real alternative: adopt HTML and CSS.

Et voilà!

I'm not even scratching the surface of what Maxprograms has offered to translators since Heartsome disappeared. Each software package deserves a whole article.

Maxprograms' packages are yet another proof that working on macOS as translators, project managers or localization engineers is possible. And we're lucky that most of the multiplatform packages that allow us to work on macOS are backed by very talented people and communities who do their best to keep us from having to change of platform.

Disclaimer: I am not affiliated in any way to Maxprograms. Just so that you know...

XLIFF Editors...

[Updated on March 21 2021 to include info on the DGT OmegaT plugin, and the new Swordfish version]

There are plenty of "XLIFF Editors" that pop up on the Mac App market. A number of them are free, most are not super expensive. But all confuse "XLIFF" with the poor subset that Xcode outputs. And that confuses the people who need XLIFF editors the most: professional translators.

XLIFF is an industry standard used in all the localization/translation world. Xcode developers who need the ability to edit their output have all the rights to create quick tools that will help them with that task. But please, don't call that XLIFF editors. What you do is Xcode l10n files editors, basically just XML simple parsers outputing the resulting data in a 2 column table with a native GUI. That's pretty much it. And that's very fine. But it's not XLIFF.

If any of those developers had actually worked with a professional translator to see what are the features required to work with XLIFF (and all the other related standards: TMX, SRX, TBX, ITS, etc.) they would never call their tool an XLIFF editor, just like TextEdit is able to edit XML but nobody would think of calling it an XML Editor...

Mac developers are very picky when it comes to what looks good. Good for them. But would they rather develop in Xcode or in TextEdit? Professional translators on the Mac who need to work with XLIFF currently have the following not so good looking but rock solid choices (all Java based, by the way):

• FOSS, very active, used by professionals all over the world:
  OmegaT and the Okapi Framework filter plugin (GLP/LGPL)
• The DGT-OmegaT site also offers a high quality XLIFF plugin for OmegaT:
  StaX Filters (GPL3), documented here.
• FOSS, active, XLIFF and ITS dedicated editor:
  Ocelot, by the Okapi Framework
• Proprietary, but personal use of the source code is free, by Maxprograms:
  Swordfish, and the code is hosted on Github: /rmraya/Swordfish
  Maxprograms has moved from Java to Node.js, but that matters only if you use Swordfish from the source code.
• FOSS, not active anymore, used to be used by professionals all over the world:
  Heartsome's Translation Studio (GPL)

XLIFF is a serious standard, and translators need rock solid standard support to work. If your editor does not have inline tag/segmentation/legacy translation support, call it anything but XLIFF Editor, please.

Also, this is not a rant. This is a reminder: there is a market for robust native pro-level translation tools on Mac. With Microsoft Office for Mac feature for feature equivalent to the Windows version, translators and localizers have little need to stay on Windows machines. Except that the biggest pro-apps are Windows only. And that's a shame.

Using XLIFF as your point of entry into the l10n world is a good and relatively easy way to access a large market (pro conversion engines to and from XLIFF already exist: see the Okapi Framework). But the point where you can compete with the incumbent and actually make money is way higher than what you think.

Office 2007 files (.docx, .xlsx, .pptx) on Mac

(updated to reflect the release of StarOffice 9 for Mac and the OOXML conversion software for Office 2004)

Microsoft Office 2007 for Windows (and its Mac counterpart: Microsoft Office 2008) uses a new file format that has been available for a while now as .docx, .xlsx or .pptx ("x" to distinguish them from the standard MS formats).

The file format is commonly known as OOXML or OpenXML, or more simply as Microsoft Office 2007 format.

Even if the new files don't seem to be very widely used, they sometimes end up on a Mac user's desktop, especially since they are the default file format of the two suites (i.e., you need to go through a number of loops to save to a different format)...

What to do when you encounter such files ?

Since I do not own Office 2008 and I did not have the OOXML update for Office 2004 at the time of the writing, I had to test access with OOXML files created with NeoOffice, from "real" Microsoft .doc, .ppt and .xls. All of the test files were pretty complex and quite heavy and had all been created originally on various versions of Microsoft for Windows.

Access through proprietary applications

The iWorks '08 way

iWorks: $79 from Apple

As far as I can tell, iWorks '08 applications Pages and Keynotes opened the .docx and .pptx files I had created without any problems.

And the result was as good looking as the original files. Very impressive.

When I tried to open the .xlsx file, Numbers was considered as the default application (even the converter was not listed) but it was unable to open it correctly. I'll need to have a "genuine" .xlsx file to test Numbers' capacities.

The problem with iWorks it that it cannot save a file to the new format. It can save it to the iWords default format or to the old Microsoft format, along with a few other more classical formats.

The Microsoft way

Microsoft Office 2008: $399.95 retail, $284.99 online, $239.95 retail upgrade version, $194.99 online upgrade version from Microsoft.
(The prices given correspond to the cheapest available version for professionals, the "Home & Student" package is not available for commercial activity.)

The Mac equivalent of Office 2007, Office 2008, has been available for a few months already. Office 2008 is the quickest way to access the new file format in a relatively smooth and painless way.

If you don't want to acquire Office 2008, you can download Microsoft's "Open XML File Format Converter for Mac". The application is available from here. It is at the bottom of the page, if the URL has not changed...

The converter requires OSX 10.4.8 or later. Microsoft also says that to view the files, you need either Microsoft Office 2004 11.3.4 or later, or Microsoft Office v.X 10.1.9 or later.

If you also install "Microsoft Office 2004 for Mac 11.5.0 Update" (description available here: http://support.microsoft.com/kb/953824) you'll also enable "Office 2004 for Mac to read and to write Office documents that are in Open XML Format".

The StarOffice 9 (beta) way

StarOffice: $69.95 (StarOffice 8 price, 9 is still beta), from Sun Microsystems.

StarOffice 9 beta is available from here:
http://www.sun.com/software/staroffice/get_beta.jsp

It should work pretty much as OpenOffice.org 3.0 beta. See below.

System wide support on Leopard (OSX 10.5)

Leopard: $129, from Apple.

If you don't (plan to) own any recent version of Office for Mac what can you do ?

Leopard users have the free option of using the new TextEdit. It can open and save the new file format.

OOXML support is system wide, which means that the Finder and other applications will also give you a "quicklook" of such files. Although not all files are equal under Quicklook. Some are displayed properly, some are displayed as a white icon and no contents is shown... The test .pptx worked, the .docx and xlsx did not.

So, support is not extremely good and I would not rely on it to check the translatable contents of a client file...

Access through free applications

OpenOffice.org and NeoOffice anyone?

Users on Panther (10.3) and above can use NeoOffice 2.2. NeoOffice is a sister application of OpenOffice.org.

The current available version of the standard OpenOffice.org (2.4) does not include OOXML support but NeoOffice includes special goodies, like OOXML support, that are found in Novell's version of OpenOffice.org, which is, sadly, not available for the Mac...

As of May 7th, the beta version of OpenOffice.org 3.0 is available. This version does include support for OOXML.

As written above, I used NeoOffice to create Office 2007/OOXML files with various degrees of success in terms of interoperability. I am pretty sure NeoOffice could open relatively complex files since the files I fed it for OOXML output were fairly complex, although I'd need to test that.

As text ?

An extreme way to access the contents of such files it to handle them as if they were zipped, unzip them and find the document.xml located somewhere in the folder hierarchy that appears (it would be under /word/ for a Word document). This file is standard XML and can be opened in any text editor.

To properly access the contents of the file, you'd need to use Okapi's Tikal utility, available for the Mono (free) running environment. Tikal should be able to extract the contents of the XML into an XLIFF file that you can later load into a translation tool...

Translation

Once you have access to the file, you can translate it by overwriting it in the application of your choice. Saving the resulting file to .docx will produce results that vary with the application you used. A best bet would be to save the result to .rtf for delivery.

OmegaT and other Java based applications

If you want to use a translation memory tool, the few I know that directly handle OOXML are OmegaT, Swordfish, the newborn from Maxprograms, and Heartsome's Translation Suite.

Appletrans

If you have converted the file to .rtf or HTML before translation, AppleTrans should be able to handle it directly.

Okapi's Tikal for conversion to XLIFF

Or, as written above, you can use Okapi's Tikal command line utility to convert its contents to XLIFF and translate it in any of the above mentioned applications.

Wordfast

The Microsoft converter opens the file in Word in the RTF format and you can then use WordFast to translate it directly (from within Word 2004 / Word v.X).

OpenLanguageTools

With hacks, you can also translate the document.xml file in OpenLanguageTools.

Have I forgotten your favorite tool ?