<?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>Wed, 02 Jun 2010 09:00:14 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<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 of [...]]]></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 encountered [...]]]></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 to do [...]]]></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>
