Tagged: multilingual

An STC Europe Summit wrap-up

Whew! The 2013 Summit is over, and many will require long naps to catch up on their sleep!

News about the Summit

Speaking of catching up, go to the Summit site on Lanyrd where all the sessions are listed. Each session is updated, or being updated, with slides and related blog posts.

Two people were very diligent at blogging at the Summit. Sarah Maddox probably wins the prize for live blogging. Sarah’s last post from the Summit collects all her Summit posts in one list. Grab a cup of coffee or tea and enjoy a good read. While you are in reading mode, continue over to Kai Weber’s Summit posts for more great blog posts about the Summit.

Searching for sessions that interest you is easiest on Lanyrd, but you can also go straight to SlideShare and search for “stc13″. All presenters were encouraged to post their slides there with the tag stc13.

Eventifier has a collection of photos, tweets, and more from the Summit.

Summit@aClick

If Lanyrd and Slideshare made you long to revisit some sessions, don’t worry. You can! All attendees will receive access to Summit@aClick in 6-8 weeks. If you didn’t attendee, you can already preorder Summit@aClick, which is all the recorded sessions in one package.

Handouts

We had some English-language copies of “How to Write Clearly” on our table at the Summit’s Communities Reception. You can download a free copy of “How to Write Clearly” in the EU bookstore in 23 languages!

You can download the SIG’s brochure (910 KB) for 2013 as a PDF. We had this as a handout at the Summit, too.

And the winner is…

We gave away two subscriptions to the digital Multilingual Magazine during the conference. The winners were Helen O’Shea and Britta Voigt. They have been notified separately.

The magazine is a great resource if you work with internationalisation, localisation, or globalisation issues. Visit their magazine website where you will also find a blog, a free newsletter, the latest news from the industry, and much more. You can also follow them on Twitter at @multilingualmag.

Watercooler Webinar: Collecting user feedback

by Jen O Neill

In this month’s Watercooler Webinar held by the Europe SIG, we discussed the various ways we can collect feedback from the global users of the products we document. Many of us write for audiences located across countries and languages. How do we find out if our documentation meets their needs when due to geography, language or cost factors, it often isn’t practical for us to meet them directly?

In our chat, we discussed the different ways to collect information from users. It was interesting to hear real examples of how people have done it.

Contacting technical support

An obvious source of customer information is speaking with technical support and product management. They can be a mine of information about customers and the problems they’re reporting. Some companies, such as HP, keep knowledge databases of calls received by technical support and the solutions provided. Such databases can then be searched for problems encountered by users. Even smaller companies will have a log of issues brought up by customers.

One tool that we all seemed to have used at one stage in our quest for user feedback was forms. A well designed form is crucial and care is needed to prepare the questions so that you collect useful and correct information. A book recommendation was “Forms that Work: Designing Web Forms for Usability” by Caroline Jarrett and Gerry Gaffney.

Two useful points brought up were that it’s a good idea to offer a prize or small gift to those who take part in surveys as a way of saying thanks. Often this can simply be to send the results of the survey to respondents. Another point was if you are collecting feedback via email, you should use an email alias address instead that of a person.

One source of documentation feedback that writers may not consider is that from translators. We had a translator in the discussion who described that translators often pick up inconsistencies and errors in texts and terminology and will seek to ask writers for clarification.

Interestingly, none of us worked for companies that used social media such as Facebook or Twitter to collect information from customers.

Customer surveys

An example of a customer survey that we discussed was one my company did a few years ago. The European technical writers had to do projects as part of their Six Sigma Green Belt certification to improve documentation quality. We used a multilingual Web survey to collect feedback from customers about our documentation.

We drew up a 10-question online questionnaire covering satisfaction, usefulness of the manuals and problems encountered across three product groups. Questions had five-point scales for answering with one open-ended question. We did the questionnaire in seven languages including English as most of our customers don’t work in English. As we each managed the localisation of our own projects, we knew the technical support people in the sales offices across Europe. They were the in-country reviewers for translations. So we asked them to help us translate the questionnaire and any associated texts.

