BIK Terminology

Solving the terminology puzzle, one posting at a time

You say Aaaazure, I say Azuuuure…

by

Two years after the then new cloud-computing technology by Microsoft was named Windows Azure, Microsoft employees and partners are still wondering how to pronounce the name. Is that a good thing for product branding? Probably not.

Naming is a big part of terminology management. In her presentation for the last DTT symposium, Beate Früh, language service manager at Geberit International AG, a European producer of sanitary technology, described very well how she and her team support engineers in finding the right names, terms or labels for new products or parts (for examples see the adjacent image or the slide deck in German). One of the keys: The team comes in early in the process to help engineers find the best possible terms.

What are best possible terms or appellations? Obviously, each language has its own rules on term formation, as discussed in What I like about ISO 704. But here are the main criteria as well as a checklist that good terminology should meet, again courtesy of ISO 704:

  • Transparency: Can the reader understand what the concept is about by looking at the term?
  • Consistency: Is the new term or appellation consistent with the naming in the subject field? Or does it introduce new aspects at least very deliberately or only when necessary?
  • Appropriateness: Are the connotations evoked by the designation intentional? And do they follow “established patterns of meaning within the language community?”
  • Linguistic economy: Is the term or appellation as short as possible, so as to avoid arbitrary abbreviations by users?
  • Derivability and compoundability: Is it easy to form other terms, e.g. compounds, with the new term?
  • Linguistic correctness: Does the new designation conform to morphological, morphosyntactic, and phonological norms of the language?
  • Preference for native language: Is the new term or appellation borrowed from another language? Or could it be replaced by a native-language designation?

Why would it take a terminologist to name things correctly? In the software industry, we used to say that programmers became programmers because they wanted to deal with 0s and 1s, not with words and terms. Similarly, product engineers are probably better with designing, developing, or testing devices rather than naming them. What’s more, they don’t necessarily think about what happens downstream, let alone set up entries in a terminology database.

Participants of the Life Science Roundtable at LocWorld yesterday in Seattle illustrated the necessity to deliberately choose terms and appellations early in the process, document them as well as their target-language equivalents and then use them consistently: After a device has gone through the regulatory process, even linguistic changes are extremely difficult, if not impossible to make. Tough luck then if a name doesn’t work very well in one or more of the other 25 target markets.

At Microsoft, most product names are run through a process called a globalization review. Marketing experts work with native-language terminologists on evaluating whether the above criteria are met. Some names obviously don’t get submitted. So, Aaaazure, Azzzzure…let’s call the whole thing off? No. But since I am now married to an “Azure evangelist”, I hope that the concept behind the appellation is really solid and makes up for the trouble we have with its pronunciation.

SHARE THIS:

Terms—A translator’s perspective vs. a terminologist’s perspective

by

Any translator can do a terminologist’s work. The best translators compile lists of terms, equivalents, maybe a piece of context or even a definition before or at least while they are translating. So, theoretically the above statement is correct. But let’s take another look at the focus of a translator and the focus of a terminologist with regard to terms.

Although a term can be at the same time a unit of translation and a term described and defined in a terminology database, translators and terminologists treat that unit differently. A translator works in context and arrives at a target solution that is correct for that particular text. Based on Saussure, Juan Sager calls terms in a translation text “instances of parole” or “language in use” (Routledge Encyclopedia of Translation Studies).

In Quasi dasselbe mit anderen Worten, Umberto Eco says “in light of [all the] meanings made available by a dictionary entry and its applicable encyclopedic information, the translator must choose the most probable, reasonable and relevant sense for the context in question and this possible world” (translation by BIK). That means that the translator cannot simply copy what he finds in a dictionary or terminology database; he actually has to be, as Robin Bonthrone put it years ago, “switched on.” If that wasn’t a condition, machine translation would have long since taken over.

That context then becomes part of the translated text, which in our scenario of technical translation, usually becomes part of a translation memory (TM). And it also becomes part of a product. As part of the product, the term is now part of history, as it were. As part of the TM, the term may be reused for the next version of the product, and it may also serve as reference material to others. But a translation memory does not equate to managed terminology. Strings in TMs contain terminology, but TMs are generally static and hardly ever managed.

In applied terminology, the starting point might be the term in the translation environment above. But a terminologist must research and understand the term not only in one particular context, but in as many as it takes to uniquely identify its meaning. Once that meaning has been identified, the terminologist creates a terminological entry. According to Sager, terminologists use the term, the “instance of parole”, to get to langue, i.e. the abstract system behind the linguistic sign. The entry is part of the terminological system in the database and can now be applied back in parole, in more than one situation or context, to more than one product or company. Therefore, it must be comprehensible to people other than the terminologist, and it must reflect the understanding and knowledge of the subject matter expert (see also Terminology by Maria Theresa Cabré).

While both translators and terminologists research terms, the product of their work is different. The translator is responsible for the delivery of a correct target language text with correct technical terms (parole or language in use). The terminologist is responsible for the creation of a correct and complete terminological entry in a database (langue or the abstract system underlying speech acts). That entry may over time be used for many different products and versions inside or outside the company; the entry may become obsolete or even incorrect and the terminologist may need to modify it or add a new entry to the database accordingly. Monetary compensation, as described in What do we do with terms? method and goal of translators and terminologists are different. Therefore, translators translate, terminologists research and document.

[This posting is based on an article published in the Journal of Internationalisation and Localisation, which can be downloaded for free.]

SHARE THIS:

Quantity AND Quality

by

In If quantity matters, what about quality? I promised to shed some light on how to achieve quantity without skimping on quality. In knowledge management, it boils down to solid processes supported by reliable and appropriate tools and executed by skilled people. Let me drill down on some aspects of setting up processes and tools to support quantity and quality.

If you cannot afford to build up an encyclopedia for your company (and who can?), select metadata carefully. The number and types of data categories (DCs), as discussed in The Year of Standards, can make a big difference. That is not to say use less. Use the right ones for your environment.

Along those lines, hide data categories or values where they don’t make sense. For example, don’t display Grammatical Gender when Language=English; invariably a terminologist will accidentally select a gender, and if only a few users wonder why that is or note the error, but can’t find a way to alert you to it, too much time is wasted. Similarly, hide Grammatical Number, when the Part of Speech=Verb, and so on.

Plan dependent data, such as product and version, carefully. For example, if versions for all your products are numbered the same way (e.g. 1, 2, 3,..), it might be easiest to have two related tables. If most of your versions have very different version names, you could have one table that lists product and version together (e.g. Windows 95, Windows 2000, Windows XP, …); it makes information retrievable slightly simpler especially for non-expert users. Or maybe you cannot afford or don’t need to manage down to the version level because you are in a highly dynamic environment.

Enforce mandatory data when a terminologist releases (approves or fails) an entry. If you  decided that five out of your ten DCs are mandatory, let the tool help terminologists by not letting them get away with a shortcut or an oversight.

It is obviously not an easy task to anticipate what you need in your environment. But well-designed tools and processes support high quality AND quantity and therefore boost your return on investment.

On a personal note, Anton is exhausted with anticipation of our big upcoming event: He will be the ring bearer in our wedding this weekend.

SHARE THIS:

BIK Terminology

From the Blog

Follow Me