CIDM

December 2022


Outsourcing: Working with another company’s content

Headshot of woman with glasses and brown hair

Jennifer O Neill, Carrier 

Outsourcing is big business. Companies are increasingly hiring third-party companies to provide specific goods or services instead of producing them themselves in-house. The most common reasons are to save money and time. It lets companies contract out, say, software development when they don’t have the resources in-house to do it themselves. It also lets them access a larger number of products to resell under their own brand than they could develop and build in-house themselves. They can simply buy products off-the-shelf or get them customized to their own specifications to meet their market’s specific needs.

Outsourcing in the manufacturing sector

Many companies go to third-party company (the supplier) to either have them build a custom-made product for them (software or hardware), or to get the supplier to customize and rebrand some of the supplier’s own products so that they better meet their market needs.

You can also buy products off-the-shelf from a supplier to simply rebrand and then resell. Particularly if the product is low cost and there’s no need to translate content, smaller companies may not bother rewriting the user manuals irrespective of the quality and simply rebrand and use the existing content as is.

However, when your company outsources a product to another company, you’re also buying that product’s content and its quality standard. The content, for example, can be the software user interface and user manuals.

This article discusses how to ensure that the content of an outsourced product meets your company’s expectations and standards.

The challenges

I’ve been over 20 years in the manufacturing sector, working with the content of software and hardware products developed and built by suppliers. These companies have been located worldwide but mainly in Asia. The most frequently encountered challenges can be divided into four groups:

  • Content quality
  • Terminology control
  • Global unreadiness and localization
  • Diverse work practice

Content quality

As technical communicators, we’re used to writing and managing content for products developed in-house. It meets your company’s publication standards before it gets released to the customer. However, if your company outsources products globally, then it is likely that the supplier you are buying from does not have English as its mother-tongue. This brings us to one of the most noticeable downsides of content associated with outsourced products: poor English.

“Any alteration about the content of this manual will not be informed.”

“Please according the following specific steps to install.”

English as a second language

English is the language of business. For many companies wanting to sell internationally, they need to provide their product content in English to reach a wider market. Unfortunately, many don’t have the luxury of using mother-tongue or native-level English writers.  The result can be English that is incorrect, inconsistent, verbose, and have unclear terminology. Often the manuals aren’t written by trained writers so the structure of the document may make using the information difficult. There may be missing information. You should also never assume that all the regulatory and legal information that may be needed for your market is included in the supplier’s user documentation.

A further complication is that the English content you receive may not be the original source language. I have received English software strings from companies where it was obvious that the source languages were Chinese and French which had been translated into English using free online translation tools such as Google Translate. Indeed, it’s surprising how many companies use tools such as Google Translate to translate their software strings into English and other languages. In the world of outsourcing, time and cost matter.

The contractual agreement drawn up between the buyer company and the supplier will state who is responsible for doing the user documentation and, if required, localization.

If your supplier produces content that is not written by mother-tongue or native-level English writers, the best way to ensure that the user documentation meets your company’s quality standards is to write them yourself in-house. Check and edit the software strings. If the English of the supplier is not a problem, and your management has agreed that they will write the content, you should work closely with them to ensure content meets your company’s standards.

It’s important that customers cannot tell the difference between the content of products developed in-house and that of outsourced products.

One of many customers

When working with suppliers you are probably one of many customers to them. Their flexibility in meeting your requests may depend on how commercially important your company is to them.

It is common practice for suppliers to hand over their documentation source files for customers to rebrand and rewrite (this will be specified in the contractual agreement). Many suppliers, particularly in Asia, do not have large (or possibly any) technical publication departments and may not have the budget to go beyond Microsoft Office. They want to keep their documentation processes simple and their user documentation generic to suit the needs of all their customers.

Software challenges

Although you can rewrite the user documentation, it might be more difficult to modify the English in the software strings. If you’ve commissioned a company to develop software specifically for your company, you should be able to easily edit their English strings. However, if your company is buying software off-the-shelf, you may not be able to modify the English in the strings as the supplier wants the same strings to be used across all its customers for that product (“one size fits all”). Check what the contractual agreement says about modifying the software and discuss with the supplier. You may be able to correct English mistakes but not modify the terminology or rewrite strings.

Terminology control

It can be challenging to rework content that’s written in English as a second language. While rewriting the English written by Chinese engineers and writers, I’ve learnt a lot about Chinese grammar. Although grammar and sentence structure can be challenging to decipher, a big challenge is terminology.

Terminology matters

If you are not already managing your terminology, when you start using content from other companies you could be in for a shock when you discover that they may use different terminology from your company.

You can’t easily take decisions on a supplier’s terminology unless you know your own company’s approved terms. It is particularly important to manage terminology in software as it often impacts the other content associated with the product.

Working with unapproved terms

If you have outsourced software development to another company, you should give them a list of your approved terminology for that product to ensure that the software stays consistent with your company’s terminology. Work with Product Management on which terms to include. And check the English strings produced by the company.

If you buy many products from a supplier and rewrite/edit their content, include the unapproved terms used by them in your term base. This will help anyone in-house working on the content from this supplier to identify problematic terms and determine the approved term to use instead.

My group’s English term base has 2000 approved and defined terms, around 200 which also list the unapproved terms used by different suppliers.

Table 1: Examples of approved and unapproved terms

