BIK Terminology

Solving the terminology puzzle, one posting at a time

Why doublettes are bad

by

One of the main reasons of having a concept-oriented terminology database is that we can set up one definition to represent the concept and can then attach all its designations, including all equivalents in the target language. It helps save cost, drive standardization and increase usability. Doublettes offset these benefits.

The below diagrams are simplifications, of course, but they explain visually why concept orientation is necessary when you are dealing with more than one language in a database. To explain it briefly: once the concept is established through a definition and other concept-related metadata, source and target designators can be researched and documented. Sometimes this research will result in multiple target equivalents when there was only one source designator; sometimes it is just the opposite, where, say, the source languages uses a long and a short form, but the target language only has a long form.

If you had doublettes in your database it not only means that the concept research happened twice and, to a certain level, unsuccessfully. But it also means that designators have to be researched twice and their respective metadata has to be documented twice. The more languages there are, the more expensive that becomes. Rather than having, say, a German terminologist research the concept denoted by automated teller machine, ATM and electronic cash machine, cash machine, etc. two or more times, research takes place once and the German equivalent Bankautomat is attached as equivalent potentially as equivalent for all English synonyms.

Doublettes also make it more difficult to work towards standardized terminology. When you set up a terminological entry including the metadata to guide the consumer of the terminological data in usage, standardization happens even if there are multiple synonyms. Because they are all in one record, the user has, e.g. usage, product, or version information to choose the applicable term for their context. But it is also harder to use, because the reader has to compare two entries to find the guidance.

And lastly, if that information is in two records, it might be harder to discover. Depending on the search functionality, the designator and the language of the designator, the doublettes might display in one search. But chances are that only one is found and taken for the only record on the concept. With increasing data volumes more doublettes will happen, but retrievability is a critical part of usability. And without usability, standardization is even less likely and even more money was wasted.

SHARE THIS:

What do we do with terms?

by

We collect or extract terms. We research their underlying concepts. We document terms, and approve or fail them. We might research their target language equivalents. We distribute them and their terminological entries. We use them. Whatever you do with terms, don’t translate them.

A few years ago, Maria Theresa Cabré rightly criticized Microsoft Terminology Studio when a colleague showed it at a conference, because the UI tab for target language entries said “Term Translations.” And if you talk to Klaus-Dirk Schmitz about translating terminology, you will for sure be set straight. I am absolutely with my respected colleagues.

If we translate terms, why don’t we pay $.15 per term, as we do for translation work? At TKE in Dublin, Kara Warburton quoted a study conducted by Guy Champagne Inc. for the Canadian government in 2004. They found that between 4 and 6% of the words in a text need to be researched; on average, it takes about 20 min to research a term. That is why we can’t pay USD .15 per term.

Note also that we pay USD .15 per word and not per term. Terms are the signs that express the most complex ideas (concepts) in our technical documents. They carry a lot more meaning than the lexical units called words that connect them.

Let’s assume we are a buyer of translation and terminology services. Here is what we can expect:

  Translation Terminology work
Number of units a person can generally process per day Ca. 2000 per day Ca. 20 to 50 entries
Cost for the company Ca. USD .25 per word Ca. USD 55 per hour

At the end of the translation process, we have a translated text which in this form can only be used once. Of course, it might become part of a translation memory (TM) and be reused. But reuse can only happen, if the second product using the TM serves the same readership; if the purpose of the text is the same; if someone analyses the new source text with the correct TM, etc. And even then, it would be a good idea to proofread the outcome thoroughly.

The terminological entry, on the other hand, should be set up to serve the present purpose (e.g. support a translator during the translation of a particular project). But it might also be set up to allow a support engineer in a branch office to look up the definition of the target equivalent. Or it might enable a technical writer in another product unit to check on the correct and standardized spelling of the source term.

I am not sure that this distinction is clear to all translators who sell terminology services. You might get away with translating terms a few times. But eventually your client’s customers will indicate that there is something wrong, that the product is hard to understand or operate because it is not in their vernacular.

There are much more scientific reasons why we should not confuse translation and terminology work; while related and often (but not always) coincidental, these tasks have different objectives. More about that some other time. Today, let me appeal to you whose job it is to support clear and precise communication to reserve the verb “to translate” for the transfer of “textual substance in one language to create textual substance in another language” as Juan Sager puts it in the Routledge Encyclopedia of Translation Studies. If we can be precise in talking about our own field, we should do so.

SHARE THIS:

How do I identify a term—standardization

by

And the final criterion in this blog series on how to identify terms is, in my mind, one of the most important ones—standardization. Standardized usage and spelling makes the life of the product user much easier, and it is fairly clear which key concepts need to be documented in a terminology database for that reason. But are they the same for target terms? And if not, how would we know what must be standardized for, say, Japanese? We don’t—that’s when we rely on process and tools.

Example 1. Before we got to standardizing terminology at J.D. Edwards (JDE), purchase orders could be pushed, committed or sent. And it all meant the same thing. That had several obvious consequences:

  • Loss of productivity by customers: They had to research documentation to find out what would happen if they clicked Push on one form, Send on another or Commit on the third.
  • Loss of productivity by translators: They walked across the hall, which fortunately was possible, to enquire about the difference.
  • Inconsistency in target languages: If some translators did not think that these three terms could stand for the same thing (why would they?), they replicated the inconsistency in their language.
  • Translation memory: Push purchase order, Commit purchase order and Send purchase order needed to be translated three times by 21 languages before the translation memory kicked in.

All this results in direct and indirect cost.

Example 2. The VP of content publishing and translation at JDE used the following example to point out that terms and concepts should not be used at will: reporting code, system code, application, product, module, and product code. While everyone in Accounting had some sort of meaning in their head, the concepts behind them were initially not clearly defined. For example, does a product consist of modules? Or does an application consist of systems? Is a reporting code part of a module or a subunit of a product code? And when a customer buys an application is it the same as a product? So, what happens if Accounting isn’t clear what exactly the customer is buying…

Example 3. Standardization to achieve consistency in the source language is self-evident. But what about the target side? Of course, we would want a team of ten localizers working on different parts of the same product to use the same terminology. One of the most difficult languages to standardize is Japanese. My former colleague and Japanese terminologist at JDE, Demi, explained it as follows:

For Japanese, “[…] we have three writing systems:

  • Chinese characters […]
  • Hiragana […]
  • Katakana […].

We often mix Roman alphabet in our writing system too. […]how to mix the three characters, Chinese, Katakana, Hiragana, plus Roman alphabet, is up to each [person’s] discretion! For translation, it causes a problem of course. We need to come up with a certain agreements and rules.”

The standards and rules that Demi referred should be reflected in standardized entries in a terminology database and available at the localizers’ fingertips. Now, the tricky part is that, for Japanese, terms representing different concepts than those selected during upfront term selection may need to be standardized. In this case, it is vital that the terminology management system allow requests for entries from downstream contributors, such as the Japanese terminologist or the Japanese localizers. The requests may not make sense to a source terminologist at first glance, so a justification comment speeds up processing of the request.

To sum up this series on how to identify terms for inclusion in a terminology database: We discussed nine criteria: terminologization, specialization, confusability, frequency, distribution, novelty, visibility, system and standardization. Each one of them weighs differently for each term candidate and most of the time several criteria apply. A terminologist, content publisher or translator has to weight these criteria and make a decision quickly. No two people will come up with the same list upfront. But tools and processes should support downstream requests.

SHARE THIS:

BIK Terminology

From the Blog

Follow Me