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 + Okapi Framework filter plugin (GLP/LGPL)
FOSS, active, not as used as OmegaT *because* limited to XLIFF and ITS:
Ocelot, by the Okapi Framework
Update: Ocelot is "limited" compared to the other solutions that offer either dozens of filters or round trip conversion tools for other formats to XLIFF. Limitation is not about XLIFF and ITS support.
FOSS, not active anymore, used to be used by professionals all over the world:
Heartsome's Translation Studio (GPL)
Proprietary, by Maxprograms, one of the main actors behind Heartsome's code:
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.
Popular posts (last 30 days):
About backups A working backup is like a stock of 10 billion masks waiting for a pandemic. You only use it when things go bad and since yo...
[Catalina update: the build instructions for IceCat 52.3 do not work anymore with Catalina. There is a weird error that says "C++ compi...
Regular expressions When you edit glossaries or translation memories a few regular expressions always come in handy. Regular expressions...
About 4 years ago I got a job where I needed to transcribe about 40 hours of interviews. I wrote most of this article then and let it to res...
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. Bu...