Approved term Unapproved term used by suppliers
display time appearance time
event happening time
operating temperature working temperature
rule handling
schedule facility time
unattended object object left
PTZ dome speed dome

 

As a note, don’t manage your terminology in a style guide. The terms need to be accessible to everyone in your company in all languages, regularly maintained, preferably with context information included, and shareable with your localization providers.

Terminology is part of branding

Terminology is part of a product’s branding. Branding is more than just the company and product logos and names. It also encompasses editorial standards, templates, visuals, and terminology. Product management often want terms used in a product’s content to help differentiate their products from competitors. In my sector, for example, some companies use the term “PTZ dome camera” while others use “Speed dome camera.” The two terms mean the same thing, both are correct. Your term base should also include such terms in your unapproved list to ensure that for products originating from another company, the terms used align with your company’s approved terms.

Global unreadiness and localization

A surprising element when working with suppliers that sell globally to other businesses is how often they give little thought to the content of their products intended for an international multilingual market. Examples are poor English, inaccurate/inconsistent terminology, missing information, inadequate templates, difficult to obtain source graphics that contain text, not all software strings translated, little thought given to the impact of translation on the user interface, lack of transparency on how they have done their translations.

Passing the buck on global

The contracting company is usually responsible for localizing the manuals. Many suppliers don’t translate their manuals for B2B customers. If your company is localizing the manuals written by a supplier, you need to check the translation-readiness of the content (language and layout). Don’t assume that when you outsource documentation to another company that they know how to write for localization. Discuss with them what you require, provide them with the relevant information (such as templates, style guides and terminology) and check their work before release. Fixing issues at the localization stage can seriously delay and increase the cost of a translation project. Writing the user documentation in-house not only helps ensure that the content meets your company’s documentation standards, but you have control over the translation quality and cost.

Depending on the contractual agreement, your company may be responsible for localizing the product software. In my experience, software localization poses the most problems. Problems I’ve encountered have been the supplier including strings that are not relevant to your product, inconsistent/incorrect terminology, poor English, poor string management by the supplier (such as they lose all the edited strings and reuse the older unedited strings. When a product may have 1000s of strings, this is painful). When outsourcing software, always clarify at the start of the project how new/updated strings will be identified for editing/translation by your team, if there are restrictions in the number of permitted characters for translated strings, and in what format the strings will be delivered to you for editing and translation.

You are unlikely to receive the software source files for translation. The software strings will normally be delivered by the supplier for translation in an Excel, *.ini or XML format, for example. You need to ensure that your translation agency can work with the files.

Suppliers may sometimes be reticent to admit how they translate their software. Have they used a translation agency, in-house staff, or a free online translation tool such as Google Translate? You may not get a straight answer.

Keeping your translation memories clean

Translating third-party content will impact your translation memories (TMs). You may need to set up different TMs for each supplier. However, if your company is just buying a couple of off-the-shelf products that don’t have a large volume of text to translate, then it may not be worthwhile to set up a separate TM.

Software is usually translated by the supplier when it is intended for use by multiple customers. The supplier may not let you edit such generic translated strings to comply with your company’s approved terminology. You may then have to decide if these products get their own TMs so as not to contaminate your TMs.

Diverse work practices

Working with third-party companies exposes you to the diverse work practices used by other companies. Language, cultural and time differences can also cause communication problems.

We do it our way

Companies develop standardized work processes so that everyone in-house works in a way that is efficient, predictable, and understood by all on the team. Everyone “sings from the same hymn sheet.” However, if you’re working with several different companies, you can quickly find yourself working with many different “hymn sheets”, which can hinder how your company is used to working.

Develop a good working relationship with your supplier and understand how they work. Language barriers may mean that you have only one or two contact people in the supplier company and can’t talk directly to those who are doing the actual work, such as the developers. Answers to questions may take several days. It’s important to be flexible and patient but persistent while all the time staying focused on your company’s quality standards and deadlines.

Document the agreed shared work practice with your supplier so it is clear to all parties what is expected by whom and how it is to be done. This is particularly important for problematic areas, which is my work is often software localization. This document needs to be kept updated. Teams change over time and the new members need to quickly learn how the team works together.

Summary

When outsourcing product development and manufacturing to another company, here are some guidelines to follow to help ensure that the content associated with the product meets your company’s quality standards:

  • Ensure that the contractual agreement says which party is responsible for providing the user documentation. If the product includes software, the contract should ideally also say whether the software strings can be edited.
  • If the supplier doesn’t have mother tongue or native-level English, the best way to ensure the quality of the manuals is to write them in-house.
  • If the supplier is responsible for writing the manuals and your company is doing the localization, check that they are localization-ready before they are released to you.
  • Manage your terminology across all languages including English (source language). Tell your suppliers your approved terms to be used in the product content.
  • If the supplier doesn’t have mother tongue or native-level English, ensure that the English software is approved by your company before release.
  • Include the unapproved/incorrect terms that originate from suppliers in your term base along with the approved terms that should be used.
  • When working with international teams across companies, be flexible and patient but stay focused on your quality standards and deadlines.
  • Document shared work practices, particularly for areas that cause problems.
  • When outsourcing software development, clarify at the start of the project how new/updated strings will be identified, any restrictions related to the strings, and the format in which they will be delivered for editing/translation.