What is a term?

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.