When we adopt or deploy a technology we aim to be the most advanced users of that technology outside of the people who created it. That means we can be sure that we are utilizing it to its full potential. As part of our engagement with the technology creators we enter into strategic relationships which engender collaboration at the highest levels. We particularly value developer to developer interaction where we can optimize integrations, alpha test new facilities and influence the design of new features.
We were the first Language Service Provider to sign a Premiere Partnership agreement with Idiom Inc. back in 2008, have been Gold Partners of Alchemy Software since their start-up days, and continually evaluate and integrate world-class technologies. Anyone who knows us will know that we do not believe in customer lock-in using complex, proprietary tools and processes. We keep customers wanting to work with us by finding the most appropriate, open, interoperable tools for the job and deliver compelling, value generating solutions.
Carrying on this tradition I am pleased to announce our latest partnership with Lingotek.
Lingotek, I really look forward to working closer with you guys over the coming months.
Even trying to decide how to title this post was not immediately obvious. In many situations what I am writing about is not even visible to the content consumers. The topic is what can be referred to as placeholders, inline markup, inline tags, format specifiers, placeables, replacement variables…
I’ve spent a lot of time with them recently. They’re a good idea with a solid Use Case. They generally follow internationalization guidelines by separating geographic region and culture affected information, typically provided by an operating system or platform, from textual content which is generally passed to translators for adaptation. They can also be used to represent some item of structure or unalterable content which you just want to protect from accidental modification during localization.
- “Dear %s, your calendar appointment for %s will start in %d minutes.” (resource file)
- “The all new [product-name] is amazing! [branded-tag-line-format text=”Ultra Super Gizmo Thingydoodle”] Get it now!” (proprietary content format)
- “<p>The Stranglers single <a title=”Golden Brown” href=”https://en.wikipedia.org/wiki/Golden_Brown””>Golden Brown</a> was amonst their best.</p>” (HTML)
- “<source>All I want is some text where a <bpt id=”1″><strong><bpt>word<ept id=”1″></strong></ept> is in bold.</source>” (XLIFF 1.2)
- “Select File->Edit->Search & Replace” (potential confusion)
They can be challenging because there are so many ways in which to represent them (sometimes depending upon the host content type), and they can be complex: the placeholder may itself contain content which should be translated by a human. They have to be considered during authoring, human and machine translation, file conversion and quality assurance.
Support for handling these within well-known applications and file formats is comprehensive and stable. However, outside of these you can be on your own and struggle without a good grasp of a document object model, and an appreciation of parsing and regular expressions.
One item of great news is that it looks like inline markup will be supported within the Change Tracking module of the up-coming XLIFF 2.1.
As always the devil can be in the detail.