<?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; Tips and Tricks</title> <atom:link href="http://www.stc-europe.org/category/tips-and-tricks/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>Double Dutch: Writing addresses</title><link>http://www.stc-europe.org/2011/11/08/double-dutch-writing-addresses/</link> <comments>http://www.stc-europe.org/2011/11/08/double-dutch-writing-addresses/#comments</comments> <pubDate>Tue, 08 Nov 2011 08:38:30 +0000</pubDate> <dc:creator>admin</dc:creator> <category><![CDATA[Tips and Tricks]]></category> <category><![CDATA[addresses]]></category> <category><![CDATA[formats]]></category> <category><![CDATA[postal codes]]></category> <category><![CDATA[spelling]]></category> <guid
isPermaLink="false">http://www.stc-europe.org/?p=601</guid> <description><![CDATA[by Jen O Neill 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 [...]]]></description> <content:encoded><![CDATA[<p><em>by Jen O Neill</em></p><p>When writing a Dutch address in English, which country name format do you use: Netherlands or The Netherlands?</p><p>Both work. Indeed on some English-language web sites you may even see both formats used.</p><p>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 <a
href="http://taalunieversum.org/en/contact_us/" rel="external">as shown on their contact page</a>.</p><p>Officially the post office format is “Netherlands”. Try using this <a
href="http://www.bitboost.com/ref/international-address-formats.html" rel="external">list of postal formats for writing country names in addresses</a>.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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!</p><p>(Note: The author of this article is Irish, so of course “whiskey” has an “e”.)</p> ]]></content:encoded> <wfw:commentRss>http://www.stc-europe.org/2011/11/08/double-dutch-writing-addresses/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item><title>Glossing over our glossaries</title><link>http://www.stc-europe.org/2011/10/03/glossing-over-our-glossaries/</link> <comments>http://www.stc-europe.org/2011/10/03/glossing-over-our-glossaries/#comments</comments> <pubDate>Mon, 03 Oct 2011 07:15:52 +0000</pubDate> <dc:creator>admin</dc:creator> <category><![CDATA[Documentation]]></category> <category><![CDATA[consistency]]></category> <category><![CDATA[sdl]]></category> <category><![CDATA[survey]]></category> <category><![CDATA[terminology management]]></category> <category><![CDATA[terminology. glossaries]]></category> <category><![CDATA[terms]]></category> <category><![CDATA[writers]]></category> <guid
isPermaLink="false">http://www.stc-europe.org/?p=591</guid> <description><![CDATA[by Jen O Neill 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 [...]]]></description> <content:encoded><![CDATA[<p><em>by Jen O Neill</em></p><p>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.</p><p>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.</p><h2>Glossaries used by writers are often inadequate</h2><p>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.</p><p>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).</p><p>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.<br
/> Also see <a
href="http://www.stc-europe.org/2010/06/02/a-recent-survey-on-terminology- management/" rel="external">our post on the SDL terminology survey last year</a>.</p><p>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:</p><p
style="text-align: center;">Power up, power on, energize, activate, start</p><p>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.</p><h2>How many terms should we document?</h2><p>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.</p><p>Barbara Inge Karsch has a good discussion on selecting terms in her blog post <a
href="http://<br /> bikterminology.com/2010/12/17/each-time-a-new-project-is-kicked-off-this-question-is-on-<br
/> the-table-content-publishers-ask-how-much-are-we-expected-to-document-localizers-ask-<br
/> how-many-new-terms-will-be-used" rel="external"</a>&#8220;How many terms do we need to document?&#8221;</a></p><p>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.</p><p>As technical writers we have to stop pretending that terminology is a “translation problem”.</p><p>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.</p><h2>Heading towards terminology management</h2><p>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.</p><p>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.</p><p>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.”</p> ]]></content:encoded> <wfw:commentRss>http://www.stc-europe.org/2011/10/03/glossing-over-our-glossaries/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item><title>Getting Reviews from SMEs</title><link>http://www.stc-europe.org/2011/04/20/getting-reviews-from-smes/</link> <comments>http://www.stc-europe.org/2011/04/20/getting-reviews-from-smes/#comments</comments> <pubDate>Wed, 20 Apr 2011 20:28:35 +0000</pubDate> <dc:creator>admin</dc:creator> <category><![CDATA[Tips and Tricks]]></category> <category><![CDATA[fun]]></category> <category><![CDATA[humor]]></category> <category><![CDATA[humour]]></category> <category><![CDATA[reviews]]></category> <category><![CDATA[technical writers]]></category> <guid
isPermaLink="false">http://www.stc-europe.org/?p=551</guid> <description><![CDATA[by Jennifer O Neill HONORABLE COLLEAGUE, WE ARE THE TECHNICAL WRITERS. YOU WERE RECOMMENDED BY AN ASSOCIATE WHO ASSURED US IN CONFIDENCE OF YOUR ABILITY AND RELIABILITY TO CARRY OUT PENDING REVIEWS IN GREAT MAGNITUDE WITHOUT RAISING ANY MISGIVING ATTITUDE. CONSEQUENTLY WE HAD THE COURAGE TO CRAVE AN INDULGENCE FOR THIS IMPORTANT BUSINESS FOR CHECKING [...]]]></description> <content:encoded><![CDATA[<p><em>by Jennifer O Neill <img
src='http://www.stc-europe.org/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </em></p><p>HONORABLE COLLEAGUE,</p><p>WE ARE THE TECHNICAL WRITERS. YOU WERE RECOMMENDED BY AN ASSOCIATE WHO ASSURED US IN CONFIDENCE OF YOUR ABILITY AND RELIABILITY TO CARRY OUT PENDING REVIEWS IN GREAT MAGNITUDE WITHOUT RAISING ANY MISGIVING ATTITUDE.</p><p>CONSEQUENTLY WE HAD THE COURAGE TO CRAVE AN INDULGENCE FOR THIS IMPORTANT BUSINESS FOR CHECKING MANUALS BELIEVING THAT YOU WOULD NEVER LET US DOWN EITHER NOW OR IN THE FUTURE. UNFORTUNATELY THE INFORMATION DEPT. OF ARCHITECTURED CONTENT IS REGRETFUL THAT INVESTIGATIONS ON THE EDIT MODIFICATIONS BY YOU RECEIVED TO US DO NOT ALWAYS ASSIST THE DOCUMENT. FURTHERMORE, YOUR URGENT ASSISTANCE OCCASIONALLY LACKS URGENCY. THE OWNERS OF THE DOCUMENTS YOU RECEIVE FROM US ARE NOT DIED &#8211; WE MOST GRACIOUSLY SEEK THE DOCUMENTS BACK FROM YOU WITHIN THE GIVEN GENEROUS 2-DAY PERIOD OF REVIEW.</p><p>WE WANT TO CONTINUE TO TRANSFER DOCUMENTS FOR REVIEW BECAUSE OF THE NEED TO INVOLVE YOU AS AN EXPERT MATTER WORKER WHO CAN APPROVE THE NOBLE CONTENTS. HOWEVER, WE REQUIRE CO-OPERATION THAT FUTURE TRANSACTIONS BETWEEN US COMPLY WITH OUR STYLE STANDARDS AND TIME SCALE.</p><p>WE NOW APPROACH YOU WITH INSTRUCTIONS THAT WILL BE OF IMMENSE BENEFIT TO BOTH OF US. PLEASE FOLLOW THE ENCLOSED INSTRUCTIONS CAREFULLY.</p><p>FURTHERMORE PLEASE IMMEDIATELY SEND US YOUR BANK ACCOUNT DETAILS FOR WHEN WE MAY TO NEED TO ACCESS YOUR ACCOUNT TO IMPOSE AN EDUCATION FINE ON UNURGENCY OR STYLISTIC REWRITING. WE ALREADY HAVE YOUR WORK TELEPHONE NUMBER AND EMAIL. DO NOT BE CONCERNED ABOUT CURRENCIES. WE TAKE EVERYTHING.</p><p>THANKING YOU FOR YOUR ANTICIPATED COOPERATION.</p><p>YOURS MOST TRULY,</p><p>TECHNICAL WRITER</p><p>INSTRUCTIONS FOR REVIEW OF MANUAL BY EXPERT MATTER PERSON:</p><p>1. WE HONOURABLY SEEK YOUR ASSISTANCE WHEN REVIEWING NOBLE DOCUMENT. YOUR UTMOST SENSE OF PURPOSE IS REQUIRED. MOST KINDLY REFRAIN FROM DOING MULTIPLE OTHER TASKS AT SAME TIME.</p><p>2. IT IS UNPERMITTED TO REWRITE THE REVIEW DOCUMENT. REWRITES OF PARAGRAPHS THAT AGITATE EDITOR WILL BE CHARGED AT $30 PER PARAGRAPH.</p><p>3.  URGENT ASSISTENCE IS MOST KINDLY REQUESTED TO RETURN REVIEWS AS SPECIFIED IN INSTRUCTED DEADLINE. REVIEWS RECEIVED AFTER 19.00PM ON DEADLINE DAY SHALL INCUR LATE FINE OF $20 PER DAY LATE. LATE RETURNS BEYOND ONE MONTH SHALL INCUR $800 MONTHLY CHARGE PER DOCUMENT. IMPACT IF NEVER RETURN OR LOST DOCUMENT SHALL BE FINE OF $1000 AFTER 3 MONTHS. PERTISTENT UNURGENT RESPONSE WILL RESULT IN YOUR PHONE NUMBER ON RELEASED DOCUMENT COVER TO FACILITATE FRIENDLINESS TO END USER.</p> ]]></content:encoded> <wfw:commentRss>http://www.stc-europe.org/2011/04/20/getting-reviews-from-smes/feed/</wfw:commentRss> <slash:comments>2</slash:comments> </item> <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>Planning your in-country reviews</title><link>http://www.stc-europe.org/2010/01/11/planning-your-in-country-reviews/</link> <comments>http://www.stc-europe.org/2010/01/11/planning-your-in-country-reviews/#comments</comments> <pubDate>Mon, 11 Jan 2010 11:30:36 +0000</pubDate> <dc:creator>admin</dc:creator> <category><![CDATA[Tips and Tricks]]></category> <category><![CDATA[guidelines]]></category> <category><![CDATA[localisation]]></category> <category><![CDATA[multilingual]]></category> <category><![CDATA[planning]]></category> <category><![CDATA[reviewing]]></category> <category><![CDATA[translations]]></category> <guid
isPermaLink="false">http://www.stc-europe.org/?p=356</guid> <description><![CDATA[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 [...]]]></description> <content:encoded><![CDATA[<p><em>by Jennifer O Neill</em></p><p>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.</p><h3>Who should do the reviews</h3><p>A good reviewer is a</p><ul><li>Company employee</li><li>Native speaker of the target language</li><li>Product SME</li><li>Stakeholder in the process of producing quality translated documentation</li></ul><p>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.</p><h3>Develop localisation guidelines</h3><p>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.</p><p>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</p><ul><li>Use approved terminology in your review (and use it consistently)</li><li>Don’t try to rewrite the document</li><li>Check that decimal and measurements notation is appropriate for your region or language</li><li>Try to ensure that the same person reviews each translation project for consistency</li><li>Mark your requested changes in the correct format (Track Changes for Word files or comments for PDF files)</li><li>Contact the person overseeing the translation project if you have any concerns about the  document content or translation quality</li></ul><h3>Don’t forget multilingual glossaries</h3><p>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.</p><p>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.</p><h3>The reviewer’s changes</h3><p>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.</p><p>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.</p><p>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.</p><p>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.</p><h3>Become a close team</h3><p>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.</p> ]]></content:encoded> <wfw:commentRss>http://www.stc-europe.org/2010/01/11/planning-your-in-country-reviews/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item><title>Producing documentation for the Japanese market</title><link>http://www.stc-europe.org/2010/01/08/producing-documentation-for-the-japanese-market/</link> <comments>http://www.stc-europe.org/2010/01/08/producing-documentation-for-the-japanese-market/#comments</comments> <pubDate>Fri, 08 Jan 2010 13:01:32 +0000</pubDate> <dc:creator>admin</dc:creator> <category><![CDATA[Tips and Tricks]]></category> <category><![CDATA[compliance]]></category> <category><![CDATA[Japan Technical Communication Association]]></category> <category><![CDATA[national standards]]></category> <category><![CDATA[translation]]></category> <guid
isPermaLink="false">http://www.stc-europe.org/?p=350</guid> <description><![CDATA[by Jennifer O Neill Although my focus at work is producing documentation for the EMA market (Europe, Middle East and Africa), it’s always interesting to learn about what’s happening in other regional markets. At the 2009 tekom conference in Weisbaden, Germany, a speaker from the Japan Technical Communication Association gave a presentation on frequent problems [...]]]></description> <content:encoded><![CDATA[<p><em>by Jennifer O Neill</em></p><p>Although my focus at work is producing documentation for the EMA market (Europe, Middle East and Africa), it’s always interesting to learn about what’s happening in other regional markets. At the 2009 <a
href="http://www.tekom.de/" rel="external" tabindex="1">tekom</a> conference in Weisbaden, Germany, a speaker from the Japan Technical Communication Association gave a presentation on frequent problems encountered in the Japanese market with manuals written in Europe.</p><p>A frequent problem is that of non-compliance with national standards, such as those related to safety. As EU directives are an important legal issue for the European targeted manuals that we do in my company, I can well understand the importance of complying with Japanese requirements.  It is also important to clearly state when information in the manual does not apply to Japan. Around 70% of Japanese people read the manuals when they buy a product. Since 2007, product accidents are now publicly reported in the press.</p><p>Another problem encountered is that of using English terms in translated manuals or doing a phonetic translation where the English sound is preserved but the meaning lost. Translations for the Chinese market must use approved terms.</p><p>Recently a consumer magazine in Japan conducted a survey of its readers, asking them what were the most important items they wanted when using printed product manuals. The top 10 answers were</p><ul><li>Larger font size</li><li>More illustrations and visual explanations</li><li>Fewer pages</li><li>Friendly explanations for beginners</li><li>Fewer foreign terms used in the text</li><li>Easy-to-use instructions</li><li>Fewer technical terms</li><li>Better explanations for elderly users (Japan has an ageing population)</li><li>Clearer separation between basic functions and advanced ones</li><li>Manual has a table of contents and an index</li></ul><p>The desires of readers seem similar worldwide.</p> ]]></content:encoded> <wfw:commentRss>http://www.stc-europe.org/2010/01/08/producing-documentation-for-the-japanese-market/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item><title>Best practices for user assistance</title><link>http://www.stc-europe.org/2010/01/08/best-practices-for-user-assistance/</link> <comments>http://www.stc-europe.org/2010/01/08/best-practices-for-user-assistance/#comments</comments> <pubDate>Fri, 08 Jan 2010 12:55:15 +0000</pubDate> <dc:creator>admin</dc:creator> <category><![CDATA[Tips and Tricks]]></category> <category><![CDATA[best practice]]></category> <category><![CDATA[typography]]></category> <category><![CDATA[usability]]></category> <category><![CDATA[user assistance]]></category> <guid
isPermaLink="false">http://www.stc-europe.org/?p=342</guid> <description><![CDATA[by Jennifer O Neill At the 2009 tekom conference in Weisbaden, Germany, Scott DeLoach of ClickStart Inc. gave an excellent overview of what research has found on the usability of user assistance. Research has found that Users prefer Arial over Verdana and Tahoma. The two latter fonts were developed for onscreen reading. People tend not [...]]]></description> <content:encoded><![CDATA[<p><em>by Jennifer O Neill</em></p><p>At the 2009 <a
href="http://www.tekom.de/" rel="external" tabindex="1">tekom</a> conference in Weisbaden, Germany, Scott DeLoach of ClickStart Inc. gave an excellent overview of what research has found on the usability of user assistance. Research has found that</p><ul><li>Users prefer Arial over Verdana and Tahoma. The two latter fonts were developed for onscreen reading. People tend not to do extensive reading on-screen.<br
/> TNR scored the same as Verdana when reading short texts.<br
/> <br
/> Many users have problems reading on-screen text that is below 10 point. Older users prefer text to be 12/14 point.</li><li>Users don’t like scrolling. They prefer to read a screen than scroll down it to find the information.</li><li>Users want quick answers.  They focus on minimizing effort rather than maximizing learning. “Easy to find” ranked higher than “Correct information”. They are focused on completing a task.<br
/> Users scan information; they don’t read long sentences. Limit sentences to 20 words.</li><li>Novices use introductions to remember information and build knowledge. However, experts are frustrated by overviews. Experts scan for procedures, notes, and tips.<br
/> Consequently don’t put technical information in overviews.<br
/> Users learn from examples so FAQs are very popular.</li></ul><h3>Linking guidelines</h3><ul><li>Users spend up to 80% of their time in the first screen. Many prefer to move to another screen than to scroll down. Therefore don’t put links at the bottom of a screen.<br
/> Preferably place links in the right margin of a screen.</li><li>Use text links rather than image links. This is mainly because they change color when clicked. Text is also easier to customize that an image.</li><li>Use links that are descriptive. Don’t simply say “Help”. Instead, for example, say “How do I …”, “Quick tips” ….</li></ul><p>You can find more information on this topic at <a
href="http://www.clickstart.net/?page_id=8" rel="external" tabindex="1">http://www.clickstart.net/?page_id=8</a></p> ]]></content:encoded> <wfw:commentRss>http://www.stc-europe.org/2010/01/08/best-practices-for-user-assistance/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> </channel> </rss>
