On Good Terms with Terminologists
By Barbara Inge Karsch and Jost Zetzsche
Translators have focused a lot recently on whether and how recent advances in machine translation are affecting their work. But it would seem helpful to take a big step back and examine one of the basics of our profession: terminology work. Jost, a working English>German translator and translation technology expert, approached Barbara, a well-respected terminology consultant and trainer, so they could work on mapping some of the differences and similarities in each other’s approach to terminology. Here is their conversation.
Jost: To me, it has always seemed that there is a significant difference between how terminology is handled by terminologists like you, Barbara, and translators, like me. Maybe this conversation can help reveal either that I am wrong and there are no differences, or, if there are differences, what they are and how they can be bridged. But first, I would like to hear more about what you mentioned to me in passing the other day: that one of the tangible results when working as a terminologist for a specific product (for instance, a software product) is to find out whether the product is inherently flawed. That has never occurred to me as something that results from the work of a terminologist. Can you explain in more detail?
Barbara: Thank you for the opportunity to talk about commonalities and differences between the terminology work that translators and terminologists do. That is an issue very dear to my heart. In fact, I have just taken on the project leadership of an ISO standard on translation-oriented terminology work (ISO 12616) precisely to help bridge that gap further. But let me address your other question about how a terminologist can tell how well a product is conceived.
Each product, whether it is a physical product, a software product, or an information product, consists of ideas. In terminology management, we call them concepts. Concepts are reflected in text through terms and names. So, when we as terminologists or translators research terms and names, we research the concepts at the root of a product.
To give you a concrete example, we used to navigate the computer screen via old-fashioned tools like the keyboard, mouse, or trackball. For a few years now, we have been able to navigate via what is referred to as a touchscreen. The term itself is what we refer to as transparent—you can derive information about the concept by looking at the term.
Let’s say the screen is named touchscreen, but the act of touching it does not have any effect. Then we know there is a problem either with the term or with the concept. If the problem is with the concept, you can conclude that there is a problem with the product, and not just at the linguistic level.
So, as we research a concept and its related concepts via documents and through our conversations with subject matter experts, we recognize how well conceived a product is both on the concept level and on the linguistic level. Make sense?
Jost: That makes it sound like terminologists should be team members of virtually every product development team. I assume that this is not the case. The few terminologists whom I know work in software-related companies. Would you say that there is a more pressing need for terminologists in companies that produce virtual products, or do these folks just have a better understanding of terminology? Or am I completely off-base in
assuming that there are more terminologists in those kinds of companies?
Barbara: The short answer is that there is a more pressing need for terminologists
in information technology environments. Given the right skills and circumstances (enough time, a receptive environment, etc.), many experts can create new concepts and
name them perfectly well. With the increasing speed to market, the rising volume of material, and the growing complexity of our processes, however, the linguistic skills of a technical expert or even content publishers are not valued as highly as other more technical skills.
But that gap upstream creates problems downstream. We can measure it in longer e-mail exchanges between employees to clarify understanding, in a higher volume of support calls due to terminology questions, and in a higher number of linguistic bugs in the translation process, to name a few.
You can also assume that a technical expert, lawyer, or marketing wiz is more expensive than a terminologist. And so you have terminologists picking up tasks that were done by the experts themselves in the past. In the information technology industry, true subject matter experts who can define the concepts of their field are very rare in my experience. So, you might find more terminologists there for that reason.
Another explanation for why there are more terminologists in software-related businesses is that the return on investment of doing terminology work with a centralized approach goes up tremendously when you translate into multiple languages and can reuse the terminology for multiple products and versions. This is true for a small product, but it is even more significant for projects in the million-word range with hundreds of translators working in over 100 languages, such as Windows. If each one of them would have to research, say, what a “speed bump” is, the product team would have thousands of e-mail messages or phone calls to answer. Instead, it was defined in the database as a new Windows 8 concept. Translators receive an exported file and have the terminology at their fingertips. You know how much money IBM saved by making terminology available directly in their authoring environment? $3,000 per information developer per year!
Now, let me go back to your remark about the difference between how translators and terminologists approach terminology work. Have you ever researched an English term to find the German term? Have you ever not found a German equivalent and had to create one yourself? Have you ever documented your research in a spreadsheet or maybe even a database?
Jost: Yes, yes, and sort of yes. If I am working in a team, I might add some comment on the term that I find (or send out a note to co-workers or project managers), but if I am working for myself, I have to admit that “documenting” would mostly consist of adding a target term to the source term. Of course, my translation environment tool adds some additional information automatically, such as date or project of origin. It is not that I cannot see the benefit of adding more information, but for me, it is also a matter of efficiency. If I spend 20 minutes or half an hour researching or coining a term, and I know I am typically not being (directly) paid for that, I would be hard-pressed to spend another 10 minutes documenting that term carefully. It is a different matter if I am working for the exceptional client who pays for that kind of work, or if I work for one of my long-term clients with an established and well-documented termbase.
Barbara: If we work correctly, we do the same things: we research terms or names and their underlying concepts, we might give them a name, and we document that information. The difference is that I hardly ever spend 10 minutes documenting my findings. The skills of documenting terminology data (terminography) are one aspect where I see a gap that we can easily close. It requires a bit of interest by translators and a bit of foresight, but it really is not rocket science.
But here we also have the tools aspect, about which I am sure you have something to say. There are certainly opportunities for tool providers. I was lucky enough to have facilitated the design of two terminology management systems. A usability engineer can make a big difference during the development phase and can drastically reduce documentation time for users later on.
Another difference is that a centralized terminology management system at a language services provider, a company, or an organization serves more than translation needs. It helps transfer knowledge, assure consistency, advance branding goals, and avoid copyright infringements or other legal violations. Because of all these objectives, it is important that the data in the database be correct. Accuracy is achieved by thorough analysis and then by documenting the results of this work in a terminological entry.
Let’s say I invest about 18 minutes on the research and two minutes on the documentation of a particular concept. I want that to serve as many of the purposes defined by the company as possible, and I do not want to touch that entry ever again. If I only documented the term and part of speech—no sources, no contexts, no usage notes, no term types, etc.—it would be impossible for a target terminologist to find the right equivalent. Moreover, if a target terminologist documented only the target term, someone would disagree eventually. And now you do not have information supporting your decision. If, on the other hand, you document the information that you get during your research anyway, mistakes can be avoided and other users know why a particular target term was chosen.
Jost: That sounds really great, but if I wanted to play the devil’s advocate, I would say that new terminology is often changed by the client’s in-country office—sometimes for good reasons and sometimes for seemingly no other reason than to establish authority. So there is potentially a good amount of effort with documenting going down the drain. On the other hand, I like your point that adequate documentation would indeed make it harder for clients to change terminology for no good reason.
Barbara: Ideally, the client or subsidiary is part of the terminology workflow. If they are interested, which they would be if they provide feedback after the fact, we would ask
them beforehand whether they would like to review the target terminology. Here is where the soft skills of a terminologist come in: negotiation and communication skills. They quickly need to loop in the right expert in their research (such as a subsidiary expert) in order to get the target term right from the get-go.
You are right, though, that terminology can become a power play. As in-house experts, we can often show the conflicting parties that, say, changing the German equivalent of fiscal year from Geschäftsjahr to Fiskaljahr in an enterprise resource planning product report costs several thousand dollars. If they cannot make better arguments than personal preference, that usually ends the discussion right there.
I do not see this as a conflict between the work of a translator and a terminologist. It is just that the circumstances, scenarios, or environments are different. But we are working along a spectrum where we have the ad-hoc, text-focused approach on one end, and a more systematic approach with longer-term and broader goals on the other. Depending on the goals, a translator or terminologist might work more on one end than the other.
Another aspect to consider is that because we want the reader to glean the main points of the entry quickly, terminologists follow terminographical standards and best practices. If we do that, we not only enable the human reader, but we also provide information in a machine-readable format. One obvious application is machine translation, but also spellcheckers, search engines, type-ahead functionality, etc.
Jost: Yes, things such as spell checkers, machine translation, or automatic typing suggestions do certainly match my needs, but all of these require only a source and target term. As a translator, I do actually value my terminology databases a lot—in fact, a lot more than any other resource, including translation memories. This is partly for some of the features mentioned above—as well as some other productivity and quality-enhancing features, such as automatic correction or insertion—but these are the very features that also lead me to enter content into my termbases that would not fall under the typical terminology definition. These would include very common expressions, fragments, or various words—often in different morphological states—that make me faster and better as a translator, but also blur the line between a terminology database and a glossary. This is partly my fault—I can see that I might benefit from adding more data—but it is also the technology’s fault.
Here is an example. If my tools were able to take the grammatical information that I enter to adjust morphological changes automatically and use it intelligently, I would definitely enter that information. If not, I will not waste my time entering it.
And I would even go a step further by saying that the very way that the terminology component in some tools is built and the lack of immediate applicability to the translation process (at least traditionally that has been the case) has “taught” generations of translators to not invest in terminology work. If tools are built for all of the complexities that terminologists need, but at the same time make it hard for the more hands-on processes that translators need, translators will not use them.
Now, I do think that we translators bear some of the responsibility for why the tool vendors did not build some of their tools more to our liking. We did not engage enough with vendors in the beginning. This, of course, comes down to the old ostrich model—if you hide from technology, then it definitely will not develop in a way that matches your interest. You need to engage to make sure that your interests are addressed.
Maybe a “compromise” could look something like this:
• if translators could unlearn some of the things that they always assumed about terminology processes and tools (like “building and maintaining full-fledged terminology
termbases is exceedingly difficult and is not something that can be expected of a freelance translator”) and start to engage more with technology vendors, and
• if tool vendors could provide for ever more applicable productivity features with their terminology components, and
• if terminologists could rethink some of the ways they communicate to translators about what is really important in documenting terminology and how that relates to productivity …
• ... maybe we would actually make some progress.
What do you think? Oh, and before you answer, maybe both translators and terminologists should combine forces to communicate to clients why terminology research needs to be paid more appropriately. And the argument could go like this: yes, we see the need to document our terminology, but since it is a need that goes beyond our present project, it needs to be billed separately as well.
Barbara: I believe that many of the problems that you are addressing regarding tools, even the fact that some translators are technology-averse, can be solved through better usability, including more natural language processing (NLP) capabilities. Terminology work is not data entry. The majority of time goes, or should go, into research, and my challenge to tool providers would be to facilitate fast data entry more rigorously and to integrate NLP when the source text terms and names are matched to the termbase. Then even those translators who have commonly switched off the termbase in the past because it slowed them down rather than sped them up would be ready to adjust their working methods, right?
I do think that a course in terminography would go a long way and increase documentation time, quality, reusability, and exchangeability of terminological data tremendously. An entry does not have to be elaborate. It should be as concise as possible, but it must contain the most pertinent aspects of the concept and term. This, too, takes experience or some education. And that can be acquired. By the way, it is part of many translation degree programs.
You also mentioned that you are documenting more than just technical terms. While the focus of technical standards and terminology education is on terms and their concepts, those of us serving a translation audience have always gone beyond that. In other words, we have documented slogans for marketing, legal expressions, or even boilerplate text, to name a few. As a freelance translator, you can take some liberty with the things that you want to document. In large-scale settings, straying from standards has proven to have an adverse effect. For example, if I document a word that by definition does not have a clear underlying concept, I cannot assign one target-language word to it that would serve all possible senses of the source word. So, it is counterproductive and confusing to translators. As a freelance translator, if you document a word, say, because
you are tired of typing it and just want to insert it automatically, nobody will stop you. Even better, if you marked it as such, it would be clear to other users with whom you might share your database sometime down the road. Incidentally, in the revised version of the ISO 12616 standard mentioned earlier, I would like to address these translation-oriented needs.
Your remark about terminologists rethinking how to communicate with translators is interesting. I look at translators as my customers in those circumstances where I cannot collaborate with them directly, and as my best friends in the environments where I can work with them. Many translators have a good understanding of the terminology process. If someone does not care about the details of the terminological entry and just wants to get a bilingual glossary, I am happy to provide that subset of data. But they have to understand that correct use of the data in the translation process is their responsibility.
As for payment, I would encourage all translators who work with clients who do not provide terminological data to insist on rates that allow them to do the work properly. After all, correct terminology is part of a translation deliverable. If you know that the customer might come back with the next release or need frequent updates, etc., it would definitely be worthwhile to make the argument that terms researched once and documented properly will enable future work through cost and time savings. The client should pay for that.
Jost: So, here is to translators becoming target terminologists!
Barbara Inge Karsch has been a terminologist for over 14 years, initially at J.D. Edwards and Microsoft. Now, as a consultant and trainer for BIK Terminology, she is assisting clients with terminology projects. She also teaches at New York University and KU Leuven at Antwerp, Belgium. She is a U.S. delegate to ISO Technical Committee 37 for Terminology and Other Language and Content Resources. She was recently appointed chair of ATA’s Terminology Committee. Her blog, BIK Terminology, focuses on terminology issues (http://bikterminology.com). Contact: firstname.lastname@example.org.
Jost Zetzsche is an English>German translator, a localization and translation consultant, and a widely published author on various aspects of translation. He writes the “GeekSpeak” column in The ATA Chronicle. His computer guide for translators, A Translator’s Tool Box for the 21st Century, is now in its 10th edition, and his technical newsletter for translators goes out to more than 10,000 translators. In 2012, Penguin published his co-authored Found in Translation, a book about translation and interpreting for the general public. Contact: email@example.com.