Technical document translation encompasses much more than Word documents, PDFs, and even InDesign files.
For example, complex technical documentation requires specific software packages. Programs like Adobe FrameMaker and MadCap Flare allow companies to create and format large and sophisticated documents such as instruction manuals, help files, and learning user guides.
These programs offer special features that standard word processors do not, such as automatic sorting, indexing, conditional formatting, multimedia and image handling, coding, and interactive input. They also may fit within a publication workflow that involves multiple teams within a company.
In this article, we will take a look at some of the challenges inherent for each of these file types in technical document translation. We will also explore why it may be beneficial to use specialized software for technical document translation.
FrameMaker Files and Technical Document Translation
Adobe FrameMaker is used to design technical documents such as product manuals, e-books with embedded media, etc. It works especially well for documents with a complex structure—multiple chapters, appendices, diagrams, etc.
Compared to Microsoft Word and other word processing software, FrameMaker also gives greater control over style and formatting. Content is constructed using an XML-based format called DITA. Documents created with FrameMaker can be displayed in several formats, including print, desktop, mobile, etc.
Companies such as Yamaha use FrameMaker to create their product manuals in multiple languages. They value the ability to cross-reference within the document themselves, and the ability to have a single source for the twenty-plus languages they translate into.
The newest version of the software makes it easy to translate FrameMaker files. Users export their documents in .xliff format. XLIFF (XML Localization Interchange File Format) is an industry-standard format that can be imported into CAT tools such as Trados Studio or MemoQ.
Those documents can then be assigned to a specialized translator. Once translated, the XLIFF files are imported back into FrameMaker so that a final file can be created.
The use of translation memory is vital during FrameMaker file translation because these files often require updates on a regular basis. By leveraging a TM, companies are able to manage technical translation costs.
MadCap Files and Technical Document Translation
MadCap Flare is another software program used for designing complex technical documents. Similar to FrameMaker, it uses an XML-based architecture.
MadCap documentation is used for online support and instruction manuals. Another popular use is interactive eLearning courses.
Source files created in MadCap Flare can also be exported in XLIFF format, using an add-on to the software called Lingo. From there, the files follow a standard translation workflow before being imported back into Flare.
While you can take the actual PDF or HTML files produced by Flare and translate them using a CAT tool, the company does not recommend it.
Translating only the output files means that you lose search functionality, automatic alphabetical sorting, and other features that make MadCap documentation so useful.
Both MadCap Flare and Adobe FrameMaker are often used as part of a CMS, or content management system. By using a CMS, companies can store content in a central location to update, localize, or repurpose it.
Other File Types
There are other file types used for creating interactive technical documentation. Most of them are XML-based and have data content enclosed in tags. With such document types, the translatable content needs to be carefully extracted and separated from the code.
Translatable content is often stored in a file type known as .properties when localizing the user interface for Java-based software packages. Similarly, when we translate the user interface for apps that run on iOS, we are working with a file type known as a .strings file. Another most common type is a JavaScript-based file called JSON file.
JSON Files and Technical Document Translation
JSON is a stripped-down file format that is used to transmit data online. Because of their small size, JSON files load quickly, making them a popular choice for the web.
On the back end of virtually any webpage you use, JSON is being used to display dynamic content. Over the past 10 years, it has gradually replaced XML.
A sample JSON string looks like this:
“color”: “red”
“Red” is the translatable element in this string and what would appear on a webpage.
However, the word “red” has multiple possible translations in some languages. In Spanish, for example, it varies based on the gender and number of the noun. So “a red skirt” is una falda roja, but “two red shoes” are dos zapatos rojos.
For this reason, JSON files should be handled using a tool that allows translators to enter more than one translation for plurals.
Additionally, when translating JSON files, it is important to be careful that only the values are extracted for translation. If elements of the code are mistakenly translated, it can cause a website’s functionality to break.
.properties Files and Technical Document Translation
The programming language Java employs a file type called .properties. Each .properties file contains a pair of strings—a key and its value.
A string in a .properties file looks like this:
prop.setProperty(“db.password”, “password”);
In this example, the key is “db.password” and the associated value is “password”.
The files can also include comments that are marked with a hashtag.
A .properties file stores important information about an application’s configuration. It may also store the application’s text for localization.
To translate a .properties file, assigning a language code for each translated string is important. That shows the software with value to display for each language. Then the values themselves are translated without altering the name of the key.
Because of potential issues with encoding, the values from a .properties file should not be exported to Excel for translation.
Instead, it is recommended to use a specialized software program such as Transifex or POEditor, which can parse the strings and extract the translatable values.
How to Handle .strings Files for Technical Document Translation
A .strings file contains the text-based elements of the user interface for any app that runs on Apple’s operating system, iOS.
To translate a .strings file, a developer exports their content from within Xcode, Apple’s development tool. That creates XLIFF files that can be imported into any translation tool.
Similar to JSON files, .strings files are able to accommodate different plural forms of a word.
During the export process, developers must identify their project’s target language, then create a “strings dictionary.” Using this information, Xcode can identify how many plurals are possible for each noun and create additional strings accordingly.
This allows translating the XLIFF file generated during the export process in a standard CAT tool.
When You Need Specialized Software for Technical Document Translation
As shown, file types used for technical documentation, such as user manuals, can be converted to an XLIFF format and handled in a standard CAT tool.
However, specialized software is needed for file types used on the web. Transifex and POEditor are among the programs designed to handle specific technical file types.
Let’s take a closer look at one example: Transifex. It has been built with code-specific localization challenges in mind. In particular, it addresses challenges related to plurals in non-English languages.
In English, the plural of the word car is cars, whether you have 2 cars or 50. But in case-based languages such as Russian and Polish, the way the plural is written varies based on the specific number.
Transifex supports plurals in a variety of formats, including JSON and XLIFF. For a language with multiple plural forms, a translator cannot save their work until they have provided a translation for each form.
Even with XLIFF files, it displays developer notes for translators to view, allowing for direct communication between the two teams.
Programs such as these also make it easy to select content for translation—and avoid accidentally translating snippets of code.
A Technical Document Translation Workflow That Suits Your Specific Needs
At Art One, we have learned from years of experience that no two technical document translation projects are identical.
It is not enough to just look at an output file; instead, we speak with each of our clients to understand their workflows and the software they use to create their documentation.
Then we create a customized solution based on the file types involved, the language pairs being used, and any other key information that is important to the success of the project. Not only do we select linguists who are subject matter experts, but our project management, localization engineering, and DTP teams also carefully choose the tools we will use.
Once our three-stage technical document translation process is complete, we have a robust quality assurance phase. Whether we have translated the user interface for a software program or the contents of a manual for a washing machine, we want the final product to maintain the look and feel of the original.
Looking to start a technical document translation process? Contact Art One to learn how we can make it as easy as possible for you.
Comments are closed.