The seven language versions of the survey were located on the European HQ web site. We got the agreement from the country sales managers in seven countries to have information on their national web sites about the survey that linked to the HQ site with the multilingual questionnaires. Two of the country managers did a mailing to all their customers to encourage them to take part in the survey. The survey ran for a month and we got nearly 200 participants, most from the countries that did the mailings to customers (next time we will push hard to get all country offices to do mailings to customers about the survey). Respondents didn’t receive a prize or gift for taking part nor get a copy of the results. However, the sales offices did get to see the results.

We found that doing a multilingual survey took more effort than if it had just been one language; there were more steps to organise due to the need to get translations of the questionnaire, web page text and answers, as well as seeking the OK from the sales office managers. But we didn’t have any problems getting the support of our colleagues located in the sales offices located around Europe. They were also interested. However, analysing and writing up the data took time as it had to be done on top of the daily workload. We hadn’t allocated enough scheduled time to this task so it took longer than originally planned.

Meeting customers at trade/training meetings

Another participant, Karen Mardahl, described how she collected feedback from customers by attending a global meeting run by her company for their partners and distributors. This was the first time that such a meeting had been held in several years and attendees came from many countries. It was also the first time Karen got to meet readers of the documentation face to face. The company did a questionnaire to collect information from the attendees on many topics, and Karen got them to include one question dealing with documentation.

Based on the information collected during the meeting, the company now does a weekly newsletter to connect with their partners. A single topic is discussed in each newsletter, and feedback and questions on any product and service are very welcome. The newsletter is encouraging them to get in touch with the company with their issues.

The next Watercooler Webinar

It’s always interesting to meet with fellow professionals and compare notes, to catch up with what’s been happening at work and see how it applies to what we’re doing. This month’s Watercooler Webinar let us discuss the practicalities of collecting user feedback. The webinar is free to SIG members and you can phone in from almost anywhere in the world using the list of phone numbers provided. Come and join us in January for our next webinar! Watch our discussion list for details.

When the manual speaks in many tongues: The multilingual manual

by Jen O Neill

Buy many products in Europe and inside the box you’ll probably find a printed multilingual manual. The manual could contain over a dozen languages. They can often elicit a groan from readers as they can initially be overwhelmed by all the languages in front of them.

This type of document is widely used in Europe, particularly for lower-cost hardware products. Its advantage is that the product can be packaged without knowing the eventual country to which it will be shipped, simplifying shipping and reducing costs.

These manuals are usually printed as a large folded sheet or as a small booklet. Due to space demands, page and font sizes tend be on the small side. They are often thrown out after use. As a result the cost of production can be an important issue.

In spite of their widespread use, we don’t often hear much about how they’re produced. Unlike the larger monolingual user manuals we all work on, these manuals are often more exposed to the cold realities of cost and size restrictions. So when planning a multilingual manual you should consider the following points:

Purpose

Will it be the only printed manual shipped with the product or is it intended as a quick installation guide with the full user guide to be include, for example, on a CD?

This will help you decide the type and extent of information required in the multilingual manual.

Space

How much space is available in the box for the printed manual when packed with the product and any other accompanying accessories and documents (such as WEEE and/or Battery Directive information sheets and CDs)?

This will determine the size and thickness of the printed manual with all required languages included, which in turn will impact how information can be presented.

Graphics

Do you have access to high quality graphics?

Usually these manuals communicate information in a very visual manner to reduce the amount of text needed. So the graphics need to be well drawn, descriptive and clear. They will often be describing hardware. If you can’t draw the graphics yourself, you’ll need the services of someone who can. To facilitate translation, graphics should only include text that doesn’t need to be translated such as measurements.

One way to save space is to present all the graphics in the front pages of the manual and then refer to them in the text of each language that follow after the graphics. Not always best in terms of usability but a compromise that at least ensures the information is provide in all the required languages in a limited space.

