BIK Terminology

Solving the terminology puzzle, one posting at a time

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:

Who has the last word?

by

In most cases, terminology research leads to one obvious target terminology solution. But sometimes there are several options and many people are involved. How then do you make a decision? Who is the final authority? When a new target term is coined or a controversial term needs to be changed, stakeholders become extremely passionate about these questions (see also a recent discussion in the inkedIn Terminology group).

I believe it is simply the wrong approach to this puzzle. Even just asking the question about authority does not help negotiations. Instead, let’s look at the process: The target terminologist does the research, because that is what they are trained and paid for. Research means accessing and evaluating pertinent resources to find the answer to the terminological problem. Resources may be print and online dictionaries, books and technical magazines, websites and terminology portals, the product itself, related products and material, and, yes, subject matter experts (SMEs).

Target terminologists are the hub in the middle of a bunch of experts. Sometimes they turn out to be self-proclaimed experts or people who are simply passionate about their native language. But especially in localization environments, a terminologist is a generalist and must never work in isolation. A good terminology management system (TMS) supports the terminologist by allowing knowledge sharing by others, voting, etc.

After doing the research, after consulting experts, after weighing each term candidate carefully, the answer should be apparent to the terminologist as well as to stakeholders. Here are some of the aspects that must be taken into consideration:

  • Linguistic presentation—is the new term a well-motivated term? Again, the DTT/DIT Best Practice contains a well-structured list of criteria.
  • Budgetary concerns—does changing from an old to a new term completely blow some product group’s budget and will they therefore not go for the new suggestion?
  • Input by end-users—when the term replaces an existing term: do end-users simply not understand the old term or have a strong dislike for it?
  • Sociolinguistic aspects—how rooted is the old term already in common parlance?
  • And finally, in certain environments, political aspects—e.g. are enough stakeholders convinced to make the change so that it will actually be successful?

It goes without saying that in each situation the criteria need to be weighted differently. For Windows Vista, for example, the German term for “to download” was changed from downloaden to herunterladen. The budgetary impact was high due to the high occurrence of the term in Microsoft material. Who had the final authority on that one? Well, a user survey conducted by the German terminologist at CeBIT in Hannover revealed that many users, even techies attending the computer fair, did not like the Anglicism. The German terminologist made the case to product groups, and the change was implemented by mutual agreement.

So, why do I say that the answer “should” be apparent? The most obvious reason is that, just like everyone else, terminologists are human and make mistakes—another good reason to not work in isolation. Apart from that, here are other aspects that I have observed impacting the negotiation process in today’s virtual world:

  • Culture, gender and hierarchy: At J.D. Edwards, some handbooks were translated multiple times into Japanese. Each time a more high-ranking person in the Japanese subsidiary had a complaint, the books or certain portions of them might be retranslated. Similarly, there was “terminology du jour”—terms that changed based on the input of the subsidiary and with little guidance by the female Japanese terminologist. Gender and hierarchy have an impact on terminological decisions in certain cultures.
  • Outsourcing: An external target terminologist isn’t necessarily in the strongest position. Many may not have contact with the local market subsidiary, because there is none or it is not staffed to discuss terminology. The worst case is, though, when the linguist makes a perfectly sound suggestion, but the counter-suggestion from the subsidiary prevails because it came from the client or the perceived expert. Subsidiary PMs may have strong technical knowledge, but that does not mean that they are always completely clear a) about the concept, b) about the impact of a term change, or even c) whether the term works for the end user. It is a terminologist’s job to assess how valuable the input of an expert is.
  • Expertise and experience: Let’s face it—some terminologists don’t deserve to be called terminologists. Terms are small, if not the smallest unit of knowledge, and terminologists need to deal with dozens of them on a daily basis. Experts usually don’t get paid or have no time for terminology work. Therefore, communication better be efficient and fast. It takes tremendous skill to make a concise case and get to a solution smoothly and efficiently.

In my experience, the best designations result from the work of a team of equals who draw on each others’ strength. In many software scenarios, the ultimate SME does not even exist—terminology-management and subject-matter expertise is contributed by different parties to an online centralized terminology database managed by the terminologist for the respective language.

What is your experience—do too many cooks spoil the terminology database? Or does it take a village?

SHARE THIS:

Abanyawoihwarrgahmarneganjginjeng

by

Does this look like a cat ran across a keyboard to you? This is how speakers of the indigenous Australian language Bininj Gun-wok say “I cooked the wrong meat for them again,” according to an article from The New Scientist.  While these linguistic units do not represent a concept that would come up in a localization environment and Bininj Gun-wok is not one of the languages into which products are localized frequently, if at all, this example shows perfectly well that languages have different ways to represent concepts. And we better not force the system of one language onto another.

The good thing is we don’t have to. Translators work through the concept. That means, they understand what a term, word or expression (e.g. “I cooked the wrong meat for them again”) means in the source language and then find the target-language equivalent (e.g. abanyawoihwarrgahmarneganjginjeng). Believe me–it takes a lot of analysis by a genius translator to turn a phrase into a perfect one-word equivalent!

While there are patterns on how languages represent concepts (e.g. noun-noun, adjective noun), there is no rule that says what is an adjective-noun combination in one language must be an adjective-noun combination in another.

Localizers often try to create target terms that stick close to the source language pattern, so that they can repeat it when more new terms are created in the source language. That is not a bad idea, as long as they don’t take a shortcut and fail to examine what the concept behind the term is.

A few years ago, the Japanese team working on the localization of a Windows product suggested that ‘compliance report’ be renamed in English. The content publishing team provided background information, but the localizers insisted that it be changed in the English material, because “it was hard to translate into Japanese.” The writers wanted to be good citizens and changed it to ‘status report,’ as the Japanese native speakers had suggested. Not only do ‘compliance’ and ‘status’ not represent the same idea, ‘compliance report’ came up again in another related product. When that product team was asked to change it to ‘status report’, they refused. After all it was correct and clear English.

While it is good practice to provide feedback on neoterms (newly created technical terms) that are culture-laden (e.g. breadcrumb bar) or product names that are to remain in the source language (e.g. Windows Vista), here are the consequences of the above scenario:

If writers, editors, PMs, source terminologists and others working in the source language give in to such pressures from the loc team, they are creating a synonym for a term that worked perfectly well and represented a concept uniquely. Another team that needs to communicate about the same concept will not even thing about looking at a good term, much less changing it. And what if the new term that now works for Japanese doesn’t work for Turkish, French, Danish, Ukrainian…. Instead:

  • Avoid synonyms when you can.
  • Solicit feedback from other product teams before you change a term.
  • Be clear in the source language; customers and translators will understand what you meant.
  • Document terms and concepts in a centralized terminology database.

For localizers or target terminologists it is important to remember that the product will be released in the target language, whether a source term sounds good or not; in other words “…doesn’t work for my language” doesn’t exist. That doesn’t mean that source terminology is always perfect. But product teams who get sidetracked on non-issues might not listen the next time there is a real globalization problem. Instead:

  • Focus on understanding concepts and finding clear target-language equivalents.
  • Spend time giving feedback on real errors or globalization issues.
  • And when researching terms, don’t take a shortcut–you would never come up with the perfect abanyawoihwarrgahmarneganjginjeng!
SHARE THIS:

BIK Terminology

From the Blog

Follow Me