TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
In the interest of full disclosure, I train for Tedopres on this very topic.
The best way to build the corporate dictionary (if you don't have one of the
STE management tools), is to start with the glossaries and style guide that
you have for each product, as well as English terms in the localization
glossaries (there should be a lot of overlap, but looking at the
localization glossaries might show areas for potential confusion). Also,
look for terms that you definitely DON'T want people to use and include the
alternative term.
Avoid adding technical verbs, if you can. I say this because of the way we
process unfamiliar terminology. If you understand the verb and have a
rudimentary understanding of the language structure, you can usually figure
out the meaning of the term. However, even if you know the term, if you
don't know the verb, it will be harder to parse the meaning.
If you buy one of the tools, they will run your content through a parser and
identify the term candidates for you (this is really the best way to go;
it's a bit onerous to manually enforce STE). Then, a linguist reviews the
content and supplies you with your initial custom dictionary. Over time, as
your team works with the tool, you will find additional terms to add.
The best practice for handling updates to the corporate dictionary with the
tool is as follows:
--Establish and editorial change control team who is responsible for
reviewing term candidates and approving them (or not) for the custom
dictionary. At first, this team will likely meet 1x/week or every other
week, depending on product release cycles.
--At the beginning of a project, each team member submits glossary terms
that are not in the corporate dictionary yet, and runs a baseline report for
the content.
--As they work, team members collect terms that they think should be added.
(In HyperSTE, you can do this in the user dictionary). When it's time for
the editorial control board meeting, team members download the terms into an
Excel spreadsheet and wipe their user dictionary.
--Editorial control board reviews terms and adds them as appropriate to the
corporate dictionary.
--Team members run the report on their docs after the terms have been added
to compare results to baseline.
You can (and perhaps should) pull terminology management out of the project
level and into a more centralized team that includes localization and
in-country reviewers. Doing so will help improve terminology consistency
across product lines, reduce mistranslations or inconsistent translation,
and reduce localization costs. Terminology will get added to the TM sooner,
resulting in translators being given the preferred translation for the term
early in the process.
Companies that are most successful in implementing STE have strong
editing/QA processes and robust change management.
Regards,
Kit Brown-Hoekstra
Principal, Comgenesis, LLC
PO Box 621265
Littleton, CO 80162
+1 720.542.3075 (work)
+1 303.243.4452 (cell)
"Practice random acts of kindness and senseless beauty."
Coauthor (with Brenda Huettner and Char James-Tanny) of Managing Virtual
Teams: Getting the Most from Wikis, Blogs, and Other Collaborative Tools,
available from http://www.amazon.com.
Message: 1
Date: Fri, 3 Aug 2012 22:15:18 +0800
From: Sandy Harris <sandyinchina -at- gmail -dot- com>
To: TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>
Subject: Re: How to build a Corporate Dictionary for using with
Simplified English
Message-ID:
<CACXcFm=VG2r9oLRnu79GpHNYCOegQQU6GSPZuF6nqmAmwUii7A -at- mail -dot- gmail -dot- com>
Content-Type: text/plain; charset=UTF-8
On Thu, Aug 2, 2012 at 11:51 PM, David Harrison <dharrison -at- moldmasters -dot- com>
wrote:
> One possible answer is to adopt Simplified Technical English in the hope
that ...
> But everything that I read about the journey towards STE tells me that we
first need to build a corporate dictionary of acceptable words and phrases
which will sit alongside the STE limited dictionary where one word has one
meaning. In hindsight - it probably would help with translations to date -
so I don't think this is a futile exercise.
> I have found possible expensive looking solutions like Acrolinx and cheap
looking packages like Maxit form Smartny. And of course the biggies like
Tedopres offer to do it for you in with software and training package. But
does anyone have experiences of creating such a dictionary/glossary and
would they care to give some brief advice or pointers.
My starting point would be the Unix spell(1) program. It has been around for
decades, probably the first spell checker program, late 70s. Feed it a text
file and it prints out a list of words not in its dictionary. That is the
entire user interface, OK at the time for a program that had to run on a
mutliuser machine with at most 512K RAM and text-only terminals.
Seems a bit primitive today, but still usable.
On my Linux box, it is not installed by default, but is available.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.