The development and manufacturing of many of the hardware products I document have been outsourced to Chinese companies. They work closely with our in-house engineers and product managers to develop customised products for our global customers. We release dozens of such products a year. The technology of these products is changing so quickly that it would be difficult for us to develop so many products in-house ourselves. Competitors also outsource their development and manufacturing for these products. See our earlier blog post “Working with OEMs”.

The Chinese engineers write generic manuals, which they then send to us to customise for our versions of the products. Their manuals are written in Chinglish. English strongly influenced by Chinese. They can have strange terms, long-winded sentences, missing grammar, simplistic mixed up verb formats, curious word order.

I’m working with an English that’s been contaminated by a language I don’t know: Chinese.

The infamous web photos of China’s Chinglish signage are amusing to read. A 70-page manual of it can be challenging. And fascinating.

So I’ve been reading up on how Chinese is written. Knowing some basic Chinese grammar helps to untangle the Chinglish and makes it easier to rewrite it into English. I’ve become curious about Chinese.

General information about Chinese

Chinese doesn’t have an alphabet. Instead it uses characters, called hanzi. There are around 40,000 characters in the language and as a beginner you need to learn around 2,000 to 3,000 just to be able to read a newspaper, for example.

No articles or prepositions. No plural or singular either

Chinese nouns don’t have articles such as “the” or “a” so they can be often missing in Chinglish. Nor does Chinese have a plural form. It’s implied in the context. As a result there are often mistakes in number in the Chinglish:

Chinglish: Can’t Add More User!
English: You can’t add any more users.

What’s with all the commas?

When you look at a text written in Chinese you’ll notice that there are a lot of commas as shown in this image.

Unlike English, the comma splice is frequently used in Chinese. Clauses are linked by commas where in English we’d use separate sentences. This means that when Chinese is poorly translated, we can often have a long paragraph of just a single sentence. Chinglish can be full of commas:

Chinglish: The enable status of camera already changed, device will reboot automatically, please enter the remote configuration after reboot is complete.
English: The camera reboots automatically when its parameters are modified. When rebooting is complete, configure the remote parameters.

(You’ll also notice that there are no breaks between words in Chinese.)

Another example of Chinglish written as a single sentence:

Chinglish: The whole screen is divided into 22*18 panes, you can use “ ↑ “ “ ↓ “ “ → “ “ ← “ keys to move the yellow pane to your hope position and press “ EDIT “ key, the yellow pane will be turned into red, then you can use “ ↑ “ “ ↓ “ “ → “ “ ← “ keys to extend the red pane.

Often the first thing I’ll do when I receive a text from the engineers is to quickly look through it to see if there are a lot of commas. This gives me a rough idea of the state of the “English” and how much rework may be required.

Past, present or future? It depends on the context

Chinese has no verb tenses. The tense depends on its context. To indicate that something has happened in the future or past, for example, time context words such as “yesterday” or “next year” are often added to the sentence. And unlike English, the time words come before the verb in Chinese.

Verb errors are common in Chinglish:

Chinglish: This action trigger local audible on box.
English: This action will trigger the unit’s buzzer.

Chinglish: The log items are more than 200 pieces, please short query range!
English: There are more than 200 log items. Please specify a smaller query range.

Chinglish: ESC button represents “Cancel”.
English: Press ESC to Cancel.

How did “Rule” become “Handle”?

The Wikipedia web page on Chinglish cites several possible causes for texts being written in Chinglish such as errors in Chinese dictionaries, no native English speakers checking the text, and the use of translation software.

None of our Chinese engineers are fluent in English. Their English is often a literal translation of the Chinese. They’re clearly thinking in Chinese when writing English, which produces Chinglish. Although I’ve never asked, I assume that they use translation software when writing their text as they often use the wrong synonym of a term or simply use a term that apparently has no logic for the context.

Chinglish: Modem drop off.
English: The modem is disconnected.

Chinglish: The image sticks.
English: The image freezes.

Each Chinese character represents a word or concept and often serves multiple purposes. Their meaning depends on context. So translating each character individually can easily produce an inaccurate or confusing result in English.

This excellent article by Mark Liberman discusses literal translation and explains the process of how “Disposable coffee cup” on a sign became translated as “A time sex thing” using translation software.