This type of documentation can reveal some of the cultural issues involved with producing international documentation. Europeans are more familiar than Americans with working from pictures. Europe is not (yet) as litigious a market as America so there may not always be the same legal demands for information to be explained in text format rather than split between graphics and text.

Budget

Are there budget limitations for producing and printing this manual?

Know what the printing budget will be since this document type is often used for lower cost products. As a result you may not be able to print in colour or use higher quality paper. Multilingual manuals tend to be printed in large print runs (perhaps several thousand at a time) so mistakes can be expensive to correct if they produce a lot of scrap documents. Don’t start writing this manual without knowing your production and cost restrictions.
How many languages will be included in a multilingual manual?

If you need to ship many languages with the product, the languages could be included in a single manual or split between two or more manuals. Including only a few languages in a manual makes it less intimidating and easier to use. However, printing two or more multilingual manuals to be shipped with a product will increase production costs, for which the budget may not always be available. There can sometimes be pressure to keep the number of items on the bill of materials for a product to a minimum.

Use the internationally recognised ISO language or country codes to identify the languages in a multilingual manual. Language codes are preferable to country codes as many countries share the same language. For the same reason, don’t use national flags to identify languages.

Love or hate them multilingual manuals will not be disappearing anytime soon. There’s a business need for them. So it’s important that we understand what makes them tick. I’ve done dozens over the years and enjoy the challenge each presents.

And you?

What’s been your experience of writing them? As a reader, which ones did you particularly like or dislike?

Parlez-vous tech comm?

by Jennifer O Neill

We often hear about the advantages of being fluent in a second language such as when visiting a foreign country on holiday. It’s easier to eat, drink and be merry when you can speak with those around you. But what about the professional advantages?

I’ve been reading a few blogs and newspaper articles recently that discuss multilingualism.

They have made me think about our profession, technical communication, and how it connects with other languages and cultures. We now work in a global marketplace and increasingly are involved with planning, writing, and distributing documentation that cross linguistic and cultural borders. Although most of us work and write in English, does it help us professionally as technical writers to be fluent in other languages? Are employers interested in such a skill?

If you’re based in Europe having another language certainly gives you more freedom to move between countries for work, particularly if you hold an EU passport. Fluency helps us deal with the various bureaucracies that invariably arrive when living in a different country. We become more aware of the diversity of life and can take part in it. We can speak with colleagues in their language. I’m fluent in French so can communicate with my colleagues in France, Belgium and Switzerland in their language, which they appreciate. Communication becomes more shared.

English today is the global linga franca. As a result many English speakers unfortunately don’t see the point in learning another language. Are many of the professional advantages of having a second language only apparent when you are the foreigner rather than the language? My last two jobs both preferred candidates to have a second language as well as good English. Admittedly both were in French-speaking countries.

Yet I think having another language is useful professionally even if you’re not based in a foreign country. We know what it’s like to read technical documents in a second language. Although such fluency isn’t a requirement when writing for a global market, it can help us to be more aware of the consequences of writing clear, concise, and direct information that is easy to translate as well as understood by those reading in their second language.

The practicalities of localisation can become more “alive”. Simply reading documents in other languages can help us appreciate the impact of such issues as text expansion due to translation (particularly around graphics) and inconsistent terminology. In some of my company’s datasheets I discovered that we had six different ways of writing “operating temperature” in English, which translated into four different ways in French and three in Spanish. Ouch!

If you’re fluent in more than one language, what advantages has it brought you professionally in your work as a technical communicator?

Planning your in-country reviews

by Jennifer O Neill

I oversee the localisation of my company’s video and an important part of the localisation process is the in-country review. This is where the translated material is sent to an individual in the target country to do a linguistic review. The in-country review plays an important role in ensuring the quality of the translated documentation. So it’s important to carefully plan for this stage.

Who should do the reviews

A good reviewer is a

  • Company employee
  • Native speaker of the target language
  • Product SME
  • Stakeholder in the process of producing quality translated documentation

