From time to time on various groups/forums which I follow appears the post like "Learn how to convert format x to y". Usually it's coming from some guy (or company) who's trying to sell his converter, or at least training around it, to you. There's nothing wrong with it, people need to earn money. Plus there's definitely market for it. If you're freelance translator working from home you probably don't have much of support from engineers, if any at all. But you need to deliver the project, so why not to use such helpful tool.

Problem arises when these tools are bought by LSPs (Localization Service Providers), because it usually means that they lack engineers in their team and that's always bad. Imagine situation where file you want to convert is slightly different from what this tool expects as input, or maybe it's broken (happens often in localization). Then you'll be just sheepishly waiting for support of this tool to come up with solution to your problem (if it'll ever happen), or keep bugging whoever provided you with broken file to fix it (often not possible as this person also has no clue what and where went wrong).

And that's why you need an engineer in your team. But pay attention, engineer, not the guy who can click few buttons in Trados Studio to generate files for you or setup a project. Engineer is the person who understands his tools and file formats he works with. Who knows that if you have XML file then it can be converted to basically anything you want, and both Xliff and TMX (common formats in localization) are XMLs. Such guy would know that given file doesn't work because there's problem with encoding, BOM, tag, delimiter, or any other thing which sounds like Chinese to you.

Need example? OK. Some time ago I was faced with a problem where aligned document couldn't be imported to the TM (Translation Memory), fortunately it was possible to export it as mqxlz file (memoQ package). I knew that this file is basically zip containing memoQxliff (Kilgray's proprietary Xliff format) and yes, it's an XML. So I've written simple XSL transformation which generated TMX file for me.

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2"
  exclude-result-prefixes="xliff">
    <xsl:output method="xml" indent="yes" encoding="UTF-8"/>
  <xsl:output doctype-system="tmx14.dtd" />

    <xsl:template match="/">
        <tmx version="1.4">
            <header>
                <prop type="targetlang">
                    <xsl:value-of select="//xliff:file/@target-language" />
                </prop>
                <prop type="name">
                    <xsl:value-of select="//xliff:file/@original" />
                </prop>
            </header>
            <body>
                <xsl:apply-templates select="//xliff:trans-unit" />
            </body>
        </tmx>
    </xsl:template>

    <xsl:template match="//xliff:trans-unit">
        <tu>
            <tuv>
                <xsl:attribute name="xml:lang">
                    <xsl:value-of select="//xliff:file/@source-language" />
                </xsl:attribute>
                <seg>
                    <xsl:value-of select="xliff:source" />
                </seg>
            </tuv>
            <tuv>
                <xsl:attribute name="xml:lang">
                    <xsl:value-of select="//xliff:file/@target-language" />
                </xsl:attribute>
                <seg>
                    <xsl:value-of select="xliff:target" />
                </seg>
            </tuv>
        </tu>
    </xsl:template>
</xsl:stylesheet>

OK, but I don't know this XSL stuff, it sound complicated. You may say, and you're right, but you don't need to know it. As engineer can make it easier for you. He would (should) know at least one programming language, not on development level, but enough to do some basic stuff. He'll then simply script it for you. (msxsl.exe is Command Line Transformation Utility courtesy of Microsoft)

If ($args.Length -lt 1)
{
    Write-Host "Specify the folder"
}
#Test if your.xsl file exists
ElseIf (Test-Path .\your.xsl)
{
    Get-ChildItem  $args[0] -Filter *.mqxliff | `
    Foreach-Object {
        $output = $_.Name -replace ".mqxliff", ".tmx"
        #XSL transformation
        msxsl $_.FullName .\your.xsl -o $output
    }
}
Else
{
    #your.xsl is required for transformation to work
    Write-Host "File your.xsl is missing"
}

All you have to do on your machine will be to run ".\script.ps1 c:\path_to_your_mqxliff_files" and script will do the rest. If you'll give guy some time (and tools) he can probably even make some simple GUI for you. The solution I've presented is really simple, and experienced developer would for sure come up with something more elegant, but it works and proves that engineer you'll hire doesn't need to be a star. He just needs to understand the problems he's facing.

I've written this post because many of companies I know stopped (or never started) to appreciate the value of engineer. Which is weird as in the outside world it's quite opposite, engineers are like rock stars, nobody pays much attention to project managers anymore (not saying they're not needed BTW.). Many CEOs of successful companies started as engineers, because there's no better way to understand how organization really works than on process level. And engineers are best at figuring out processes.

The purpose of this post is not to pimp up my resume. I have good job and if needed I can always get back to being manager. I'm just worried about industry where substandard replaced standard and only few seem to understand why it happened. I'm not saying that engineer is the solution to everything, you still need good translators and PMs. But without this nerdy guy who sits in the corner and makes you feel uncomfortable you'll not get far, trust me. So ask yourself a question, do I want to provide translations to all this small companies and world would never hear about me, or do I want to work with big ones who expect full solution from me? And hire an engineer.

I'm working on client side for a couple of years already and it really is quite obvious if LSP is hiring engineers. Amount of ridiculous questions is significantly lower:) And if you think it doesn't matter, well... Good luck with your business.

Oh, and if you're not localization company, but doing a lot of translations also hire an engineer. You won't be screwed over so often;)