The biggest problem I have understanding Chinglish is with such mistranslated terms. One example is “handle” being used instead of “rule” in the manuals (such as when you configure the rules for how a system should respond to an alarm situation). One example:

Chinglish: View Tampering Handle.
English: View tampering rules.

I couldn’t see the link between “rule” and “handle” until I read Mark’s article. I entered the Chinese term for “rule” (taken from a software string) into Google Translate and it proposed the English term, “Deal with”, and several synonyms (processing, handling, handle, process). No “Rule” but a probable explanation as to why “Handle” appears in the manuals.

So I’m now wondering if the Chinese translation software tool used by the engineers lists “Handle” at or near the top of the English term options provided, making it an easy selection. If you don’t really know the target language well, you tend to select the first word the translation tool proposes.

I’ve tried this test with other peculiar English terms in the manuals when I have the corresponding Chinese term. I now have a better understanding of why some strange English terms have probably been used. Google Translate and the other translation software tools available on the web are useful tools and are continually improving. But they aren’t infallible.

In the meantime, my interest in Chinese grows.

For more information on Chinese grammar, see Wikipedia’s entry on Chinese grammar, grammar information from chinesenotes.com and a learner FAQ from the Chinese Grammar Wiki.

And what’s my elevator speech?

I enable English, natively.

We all agreed that having shared and consistent documentation standards and procedures for all writers in a company are necessary goals but trying to achieve and maintain such a harmonised state was often an uphill and ever changing struggle. The ground often keeps moving.

Earthquakes that fracture global documentation standards

When reading the numerous articles and blogs about the tools available to facilitate standardising documentation content and processes – and the cost of some recommendations can run into many thousands of dollars/euros long term – I often find myself wondering, “What a stable environment these guys must work in. They apparently don’t get hit by earthquakes.”

The earthquake in question is mergers and acquisitions (M&As). All of us taking part in the discussion had experience the impact of M&As, sometimes several times, and the detrimental effect they can have on us developing and maintaining effective documentation standards across the company.

The impact often creates virtual writing teams dispersed over a wide geographic area, even several countries, and who’ve probably never worked together before. Unfortunately companies often make little effort to merge the cultures of the different virtual teams. With many travel budgets frozen these days, the virtual team members may never get to meet face to face so it can be difficult to forge strong relationships. Trust and mutual understanding can take a hit.

In the worst case, the technical publications department may even disappear following an M&A with writers now reporting locally to, say, different Engineering groups. Have upper management considered the impact on documentation standards and cost in such situations?

Outsourcing writing and R&D can also complicate the goal of achieving harmonised standards across a company.

As the STC annual conference approaches, I can’t help but notice that the impact of M&As on our work is rarely discussed even though many of us have probably been impacted by such earthquakes.
Strange omission.

Controlling the standards

One M&A issue we discussed was how the role of the editor can change as teams become more virtual and culturally dissimilar. Even if all the writers in a global company supposedly use the same style guide, templates and processes, there’s no guarantee that everyone will correctly use them. It’s too easy to ignore style guides. Scattered teams mean that it’s harder to enforce standards. It becomes easier to ignore the editor’s recommendations, particularly if there’s no feeling of being part of the same team. The editors can find themselves swamped with work, which then delays the release of the documentation. Management in an attempt to remove the process bottleneck or to reduce costs may simply cut the editorial stage. Editors are an increasingly rare bird these days.

The politics of change

The restructuring and musical chairs that often follows an M&A can mean that the person put in charge of the newly created or restructured documentation department may not be the person with the most experience in technical communications or in working in a global business environment encompassing many countries and languages. The choice of a leader can be “political”, which could impede the success of implementing global standards. The style guide itself can also pose “political” issues that may determine whether or not the different virtual teams use it correctly.

Need to develop business awareness

Those tools that could help us do our work more efficiently need budgets. The impact of M&As on documentation forces us to become better at understanding the business decisions made by upper management. Our discussion brought up the issue that there’s often a lack of understanding by documentation managers on how global business operates and how cultural differences impact our work. Not all regional markets within a company may do business the same way, for example, so the documentation needs can vary around the world.

Shared stories

Our one hour discussion didn’t solve the problem on how to make it easier to harmonise documentation written globally. But we got to share our stories and compare notes and to realise that we’re not alone in our harmonisation problems.