In my company, we usually send the translations for review to a technical support colleague in one of our many sales offices located across Europe. Sometimes the sales people also help. What they all have in common is that they know the products, are mother-tongue in the language being reviewed, and know the customer so want documentation that helps them. Quality matters to them. Well written and translated documentation helps reduce the number of calls they receive from customers.

Develop localisation guidelines

Before the localisation project starts, you should work with your localisation vendor to develop localisation guidelines. The guidelines, a localisation style guide, will help the translators know how you want the text translated. It can include such information as fonts to use for specific languages, how to handle text that is not translated, stylistic issues. As the in-country reviewers are often the final judges of the quality of the localised documentation get their input in these guidelines so that they and the localisation vendor agree on standards. This joint effort will help minimise the number of revisions later.

Although many reviewers have in-depth knowledge of the product, they may not know how to review a translated document. It’s therefore important that you provide them with a clear set of guidelines or instructions to ensure consistent and timely feedback from them. It can be a simple list of do’s and don’t on a single page. Some guideline examples are

  • Use approved terminology in your review (and use it consistently)
  • Don’t try to rewrite the document
  • Check that decimal and measurements notation is appropriate for your region or language
  • Try to ensure that the same person reviews each translation project for consistency
  • Mark your requested changes in the correct format (Track Changes for Word files or comments for PDF files)
  • Contact the person overseeing the translation project if you have any concerns about the document content or translation quality

Don’t forget multilingual glossaries

We work with our in-country reviewers to develop our multilingual glossaries as some of our terminology is industry specific and we want to ensure it is translated correctly. These multilingual glossaries have more terms and acronyms in them than the English-only glossary used by our technical writers.

The localisation vendor SDL recently conducted an online survey which found that 36% of respondents stored their English terminology in a style guide, 33% in spreadsheets, and that 24% had no terminology list. I suspect that those respondents without terminology lists were not localising their documentation. However, if you are serious about quality in any language you must have a glossary of terms and acronyms. If you don’t have one for use during localisation, and don’t have in-country reviewers to help you develop one, your localisation vendor will be able to help you do one. Translators need approved translated terminology.

The reviewer’s changes

The translated document can be sent to the reviewer in different formats. It depends on what you’ve agreed with your localisation vendor. The most common file formats used for reviews are Word and PDF. Whichever format is used, the reviewer needs to clearly understand how to mark their changes in the file and why it’s important that the translator can easily see what changes have been made. This information will be included in your reviewing guidelines to them.

Their changes are then manually implemented from the Word or PDF file into the translation database by the translator. If there are many changes, this can take time. And if there are many changes, you need to find out why from the reviewer in order to reduce rework in later projects. Was it a poor translation, stylistic differences between the reviewer and the translator, or a new reviewer who has different expectations from the previous reviewer? Were some of the changes due to errors in the content of the document? If so, you need to know how to handle content errors at this stage in the localisation process.

A common problem with in-country reviewing is the late review. In-country reviewers have daytime jobs too to do. Reviewing translations is just one item on their long task list. Sending them a 300-page translation of a new product’s documentation to review in a week is often unrealistic. Review schedules need to be realistic yet fit in with the product release deadlines. Get to know your reviewers so that you know when potential delays may occur such as when they’re on holiday, attending trade shows, giving customer trainings. You can then plan the review schedule accordingly, perhaps even calling on the assistance of another reviewer if necessary. All the while keep working on updating your multilingual glossaries and fine tuning the localisation style guide so that translation quality continually improves.

Increasingly localisation vendors are developing online review tools that allow the in-country reviewer to review the translated text via the Web, which means no firewall problems and their changes are implemented immediately into the translation memory, saving time and streamlining the process. The translator no longer has to spend time transferring the changes from a marked up PDF, for example, to the translation memory. The reviewer is still provided with an English PDF of the manual in order to see how the text appears in the document. However, such online tools aren’t free. For example, one large localisation vendor charges around 100 euros a month per reviewer for their Web-based online review tool.

Become a close team

By planning ahead for in-country reviews you can help ensure that the translated documentation you release in the international market meets the expectations and needs of your customers.