Provide a list of terms that shouldn’t be translated

It might seem odd to prepare for translation by creating a list of things not to translate. But, this list can be important not only for legal reasons but also to ensure that your translated content uses terms relevant to your users. The main items to consider are product names, words or phrases that don’t have a translated equivalent, and terms that your users prefer to remain in English.

Your legal and marketing teams should be able to advise you on which product names can or should be translated to maintain your brand identity. If you have in-country technical sales members or partners, you can ask them for their insight into any technical or industry-specific terms that should remain in English.

Keep in mind that the list of terms might not be the same across all languages. Don’t assume that what is best for one language also applies to another.

Provide a list of previously translated terms that are important to you

Your translation memory, consisting of all previously translated terms, helps ensure that new translations match your existing translations. But, you might also want to keep a list of important translated terms outside of translation memory. This list gives the translators a convenient reference if they come across any inconsistencies. For example, if you have a specific way to translate a product offering, calling it out helps ensure that it’s the first option that pops into a translator’s mind.

You might also want to rely again on your in-country employees or partners to establish preferred translations for technical or industry-specific terms. Using these preferred terms avoids introducing less-desirable variations into your content.

Provide context for strings and terms

Translators are language experts, but they aren’t expert mind-readers. While the meaning of a string might be obvious to your team, you need to consider those who aren’t immersed in the product or those who don’t see the string in context.

Generally, individual sentences in documentation are considered in the context of an entire paragraph, so translators see the order in which they appear. The surrounding text becomes the context. Translators can also see whether the text is a title, if it’s in a table, or whether it’s part of a larger paragraph. These clues provide enough context so providing anything additional is usually only necessary if you’re documenting new technology or features. Sending a quick summary of the new feature and how it relates to the existing content allows translators to use consistent terminology for all related features. It can also help reduce questions that might otherwise delay the translations.

UI strings, on the other hand, tend to be incomplete sentences or short terms. They are usually arranged in the order they appear in the UI database. You might have one or two strings that come from one area of the product, but those will be preceded by strings from a completely different area. Translators can’t use the surrounding text to help them identify how the word is being used – and, therefore, what translation to apply. If a single word has multiple meanings in English, translators don’t have the necessary information to determine which translation to apply.

You can provide that context by including development comments in your strings. The comments are exported with the strings, giving translators access to this crucial contextual information. Examples of useful notes include a short sentence about what the string is referring to, a definition in the case of ambiguous terms, or information about where the string is being used. Knowing whether the string is a title, field label, or button can help ensure that your translated UI has a professional and polished look.

A little goes a long way

Providing translation instructions for important terms, along with basic context notes for strings, can greatly improve the quality of your translations and keep your projects on track. If you haven’t considered what terms should remain in English or whether there are any preferred translations for your audience, you might be missing out on branding opportunities or risking using an inappropriate translated term. And, if you don’t provide sufficient context for your UI strings, your translation project might be delayed while you provide answers to any questions from your translators. Or, you could end up with a term that is incorrect for the context where you use it.

Compiling these lists might seem daunting, but it can be done in parallel with your coding cycle so you don’t have a bottleneck at the end of the project. If you’re introducing a new product, prepare your legal counsel in advance so they can be ready to discuss product name translations. If you’re adding support for a new language, review your existing terms list and start asking if the same rules apply for the new language. And, as your developers add strings into your string database, have them add notes about how the string is used while it’s still fresh in their minds.

Whether you need help getting ready for translation, or want someone to manage the process from start to finish, Spark can help you meet your translation goals.

As smartphones got smaller, the boxes got smaller too. As they became more ingrained into our daily routines, they also came with more accessories to help us out. All of this left less and less room for user documentation. Often, we had to think outside of the box to figure out how to fit everything inside the box.

The most obvious way to reduce the size of printed documentation is to reduce the amount of information in it. For both environmental and space reasons, we moved much of the smartphone documentation online. But, there were some things that we couldn’t move, such as information on where the power button was, or what gestures users needed to know to navigate the user interface and set up the phone – not to mention how to find all the information that we had removed from the printed documentation!

But, what do you do if you’ve removed all the information that you think you can and you’re still struggling to fit your documentation into a physical package? Here are a few other ways to shrink your printed documentation without impacting its usability:

• Use thinner paper. When box space is measured to tenths of a millimetre, shrinking the thickness of each page can make a difference when you add up the pages. Keep in mind that the paper still needs to be thick enough so there’s no ink bleed from one side of the paper to the other. The documentation isn’t helpful if users can’t read it.
• Reduce the font size. There is a limit to how low you can go – in limbo and in font size. But, font size is often something that you can play with. Keep your audience in mind, as products aimed at younger audiences can generally squeak by with smaller fonts than those aimed at an aging population. If you’re translating the documentation, you might not be able to reduce the font size for some languages without impacting the readability of the characters.
• Use narrower margins. If you have short paragraphs or steps, you might be able to get away with slightly smaller side margins. But, there is a limit to how tightly you can pack in the text. People need white space around the text – both between the lines and at the sides – to comfortably read it. With short paragraphs, however, the internal white space might balance out the decreased space in the margins.
• Replace text with graphics. Unlike the old adage says, you can’t often replace 1000 words with just one picture. But, you can condense short bits of information into one graphic to save space. In most cases, callouts or tables are easier for users to scan and find the information they need, rather than long paragraphs of text.
• Look at the whole package. This is where you start to think outside of the box – and the documentation. Can some information go somewhere else? For example, is there empty space on the packaging where you can put support information? Is information duplicated? If it’s on the packaging and in the documentation, can you remove it from one? Can you replace paper with another format? In our case, the smartphones shipped with blank clings on the screen and the back of the device. By moving some information out of the documentation and onto those clings, we could make better use of the space. And, better yet, the information was more visible to users.
• Take another look at the information. It never hurts to take a second (or third) pass at your content to make sure that it really is as streamlined as it can be. A good editor can help you with that task. It’s easy to get into the habit of carrying forward information because it’s always been there, without considering whether it is still necessary. A fresh set of eyes can help assess the need for content. For example, new features or emerging technology might necessitate a more detailed explanation at first. But, as it becomes mainstream, you can likely reduce that additional contextual information. Or you might be able to remove it entirely.
• The Three Cs: When you know what content needs to be included, it’s time to take a review how the content is written. Clarity, consistency, and conciseness are rules that every technical writer needs to live by. When you are working with tight spaces, they are even more important. Are there ways to tighten up the text? Have you applied plain language principles? Can you use fewer words to express the same thought?

As you can see, there are many ways to reduce the size of your documentation without reducing its usability. You might even find that making a few changes to reduce space improves the overall readability of your documentation.

If you need help fitting information into a printed format, or figuring out what to keep in the box and what to do with the rest, give Spark a call. We can help you find a solution to your space problems.

We clarify and clean up

We’re writers. It’s our thing, and we’re pretty good at it (if we do say so ourselves.) Writing isn’t just putting words to paper. It’s finding the right words to use and creating a flow that’s easy to follow. People less familiar with writing principles tend to put as much information as they can into a document to try to help users. But what seems helpful to add can ultimately hold users back.

We’re skilled at taking technical content and making it easier to read. Have a manual that feels more like a medical textbook? We can streamline it to a more manageable size. We cut through the jargon and unintentional fluff to focus on the task at hand. Your users get the answers that they need as quickly as possible.

We look at the whole picture

We call ourselves content developers for a reason. We don’t look just at the specific changes that need to be made. We consider how those changes affect your company’s broader content set. For example, can changes help offset your customer support needs? How do they align with your marketing materials? If your employees focus on one area of your business, they might not realize that making changes can impact other areas. We can make sure that the impact is positive.

We also think about translation, legal requirements, and print needs. So, when those questions come up, we already have answers for you.

We bring an outside perspective

An outside perspective means that we step back and look at the content with fresh eyes. For example, the feature that took the longest to design or code might be the most important to your project team, but it isn’t always the most important to your users. Your employees might not even realize that they are attached to certain features after their trials and tribulations with them throughout a project. We have the experience to look at all of the content objectively and align it to what your users need.

Our unique perspective also means that we’re away from the technical details – just like your customers. We ask questions about what we don’t understand, which are probably the same things that your users don’t understand. We have a good perspective on the kind of information and level of detail that a user is looking for.

We also bring with us our years of experience on other content. You benefit from the times we reworked content to fit a smaller box size or developed online help for mobile applications. Our content experience can work for you.

We make your business our business

The obvious decision of using an engineer, developer, or marketing team member to write content isn’t so obvious when you look at what a contractor can bring. Your employee might know your business already, but we make it our goal to learn your business quickly. We know how to write about products, how to get to the heart of your message, how to make sure that the message compliments and aligns with your existing content, and how to make sure that it delivers what your customers need.

Make Spark Content your content development team. With our expertise, we look at the whole picture to polish your content. At Spark, we’ve got content covered.