How have M&As impacted your implementation of global documentation standards?

Learn about the candidates on the STC website where there is a section dedicated to the 2012 election information. The following offices are to be filled:

• Vice President
• Secretary
• Director (two positions to be filled)
• Nominating committee (two positions to be filled)

The full slate of candidates includes a mini-bio for each person and a link to a personal page. You can read more about each person on their personal page, along with links to Twitter accounts, personal websites, and audio files. Read about these people who can make a big difference to the future of STC and remember to cast your vote.

Who can vote?

All members can vote, but are you an active member? All memberships in STC operate on a calendar year basis, so no matter when you joined or last renewed, your membership expired on 31 December. STC has a grace period for renewals, but you must renew by 29 February to be eligible to vote in the STC election.

You can also post questions for the candidates to answer. Ask a few questions to help you determine who gets your vote. Your opinion counts. Share it by voting!

Most people replied that they would prefer to discuss internationalisation and global work issues (82%) covering producing documentation for international audiences and working with teams/companies located globally. Fewer (18%) were interested in discussing localisation and translation issues covering adapting documentation to regional needs and translation project issues.

Top internationalisation & global work topics to discuss

The survey gave a list of five proposed topics for discussion and here are the results in order of preference:

1. Global harmonisation of documentation standards across different writing groups in a company
2. Getting started in terminology management
3. Collecting metrics about our documents
4. Impact of mergers and acquisitions on documentation and writing teams, particularly if the teams are located across different countries
5. Making a business case to get a new tool for doing documentation

Internationalisation & global work topics proposed by respondents are

• Embedded information in globalised software
• Content structure differences across languages and locales
• Why tech pubs is the logical department to lead these tasks

Top localisation and translation issues topics to discuss

The survey gave a list of four proposed topics for discussion and here are the results in order of preference:

1. Doing more with less when translating manuals – let’s talk money.
2. European Union directives and their impact on documentation.
3. Absent best practices – Most localisation problems start with the English source documentation.
4. The impact can poor content and layout on localization.
5. Stepping into the House of Babel. What to consider when starting to get our documentation translated.

When to hold the chats

We also asked about when you’d like to hold the chats. Most of you (44%) preferred the second week of the month to hold the chat. Wednesday was the most popular day (50%) but Tuesday and Thursday scored well too (39% each).

Two times were favoured for the chats: 16:00 CET (10:00 am EST) and 17:00 CET (11:00 am EST). Both scored 56%. Third most popular time was 18:00 CET (12:00 EST) scoring 50%.

Our next chat

So for 2012, we’ll be holding our Watercooler Webinar chats on Wednesdays, the second week of the month. Later in the afternoon seems the best time, either 16:00 or 17:00 CET. Over the next couple of months we’ll discuss the two top topics selected, Global harmonisation and Getting started in terminology. These results also give us good ideas for webinar presentations by invited speakers.

Our next Watercooler Webinar chat will be on Wednesday, 8 February. Details will be sent out to members shortly.

And don’t forget Alice Jane Emanuel’s webinar on Thursday, 31 January, on documentation and typography! It should be excellent.

This 1-hour session will introduce you to best practices in design and typography for technical communication and will include plenty of practical advice that you can use right away to improve reader comprehension and information absorption.

Read all the details, including registration now!

This webinar is sponsored by UTC Fire & Security EMEA.

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 writing a Dutch address in English, which country name format do you use: Netherlands or The Netherlands?

Both work. Indeed on some English-language web sites you may even see both formats used.

I admit I have always used the “The Netherlands” format in addresses, as do many people. The Dutch themselves, when writing their country name in English in addresses, also tend to use “The Netherlands”. For example, the Taalunie, the Dutch language body, uses this format in its English address as shown on their contact page.

Officially the post office format is “Netherlands”. Try using this list of postal formats for writing country names in addresses.

In English, and several other languages, we use the plural form of the country name, the Netherlands, but in Dutch they now use the singular form, Nederland. However, in the official name of the country, Kingdom of the Netherlands (Koninkrijk der Nederlanden), they still use the plural.

