We have touched upon the direct link between the quality of source materials and the quality of translation in our previous article. This theme also extends to the technical realm – poorly formatted, uneditable or poorly scanned source documents will definitely not improve the quality of the localized materials.

The main reason for this is that, regardless of whether we use an AI-powered machine translation engine and post-editing or traditional professional human translation, all the major phases of localization process are performed in a CAT (Computer-Assisted Translation) software that can only be used with editable files.

CAT infrastructure is what enables boosted productivity, cuts costs and shortens the turnaround time, so it is easy to see why the properties of the source files are one of the essential elements of the localization process.

In cases when source files cannot be easily imported into a CAT software, there are ways to process these files to enable smooth execution of the localization project, such as:

• OCR or Optical Character Recognition

In certain cases, the materials for localization exist only in the form of scanned documents, or they include images or scanned elements such as seals, tables, or even written text. To make these files editable, technical localization teams perform OCR processing to generate a searchable and editable textual file that will be used in the further phases of the process.

• Alignment

In cases when there are (editable or uneditable) translated versions of documents that were not generated in a CAT tool, it is possible to perform the OCR and subsequently the alignment process to develop translation memories that will enable faster, cheaper and leaner localization with improved lexical consistency.

• Development of Terminology Bases

It is always recommended to extract specific terms and phrases – from taglines to any project-related terms that require special attention – before the localization process begins, and to develop terminology bases that will contain client-approved translations of these terms and phrases. This approach will save time and resources and ensure consistency and quality of the localized materials.

Fixing the Quality Issues in the Target

Quality Assurance (QA) process is performed on translated and reviewed files to check and resolve any errors that may have slipped through. The QA process is also computer-assisted and can be performed within the CAT tool or with independent QA applications.

What is usually checked are issues that involve spelling, formatting, tags, numbers and consistency. Depending on the project requirements, there are various types and levels of quality assurance, and dedicated QA programs are developed for each project.

It should be noted that the QA process is performed on purely textual files before they are sent to further processing, depending on the file format. After this stage, further quality control steps may include:

• DTP or Desktop Publishing + Proofreading

Even the best laid translations may go awry once the translated text is imported into a page layout software. Different languages (and different scripts) have different lengths, there may be issues with text breaks, fonts, layouts and everything in between.

This is why DTP should be performed with proofreading that will enable the linguist team to check their translation in context and address any issues before the localized materials are published.

• Software testing

In cases when the subject of localization is software, testing of localized apps (or, alternatively, screenshots) is performed for the same reasons as proofreading – to enable the linguists and QA teams to check their work in context and address any issues.

Under One Roof

While each of these processes can be performed by different teams and by various organizations, the record shows that centralizing the entire localization process and the supporting processes provides higher quality and faster turnaround times – simply because the linguist and technical teams within the same organization who work in accordance with harmonized rules and procedures are essentially all working on the same task with the same goal.

There is little room for “not my job” mentality, misunderstandings of technical and language aspects of the source material and similar weak spots that may lead to errors, delayed product launches or suboptimal localization.

Lest we forget, we localize content to localize the experience, and one of the fastest and safest ways to do it is by bringing various talents whose services are required for localization under the same roof. This enables linguists to know how their translations will be used and they will have an opportunity to adapt their work accordingly and to check it in context, while the tech people will be aware of the importance of linguistic subtleties in their line of work, and the result can only be a high quality localization.

The post Walking the Technical Side of Localization: Orchestrating QA, OCR and DTP to Really Work for You appeared first on Ciklopea.

Editable file is simply any electronic file that can be used for office automation and computer-assisted processing, i.e. any file that can be edited, changed or updated (at least) in the environment of its native application.

Files used for translation/localization are generally not originally developed in CAT (computer-assisted translation) tools, but one of the things that makes these tools so awesome is its built-in support for a wide range of standard editable documents such as: HTML, XML, TXT, SRT, a wide range of documents generated in Microsoft Office suites (Excel, Word, PowerPoint, Visio, Project etc.), files generated in certain Adobe applications such as FrameMaker, InDesign, InCopy and many more.

These types of documents can be easily imported and manipulated in the standard CAT tools and the translated/localized files can be exported in their native formats, with little to no additional editing if the additional DTP services were not requested.

