Where do we stop? When is a term not a term, or at least not a term we’re interested in documenting ourselves?
We often argue, for efficiency’s sake, that we must include terms that may seem “obvious” or “self-explanatory” in our source languages, but they cause ferocious problems in other languages without a standardized equivalent. Therefore, concepts with specialist meanings attached to them in an SAP context are considered terms and must include clear definitions and sources. The context information included with these entries is particularly important for translation.
For instance, seat appears in our travel management solutions for booking a place to sit on aircraft, trains, and so on. Although this is a common word its use in travel management needs to be defined. It could be misunderstood in other contexts as a synonym for “chair”, as shorthand for “county seat”, or in the legal senses of “company headquarters” or “licensed user”. Such homonyms must have their own definitions, context, and source information, of course, else they appear to be duplicate entries to the unwary.
There’s a limit to the broad-brush policy. Standard words with commonly-understood meanings and found in any dictionary are out.
- Days of the week (Monday), months of the year (January) – we’re not a calendar company
- Colors (red, vermillion, puce) – nor a paint company
- Normal actions and verbs (be) – nor lexicographers
- Terms not related to SAP products but used in marketing materials with customer participation
A good example of the last would be high-definition television and its abbreviation HDTV. Clearly not an SAP-relevant term because SAP doesn’t manufacture TVs. On the other hand, electronics manufacturers are interested in this term, and many electronics manufacturers use SAP products. Thus, a customer success story for one of these manufacturers or for the electronics manufacturing industry would use its terminology but at most we’d keep the terms in a project-specific file for future reference. We wouldn’t add these terms to our own term database as permanent entries.
Another special situation is jargon. Many standard terms and words used to be insider knowledge – very few of us knew what a blog was fifteen years ago and yet here we are, I’m writing one and you’re reading it. Every organization, branch of knowledge, and group has its own lingo. SAP is no different and at times its legendary “SAPanese” causes confusion until we can establish and explain the budding jargon as technical terminology applied to specific special purposes.
Yet we draw the line at designations used by colleagues in charge of our internal operations and corporate communications – sorry, can’t share examples here – and instead we suggest these be entered for internal reference in wikis (see, wiki is yet another “IT term made good” in the general vocabulary!)
It may seem porous. It is. It has to be.There’s no one-size-fits-all recommendation where we can say “no more; this isn’t a term”. One person’s bland word is another person’s term. We trust the experts on the front lines of terminology work to read our guidance and to make the final decisions.