The Netherlands isn’t the only country with “the” as a prefix to its name. Ukraine during the Soviet era was always known in English as “the Ukraine”. However, it is now more frequent to use the name when writing it in text without “the”. On the other hand, a former colonial territory in Africa once known as Gambia now insists since its independence on being called The Gambia.

Did you know that not all countries use postal codes (also known as zip codes)? Around 70 countries in the Universal Postal Union (190 members) don’t use postal codes, including Ireland and Panama (see http://en.wikipedia.org/wiki/Postal_code). Ireland is currently planning on introducing postal codes. My sister lives in the Irish countryside and currently doesn’t have a single number in her address. Post arrives punctually.

You will also sometimes see the ISO 2-letter country code (ISO 3166-1) prefixed to a country’s postal code (for example, NL-7900). This practice is more frequently seen in continental Europe for international mail.

Addressing an envelope can be enough to drive one to a glass of whiskey. Except that whiskey itself has its own flavours of spelling. To the surprise of many people “whiskey” doesn’t follow standard UK/US English spelling rules. Its spelling depends on its country of origin. Scottish and Canadian whisky. Irish and American whiskey (visit any shop selling the drink for confirmation). “Scottish whiskey” is a serious ouch!

(Note: The author of this article is Irish, so of course “whiskey” has an “e”.)

We’re increasingly hearing about how important it is for us to manage our terminology as it impacts documentation quality, translation cost, branding and customer satisfaction.

It’s no secret that most terminology problems start in the source content. Unfortunately the inconsistent use of terms in user interfaces, online and printed documentation, marketing material and web content often only comes to light during the translation when it can be too late or too expensive to fix.

Glossaries used by writers are often inadequate

Although we all probably use company glossaries or style guides to help us use terms correctly and consistently in our work, the glossaries often represent only a fraction of the terms we actually use in our work.

A clue that our glossaries may not be comprehensive enough can often come from the translators (our customers may also be having problems with our terms, but we’re rarely in contact with them).

Translators often complain that those responsible for creating the source content don’t document enough terms. They may receive a glossary from us with only a couple hundred terms or less to help them with their work. According to the terminologist, Barbara Inge Karsch, content creators document only around 20% of the terms needed by translators.
Also see our post on the SDL terminology survey last year.

For example, in my company we found out at the translation stage that we had five different ways of saying “power up” in our English manuals:

Power up, power on, energize, activate, start

However, only one of these terms, “power up”, was included in our glossary. The other four were unapproved undocumented terms that had all been used (several times) at some stage by writers. Perhaps when reusing existing content from different products or by a contract writer new to our products.

How many terms should we document?

It depends. It depends on the size of your project, the complexity of the products being documented, number of terms already documented, your budget and resources.

Barbara Inge Karsch has a good discussion on selecting terms in her blog post “How many terms do we need to document?”

However, few companies can afford the services of a dedicated terminologist. Indeed smaller companies may not even have an editor to help ensure that terms are correctly used by writers.

As technical writers we have to stop pretending that terminology is a “translation problem”.

We’re implicated as creators of the source content. We need to ensure that we develop comprehensive glossaries at the start of a project. This will free developers, writers, and ultimately translators, from spending time researching the terms themselves and potentially coming up with multiple terms for the same feature, which then go undetected throughout the product life cycle and can impact usability and incur extra costs.

Heading towards terminology management

Ideally we shouldn’t be keeping our terminology in a style guide or spreadsheet as they can eventually become too inflexible. Unfortunately terminology management tools are still expensive. For many of us, particularly if we’re lone writers or work for a smaller company, they may not yet be an affordable option. This is why Microsoft Excel is so widely used in the tech communication environment to manage glossaries. Everyone has it.

So spreadsheet tools are useful to help start us managing our terminology as they let us collect the terms we work with. And that’s the challenge, collecting the terms. Developing and maintaining a comprehensive glossary is hard work. But the sooner it is done in the documentation process, the better.

As Barbara Inge Karsch says,“As terminology management becomes more accessible and as needs for terminology data become more important, it is up to content creators and LSPs [localisation service suppliers] to learn more about this area and to find ways to consider terminology requirements earlier on in the document creation process.”

Outsourcing manufacturing is big business. Many companies today use the services of other companies to make, even design, some of their products as it can provide them with needed components or products without owning and operating a factory to do this work themselves. The benefits are cost savings, improving time to market, and access to a wider range of products than they could develop themselves in-house. Both hardware and software are outsourced.

What’s an OEM?

Companies to whom manufacturing is outsourced are called Original Equipment Manufacturers (OEMs). An OEM is a company that “manufactures goods that are sold to other businesses that might rebrand them and sell them at retail”. Source of OEM definition.)

