<?xml version="1.0" encoding="UTF-8"?> <rss
version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
> <channel><title>STC Europe SIG &#187; Language</title> <atom:link href="http://www.stc-europe.org/tag/language/feed/" rel="self" type="application/rss+xml" /><link>http://www.stc-europe.org</link> <description>Society for Technical Communication&#039;s Europe SIG</description> <lastBuildDate>Mon, 23 Jan 2012 11:58:13 +0000</lastBuildDate> <language>en</language> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=3.3.1</generator> <item><title>When the manual speaks in many tongues: The multilingual manual</title><link>http://www.stc-europe.org/2010/08/25/when-the-manual-speaks-in-many-tongues-the-multilingual-manual/</link> <comments>http://www.stc-europe.org/2010/08/25/when-the-manual-speaks-in-many-tongues-the-multilingual-manual/#comments</comments> <pubDate>Wed, 25 Aug 2010 06:06:33 +0000</pubDate> <dc:creator>kmardahl</dc:creator> <category><![CDATA[Documentation]]></category> <category><![CDATA[Language]]></category> <category><![CDATA[manuals]]></category> <category><![CDATA[multilingual]]></category> <category><![CDATA[planning]]></category> <guid
isPermaLink="false">http://www.stc-europe.org/?p=498</guid> <description><![CDATA[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 [...]]]></description> <content:encoded><![CDATA[<p><em>by Jen O Neill</em></p><p>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.</p><p>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.</p><p>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.</p><p>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:</p><h3>Purpose</h3><p><em>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?</em></p><p>This will help you decide the type and extent of information required in the multilingual manual.</p><h3>Space</h3><p><em>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)?</em></p><p>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.</p><h3>Graphics</h3><p><em>Do you have access to high quality graphics?</em></p><p>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.</p><p>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.</p><p>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.</p><h3>Budget</h3><p><em>Are there budget limitations for producing and printing this manual?</em></p><p>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.<br
/> How many languages will be included in a multilingual manual?</p><p>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.</p><p>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.</p><p>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.</p><h3>And you?</h3><p>What’s been <strong>your</strong> experience of writing them? As a reader, which ones did you particularly like or dislike?</p> ]]></content:encoded> <wfw:commentRss>http://www.stc-europe.org/2010/08/25/when-the-manual-speaks-in-many-tongues-the-multilingual-manual/feed/</wfw:commentRss> <slash:comments>4</slash:comments> </item> <item><title>A recent survey on terminology management</title><link>http://www.stc-europe.org/2010/06/02/a-recent-survey-on-terminology-management/</link> <comments>http://www.stc-europe.org/2010/06/02/a-recent-survey-on-terminology-management/#comments</comments> <pubDate>Wed, 02 Jun 2010 09:00:14 +0000</pubDate> <dc:creator>admin</dc:creator> <category><![CDATA[Language]]></category> <category><![CDATA[localisation]]></category> <category><![CDATA[localization]]></category> <category><![CDATA[survey]]></category> <category><![CDATA[terminology]]></category> <category><![CDATA[terms]]></category> <category><![CDATA[translation]]></category> <guid
isPermaLink="false">http://www.stc-europe.org/?p=479</guid> <description><![CDATA[by Jen O Neill Even if you only produce documentation in a single language and don’t deal with an international audience, using consistent terminology matters. SDL recently released the results of a terminology survey that they conducted earlier this year. The study is an interesting review on the trends and opinions on the subject of [...]]]></description> <content:encoded><![CDATA[<p><em>by Jen O Neill</em></p><p>Even if you only produce documentation in a single language and don’t deal with an international audience, using consistent terminology matters.</p><p>SDL recently released the <a
href="http://www.sdl.com/en/sites/terminology-survey-2010/" rel="external" tabindex="1">results of a terminology survey</a> that they conducted earlier this year. The study is an interesting review on the trends and opinions on the subject of terminology management.</p><p>They asked two groups about terminology management: a business audience and translators.</p><p>When asked what they considered to be the most important impact of inconsistent terminology, the business audience replied the quality of the content, internal communication and customer satisfaction. Inconsistent terminology also impacts the cost of translation and branding.</p><p>Three departments are largely responsible for owning the terminology in a company: Technical Publications, Translation/Localisation, and Marketing. They’re responsible for the management, maintenance and approval of terminology.</p><p>The most common internal process they used for managing terminology were style guides and spreadsheets to store terms. Over 35% of the business respondents said that they keep their terminology in a style guide. However, only 50% shared their terminology lists with other departments in the company.</p><p>This lack of sharing with other departments obviously increases the risk that departments could be using different terms for the same meaning. And yet, as so many departments in a company use common terminology—not just technical publications and marketing—it’s a lost opportunity not to collaborate in sharing terminology to ensure consistency.</p><p>All parties taking part in the survey agreed that the problems related to inconsistent terminology start with the source documentation. Indeed 40% of translators said that they frequently encountered inconsistent terminology.<br
/> The translators said that the main impact of inconsistent terminology is on translation quality, style and consistency, client satisfaction and their productivity. These are the parameters often used to measure a translator’s success and performance. We can conclude from this that consistent terminology makes the translator’s work much easier as well as improving quality.</p><p>An interesting point shown in the survey is how few companies take responsibility for their terminology in the localization stage. The translators said that only 15% of clients drove terminology management. Terminology management just isn’t part of the localization strategy of many companies (they do have a localisation content strategy, right?). Indeed it’s more likely that the translator takes ownership of terminology than the company that created the source documentation being translated. We put all that effort in creating a document and then practically abandon control over it when it moves to another language.</p><h3>An example: Same meaning, different terms</h3><p>Over the years my company has been through various acquisitions and mergers. Being a global company, content is also created across the globe by different groups. The content is often then reused in different documents. All this has provided many opportunities for inconsistency in our terminology. For example, the following six terms have all appeared in our product datasheets.</p><ul><li>Operating temperature</li><li>Temperature range</li><li>Temperature</li><li>Working temperature</li><li>Operating temperature range</li><li>Ambient temperature range</li></ul><p>Unfortunately these terms all describe the same feature: the operating temperature of a product.</p><p>The datasheets were subsequently translated into multiple languages. The inconsistency in the English source terminology has bred inconsistency across the other languages—a domino effect. We’ve found that, for example, we have four different ways to say “operating temperature” in French and three different ways in Spanish (I gave up counting for the other languages). This inconsistency with just one term illustrates the widespread impact that poor terminology management can have across multiple documents and languages.</p><p>SDL’s survey clearly showed that terminology needs to be managed during the whole content life cycle, from the moment we decide a source document is needed through to the localisation of the content.</p> ]]></content:encoded> <wfw:commentRss>http://www.stc-europe.org/2010/06/02/a-recent-survey-on-terminology-management/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item><title>Happening times</title><link>http://www.stc-europe.org/2010/03/30/happening-times/</link> <comments>http://www.stc-europe.org/2010/03/30/happening-times/#comments</comments> <pubDate>Tue, 30 Mar 2010 10:30:11 +0000</pubDate> <dc:creator>admin</dc:creator> <category><![CDATA[Communication]]></category> <category><![CDATA[Language]]></category> <category><![CDATA[localisation]]></category> <category><![CDATA[localization]]></category> <category><![CDATA[rewriting]]></category> <category><![CDATA[translation]]></category> <guid
isPermaLink="false">http://www.stc-europe.org/?p=429</guid> <description><![CDATA[by Jennifer O Neill I work in the manufacturing sector and many of our products are outsourced to suppliers for development and manufacture, to be sold under our company’s brand name. The English terms I come across in the software and manuals that I check can often be amusing in their originality. A Chinese supplier [...]]]></description> <content:encoded><![CDATA[<p><em>by Jennifer O Neill</em></p><p>I work in the manufacturing sector and many of our products are outsourced to suppliers for development and manufacture, to be sold under our company’s brand name. The English terms I come across in the software and manuals that I check can often be amusing in their originality. A Chinese supplier with whom we work called the term “Event” in a product’s firmware “Happening Time”. I don’t know why but the term “Happening time” tickles me. I still changed it to “Event”.</p><p>I’ve no idea how “Rule” became “Handle”.</p><p>I may find amusement in such mistakes but on the down side….</p><p>Over the years I’ve worked with over two dozen suppliers from around the world, most in Asia. Only two of these suppliers have used technical writers to do their manuals. One was in Canada and the other in Israel.</p><p>It was a few years back and at the time neither writing group in these two companies gave sufficient thought to the impact of localisation on their manuals (such as text expansion and embedded text in graphics) as they didn’t translate their work. Yet their companies were selling the products to other companies for resale under other brand names, and these companies often operate in multilingual markets. Such as my own company. I may have had to redo the layouts and graphics of their manuals for localisation, but the English was correct.</p><p>I hope that these two writing groups are now doing manuals that are easy to localise, even if they’re still not doing any translation themselves. Such a step would increase the value of their services to their respective companies, who are keen to expand internationally.</p><p>However, most of the “English” source documents I receive to customise for my company are written by engineers in non-English speaking countries. The level of English varies from “Nearly there” to “????”.</p><p>The standard localisation issues with text expansion, embedded text in graphics, and inconsistent terminology are obviously also present. The Tech Comm world may be a buzz with XML and DITA but Microsoft Word is doing great in the world of many companies. So is Normal style. These issues are easy, if perhaps time consuming, to fix.</p><p>What does shock me is how many companies release manuals and software with poor, at times incomprehensible, English. If you then plan to then translate the documents and software, poor English will then often mean even worse translations. And translating isn’t cheap.</p><p>Training technical writers isn’t the problem. It’s training companies to have higher expectations on the quality documentation and software they provide to customers. Customers matter. Being able to use a product easily matters. Crap English impacts your bottom line.</p><p>Companies also need to realise that being able to speak English sort of OK isn’t the same as being able to write it correctly. Users – and translators  – can tell the difference.</p><p>I know that English-mother tongue or fluent writers aren’t easy to find in many of the new growing industrial areas of the world. One of our Chinese suppliers is now getting a Chinese engineer who lived in the US for several years to do their manuals. The English is better (from a low base line). It’s still foreign-flavoured English, but it is at least easier to understand and is a step in the right direction for the resources they have at hand. Realistically, the chances of them hiring a mother-tongue writer in their city are minimal. We still rewrite their documentation for our customers.</p><p>Last year, I attended the STC France annual conference. During the last session when the speakers were discussing how they thought our profession would evolve in the future, one speaker said that we would be spending more time rewriting other people’s work.  I agree.</p><p>English is now the <em>linga franca</em> of international business. As a result, the quality of English is often suffering. The challenge we face is finding ways to improve written English in documentation, and to persuade companies it’s worth the investment. Let’s reduce the incidence of all those awful happening times.</p> ]]></content:encoded> <wfw:commentRss>http://www.stc-europe.org/2010/03/30/happening-times/feed/</wfw:commentRss> <slash:comments>3</slash:comments> </item> </channel> </rss>
