BIK Terminology

Solving the terminology puzzle, one posting at a time

ROI—The J.D. Edwards Data from 2001

by

Even after nine years, the terminology ROI data from J.D. Edwards is still being quoted in the industry. The data made a splash, because it was the only data available at the time. It isn’t always quoted accurately, though, and since it just came up at TKE in Dublin, let’s revisit what the J.D. Edwards team did back then.

J.D. Edwards VP of content publishing, Ben Martin, was invited to present at the TAMA conference in Antwerp in February 2001. His main focus was on single-source publishing. Ben invited yours truly to talk more about the details of the terminology management system as part of his presentation, and he also encouraged a little study that a small project team conducted.

Ben’s argument for single-sourcing was and is simple: Write it once, reuse it multiple times; translate it once, reuse the translated chunk multiple times.

At that time, the J.D. Edwards’ terminology team and project was in its infancy. In fact, the TMS was just about to go live, as the timeline presented in Antwerp shows.

For the ROI (return on investment) study, my colleagues compared the following data:

  • What does it cost to change one term throughout the J.D. Edwards software and documentation?
  • What does it cost to manage one concept/term?

27 different terms were changed in various languages, and the time it took was measured. Then, the average change time was multiplied by the average hourly translation cost, including overhead. In the J.D. Edwards setting, the average cost to change one term in one language turned out to be $1900.

The average time that it took to create one entry in the terminology database had already been measured. At that early time in the project, it cost $150 per terminological entry.

The cost to manage one entry seems high. Therefore, it is important to note that

  • There were three quality assurance steps in the flow of one entry for the source language English, and up to two steps in the flow of one entry for the target languages. So, the resulting entry was highly reliable, and change management was minimal.
  • The cost came down dramatically over the months, as terminologists and other terminology stakeholders became more proficient in the process, standards and tool.

Both figures are highly system/environment-dependent. In other words, if it is easy to find and replace a term in the documents, it will cost less. While these figures were first published years ago, they served as the benchmark in the industry and established an ROI model that has since been used and further developed and elaborated on. If you have any opinion, thoughts or can share other information, feel free to add a comment or send me an e-mail.

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:

What is a term?

by

A few years ago, my director at the time asked this seemingly innocent question. It isn’t a conundrum only to sponsors of terminology projects: Content publishers, localizers and other users of a terminology database are wondering as well. And while the more senior terminologists, who have heard this question before, may roll their eyes, it isn’t one that will go away. Since there is no one solution to this puzzle, it deserves some analysis.

The correct, yet to the director meaningless answer could have been “a verbal designation […] of a general concept […] in a specific subject field” (ISO 1087-1). Terminologists may be happy with a clear, concise definition – that’s what we are all about. But a director? Very likely he was looking for something else.

The form that question may take for a content publisher is: What term needs to be added to the terminology database to support the localization team? Even terminologists ask each other: Does this “thing” go in or not? And while localizers at the end of the workflow may be less selective–after all, they need answers, and they need them fast -, they, too, may wonder: Can I add this terminology question to the database or not? So, what the director and everyone else is interested in is the scope of a corporate terminology database; the range of stuff that is entitled to an entry; the definition of the corporate terminology.

ISO 704, for example, says “a terminology shall include lexical units that are adequately defined in general language dictionaries only when these lexical units are used to designate concepts that form part of the concept system.” Definition by exclusion–that is not a bad start.

Let’s assume that a software company doesn’t publish poetry or fiction. Rather just about anything that comes up in the company material, e.g. user interface, documentation, websites, etc., is technical language, and many of the lexical units used are technical terms. Almost all of the technical terms that could be excluded according to the above recommendation from ISO 704 are needed to clarify relationships to other lexical units. Or to standardize target-language equivalents. Or to clarify meaning. So, while defining the scope by excluding things, we need to look further.

In terminology work, three types of designations are distinguished: symbols, appellations and terms (ISO 1087-1). A well-known symbol, at least back when localization was first taught, was the mailbox. (It was used often in localization classes, because it was highly culture-specific and had little meaning for many people outside the United States; in many applications, it has been replaced by the icon of an envelope since). A good example for an appellation is the name of an organization (e.g. Financial Accounting Standards Board (FASB)) or country (e.g. Serbia). Appellations designate or stand for individual concepts, things that exist just once in the world. Terms, on the other hand, represent general concepts, e.g. beer bottle or virtualization).

If all corporate language is technical language and many of the designators would qualify for an entry in a terminology database, which terms, symbols or appellations should not be included? What tends to be excluded are:

  • Symbols (e.g. icons)
  • Longer text (e.g. error messages)
  • Fictitious names (e.g. company names used as examples in demo data)
  • Examples (e.g. example data used to explain the functionality in an ERP application)

Often, there are other databases that house, categorize and standardize symbols and even fictitious names. Otherwise, they could be included in a terminology database as well. Longer text units and examples simply don’t have a good return on investment: Error messages, boilerplate texts, etc. don’t need to be defined and are better stored in translation memories; examples may be very culture-specific and might need to be adjusted or are not worthwhile defining and standardizing in a database.

So, include anything with a return on investment and exclude what is stored elsewhere or doesn’t pay off. Pragmatic guidelines like these will at least keep a team of terminologists aligned. Do we need a more concrete rule in addition? Not in my opinion. There are other questions that need to be asked, but they are for another time.

SHARE THIS:

BIK Terminology

From the Blog

Follow Me