An Original Design Manufacturer (ODM) is a company that “designs and manufactures a product which is specified and eventually branded by another firm for sale”. (Source of ODM definition.)

OEM and ODM products are used in many industries, but particularly so in electronics. These companies are located around the world but many are based in Asia. In this article “OEM” has been used to cover both OEM and ODM companies.

The OEM source files

If you are rebranding or rewriting OEM documentation, be aware that in the world of OEMs, Microsoft Word rules. As cost control is a big issue with many OEMs, few have technical writers in-house but instead get their engineers to write the documentation. They use Word.
And often they’re not writing in their mother tongue – most OEMs aren’t located in English-speaking countries. The documentation consequently can often be poorly written and riddled with an “English” contaminated by another language.

Rewriting OEM manuals can be challenging, particularly if you’re working to a tight deadline and the English is poor. If your company works with many OEM products, a further challenge is trying to keep the rewritten manual consistent with the content of the other manuals in your company. Reuse of content is particularly important to help control translation costs. Yet writing for reuse can at times feel a challenge when you’re struggling with reading to comprehend, particularly if you don’t have access to the OEM engineers to ask what they meant in the text they wrote.

Some companies just simply rebrand an OEM manual and leave the content as is. There are unfortunately many examples of such manuals on the internet. Lots of companies don’t have the services of technical writers. And don’t consider the business benefits of having them either.

Keeping terminology correct and consistent

Working with OEM software and documentation increases the need for terminology control as there’s a greater chance of unapproved, inconsistent, and incorrect terms being present than when content is developed in-house. Even when correct, terms may also not always be the same between companies.

Build a glossary of terms related to your OEM documentation and software that includes both the correct and incorrect terms. Include context of use, the definition of the term. So next time a writer in your group is working on an OEM manual and they come across “appearance time”, for example, they can quickly look it up in the glossary and see that this must be changed to “display time”. As with all glossaries, this is a living document and must be regularly maintained.

Fluency in other languages is certainly a help when working with OEM documentation as it can make it easier to spot problems with terminology. One example we had of “flavoured” English was in the software of a French ODM we used to develop a program for us. They used the term “equipments” throughout the English source software. We changed this franglais (English with French influence) term to “devices”. The word “equipment” exists in both languages but the context of use can differ. In French this is called a “faux amis” or “false cognate” in English. Be continually on the lookout for such faux amis when checking software and documents written by OEMs.

Where possible, give the OEM your company’s glossary of approved terms to use when customizing products for your company. But continually check that your company’s approved terms are indeed being used, particularly when the product is updated. A different engineering team perhaps might be put in charge of the product update and for whatever reason they could ignore or overlook your glossary. Stay alert.

Legal issues

Reuse as is or rewrite the OEM documentation? This question will be answered in the contractual agreement drawn up between the OEM and the company using their services. It will specify whether the product documentation will be handed over by the OEM to be customized. So if you have any specific documentation needs, such as you want to the source files in XML, FrameMaker, or HTML, for example, you should ensure that this is agreed upon before any contractual agreement is signed. But as stated earlier, most OEMS work in Word.

In my experience, many OEM manuals have incomplete or no regulatory information included, where required. If you are rebranding/rewriting OEM manuals, check that all required legal information is indeed included for your market. Although legally the manufacturer is responsible for placing the CE mark on the product, for example, once you rebrand it, you then become legally responsible. See an earlier blog on sharing source files with third party companies.

Localisation issues

In my experience, few OEM companies consider the impact of localization on their software and documentation even if they are selling their products worldwide. And that includes OEMs with in-house technical writers.

If you will be translating the documentation you’ve inherited from an OEM, you should review it for potential localization issues such as embedded text in graphics (do you have the source graphic files or just the jpeg files?), terminology (mentioned earlier), and possible cultural issues in the content. One OEM my company worked with had in-house native English-language technical writers who targeted their documentation to the America market although the OEM sold its products in many other countries. They had, for example, used the term “Thanksgiving” in a section of a user manual on programming schedules instead of the generic “public holiday”. We had to carefully go through their manuals to ensure that the content was culturally neutral for our market in Europe, Middle East, and Africa.