For example, a PowerPoint presentation can be imported, edited, translated and proofread in a CAT tool, exported back to PowerPoint and the only additional required changes to the layout of the translated document will usually be adaptation of font sizes/placeholders to meet the length characteristics of the target language.

Why PDF in not (really) an editable file?

PDF (Portable Document Format) was developed by Adobe in 1993 as a presentation format that would present the document in its entirety (i.e. including layout, font, images and interactive elements) across different software and hardware platforms.

Over the years (or decades, to be more precise), the format has evolved to become more complex and nowadays includes advanced security and interactive features, remaining indispensable in everyday office operations.

However, its main purpose remains cross-platform presentation rather than editing – it can be used as an output format in a variety of applications, but due to its complexity and various standards and features, it can usually be editable only in its native application.

For example, a graphic file generated in Adobe Illustrator and exported as a PDF file can be smoothly edited and reedited in Adobe Illustrator – provided that preservation of editing capabilities was selected before the output file was generated.

In most cases, such PDF document will be editable in Adobe Illustrator only and practically useless in the context of CAT processing. Even if CAT software could extract the text, there will most certainly be issues with layout and the translated PDF would be practically impossible to fix.

Can we translate directly in a PDF file?

We might. But that would be a time-consuming process and the quality of the output file could not be guaranteed, the reason being that such an operation would in most cases be the work of a single linguist and the probability of human mistakes would be higher, i.e. it would be impossible to apply a full-scale localization process with guaranteed and predictable results.

If we add the unavoidable design, layout and font issues, it is easy to see why the technical limitations of this approach would spell an expensive, time-consuming and difficult project with unpredictable results. And nobody wants that.

These are the main reasons why your translation vendor asks you for editable files – to make you wait less and spend less on a translation project.

Learn More about translation technology and how it can help you optimize costs in our featured article How to Cut Localization Costs with Translation Technology

The post What Is an Editable File (And Why PDF Isn’t Really One) appeared first on Ciklopea.

Example No. 1: A simple case

Project outline:

Three Word documents previously translated to one language, totaling 6000 unweighted words. Two new documents totaling around 2500 words that feature certain elements of the existing files and need to follow the existing style and terminology.

Project execution:

Since the translated documents were properly formatted and there were no layout issues, the alignment process was completed almost instantly. The software was able to segmentize the source files and we matched the translated segments, with some minor tweaking of segmentation. We then built a translation memory from those matched segments and added the new files to the project.

The result:

Thanks to the created translation assets, the final wordcount of the new content was around 1500 and our linguists were able to produce translation in accordance with the previously established style and terminology. The assets were preserved for use on future projects.

Translation alignment in action.

Example No.2: An extreme case of multilingual alignment

Project outline:

In one of our projects we had to develop translation assets in four language pairs, totaling roughly 30k words per language. The source materials were expanded with new content totaling about 20k words unweighted and the language assets had to be developed both to retain the existing style and terminology solution and to help the client switch to a new CAT platform.

Project execution:

Unfortunately, there was no workaround for ploughing through dozens of files, but once we organized the materials we could proceed to the alignment phase. Since these files were localized and some parts were even transcreated to match the target cultures, which also included changes in layout and differences in content, we knew that alignment was not going to be fully automated.

This is why native linguists in these languages performed the translation alignment and communicated with the client and the content producer during this phase. While this slowed the process a bit, it ultimately yielded the best results possible.

We then exported the created translation memory in the cross-platform TMX format that allowed use in different CAT tools and the alignment phase was finished.

The result:

With the TM applied, the weighted volume of new content was around 7k words. Our linguists localized the new materials in accordance with the existing conventions in the new CAT platform and the translation assets were saved for future use.

Wrap up

In both cases, translation alignment enabled us to reduce the volume of the new content for translation and localization and ensure stylistic and lexical consistency with the previously translated materials. It also provided an additional, real-time quality control and helped our linguists produce a better translation in less time.

Translation alignment is not an everyday operation, but it is good to know that when it is called to deliver the goods, this is exactly what it does.

The post Files, Files Everywhere: The Subtle Power of Translation Alignment appeared first on Ciklopea.