In summary

• From the contractual agreement and your product managers, find out what has been agreed with the OEM with regards to the documentation.
• Develop a glossary specific for this OEM (or expand your group’s glossary) that includes correct and incorrect terms.
• Check that the legal information in your rebranded/rewritten documentation is correct and complete.
• If you translate, check for potential localization issues.

The Society for Technical Communication (STC) is one of the world’s largest organisations for technical communication. We have members across the world. Currently around 18% of STC members are based outside of the United States, most in Canada. Around 5% of members are in Europe and Asia. So perhaps it shouldn’t be too surprising if it can have a very US-centric focus as most members are there.

But it is surprising. And frustrating.

Our business is communication and an increasing number of us work globally. Even if we may not travel as part of our jobs or be based in a foreign country, our work could well be used in multiple countries and languages.

Being global in outlook matters. Understanding how “global” impacts our work and jobs is important so that we can then better meet customer and colleague needs wherever they may be based. It also means we are better able to professionally evolve to changing market demands. As an international professional organisation, STC should be there helping us irrespective of where we’re based.

Problems faced by members based outside of the US

Non US-based members have been complaining for several years to the STC board about the lack of a real global outlook from headquarters and how poorly non US-based members are often served. Examples of current issues are

• Some membership benefits only available to US members
• Cost of webinars
• Can only pay using credit cards (EFT – electronic funds transfer – still not available)
• Lack of regional conferences and workshops
• Poor communication between headquarters and members
• Lack of in-depth sessions on localisation/internationalisation at conferences
• And the lack of globalized content in the Society Web site, communications and forms (such as dates, times, addresses)

Responding to our requests for change, in 2006 the STC board set up a committee to review how the society could better meet the needs of its international members. This Global Strategies committee advised the office and board on many globalisation issues. A globalisation audit of the society unfortunately had to be postponed in 2008 due to the financial crisis.

So how are we doing with globalising the society?

A year ago, the Globalisation Audit Task Force (GATF) was set up to determine how the society could improve communication with non US-based members and determine issues that needed to be resolved.
Over the past year GATF has collected a list of globalisation issues from multiple sources within in the STC such as our forums and conversations with members as well as reviewing the old website. They also interviewed non US-based members on their needs. All this work provides an insight into the problems faced by members based around the world and gives an informative update on where the STC is in its progress on becoming a more globalised organisation, better able to meet the needs of a multi-cultural membership working in a world that gets smaller every day.

The 2011 GATF report and the presentation of the GATF report to the STC Board at the 2011 annual conference last May make interesting reading. I strongly encourage you to read them.

Where do we go from here?

Progress on improving the international outlook of the society has been slow so this work by GATF is a good step forward. The report gives a practical list of action items and advises that the society how it could proceed.

From this list, we see that there are several things we could all do individually and collectively to push global issues:

• Educate members on globalisation: Write articles and blogs on STC sites (including the Europe SIG). If you have experience in globalisation, seriously consider submitting a proposal to the annual conference that’s aimed at other experienced members.
• Make webinars more available to different time zones: Run webinars ourselves to make them more accessible to members in different time zones. However, running a webinar using the facilities used by STC headquarters, Genesys, is too expensive when based outside of North America. Fortunately, there are many other tools around that are more affordable. We could compare notes with other regional groups on suitable webinar tools. Seek sponsorship to make them more affordable.
• Planning regional conferences (and with volunteers) is hard work (I’ve helped with a few and can speak from experience) so they won’t be annual events. Local initiative gets these off the ground. They don’t have to be large events. Perhaps partner with another international or national association on a shared theme?

Clearly change won’t happen overnight but we need to ensure that the board and office don’t just sit back and do little to solve this growing need. So this is where we all come into the equation. A small committee can only push so hard. We should now all help push the society to become the international society that so many of us want (and expect).

What ideas do you have for pushing these changes forward?
What suitable and affordable webinar tools can you recommend?
Are there issues not covered in the GATF report?

Share your thoughts and ideas in the comments.