BIK Terminology

Solving the terminology puzzle, one posting at a time

Archives for October 2010

To centralize or not to centralize—it’s not even a question

by

In May, I saw the announcement of a new research brief by Common Sense Advisory, which, according to its summary, would explain why companies are starting to centralize their language services. That made sense to me. In fact, it made me happy.

Not happy enough to cough up the money to purchase the study, I am afraid. But as people interested in terminology management, don’t you think that the following paragraph from the announcement sounds good? “Large organizations have begun consolidating their translation activities into internal service groups responsible for a broad range of language-related functions. This brief outlines the rationale behind and steps involved in enterprise language processing, including centralized operations, process re-engineering, automation, and content and metadata remediation.”

It sounds good, because anything else but a centralized service for prescriptive terminology management in an enterprise would be counterproductive. A centralized terminology database with a centralized service allows an entire company to contribute to and make use of the asset. According to Fred Lessing’s remar in an earlier posting, Daimler did a good job with this. Here is what they and companies, such as IBM and SAP, who have had a centralized service for years, if not decades, are getting out of it:

  • Standardization: If product teams reuse terms, it leads to consistent corporate language. Documenting a term once and reusing it a million times, helps getting a clear message out to the customer and sets a company off from its competitors.
  • Cost savings: The Gilbane Group puts it nicely in this presentation: “Ca-ching each time someone needs to touch the content.” It might cost $20 to set up one entry initially, but ten questions that didn’t need to be asked, might save $200 and a lot of aggravation. There are many terminology questions that come in for a major release. If I remember correctly, there were 8000 questions for a Windows Server release back when things hadn’t been centralized; many translators asked the same question or asked because they couldn’t access the database.
  • Skills recycling: That’s right. It takes “strange” skills to set up a correct and complete entry. A person who does it every now and then might not remember what the meaning of a data category field, forgets the workflow, or simply can’t understand the question by a translator. And yet, entries have to be set up quickly and reliably, otherwise we get the picture painted in this posting. A centralized team, who does it all the time, refines skills further and further, and again, saves time because no questions need to be asked later.

But all that glitters is not gold with centralization either. There are drawbacks, which a team of committed leaders should plan for:

  • Scale: Users, contributors and system owners all have to be on board. And that takes time and commitment, as the distance between people in the system may be large, both physically and philosophically. Evangelization efforts have to be planned.
  • Cost allocation: A centralized team might be in a group that doesn’t produce revenue. As a member of terminology teams, I have worked in customer support, content publishing, product teams, and the training and standardization organization. When I had a benchmarking conversation with the Daimler team in 2007, they were located in HR. The label of the organization doesn’t matter so much than whether the group receives funding for terminology work from those groups that do generate revenue. Or whether the leadership even just gets what the team is doing.

I believe that last point is what broke the camel’s back at Microsoft: Last week, the centralized terminologist team at Microsoft was dismantled. The terminologist in me is simply sad for all the work that we put in to build up a centralized terminology management service. The business person in me is mad for the waste of resources. And the human worries about four former colleagues who were let go, and the rest who were re-organized into other positions. Here is good luck to all of them!

SHARE THIS:

Jump List? Or what should we call it?

by

Giving a new concept a name in a source language often leads directly to the question of what to do with it in another language. This seems like a problem for target terminologists and translators, right? It isn’t. Marketing, branding and content publishing folks listen up!

We have just created a new term or appellation according to best practices from ISO 704. Now, what do we call it in the target language? What do we do with new designations, such as Azure or jump list? Well, the same best practices apply for target language terms as well. But there is a difference for terms and appellations.

Terms represent generic concepts. They are the parent concept or superordinate to other concepts. The concept called “operating system” in English has many different subordinate concepts, e.g. Windows, Linux, or Mac OS. Many times generic concepts have native-language equivalents in other languages. Of course, a particular language may borrow a term from another language, a direct loan. But that should be a deliberate term formation method and it is just one of them, as discussed in What I like about ISO 704.

An appellation represents an individual concept, one that is unique. Like you and me. And just as our parents gave us names that should represent us to the world—some very common and transparent, others peculiar or extraordinary—products get names that represent them to buyers. The criteria for good formation are weighted slightly differently than they are when used during new term formation: An appellation might be deliberately not transparent or consistent with the rest of the subject field. After all, it is a new product that is supposed to stand out. And it might be deliberately in another language.

Windows Azure™ is the appellation for “a cloud services operating system that serves as the development, service hosting and service management environment for the Windows Azure platform,” according to the official website. If we leave aside the trademark for a moment, nobody in their right mind would use the literal translations “Fenster ‘Azurblau’”, “Fenêtre bleu” or “Finestra azzurra”.

Once again, I find ISO 704 very helpful: “Technically, appellations are not translated but remain in their original language. However, an individual concept may have an appellation in different languages.” Good examples are international organizations which tend to have appellations in all languages of the member states, such as the European Union, die Europäische Union, or l’Union européenne.

ISO 704 goes on to say that “whether an individual concept has an appellation in more than one language depends on the following:

  • The language policy of a country;
  • How internationally well known the concept is;
  • The multilingual nature of the entity in question;
  • The need for international cooperation and relations.”

Based on this, it is pretty clear that an international organization would have an appellation in each of the languages of the member states. What about product names, such as Windows Azure? As terminologists for the target market, we should make recommendations in line with the above.

That is exactly what happened with a new feature for Windows 7, called Jump List in English. The message from the marketing department was that it was to remain in English even in the localized versions of Windows. But the problem wasn’t that simple.

There are actually two concepts hidden behind this name:

  • Jump List: The Windows feature that allows users to display jump lists.
    • A unique feature and therefore an individual concept.
    • An appellation.
  • jump list: A list associated with programs pinned to the taskbar or Start menu.
    • A generic concept that can happen multiple times even within one session
    • A technical term.
    • Erroneously capitalized in English.

Generally, when a new feature is introduced the feature gets a name and many times, the individual instances of the feature take on a term derived from the feature name. In this case, the feature was named Jump List and the instances were called Jump Lists. The later should not be uppercase and is in many instances not uppercase. But the two concepts were not differentiated, let alone defined up front.

So, when the German localizers got the instruction to keep the English term for all instances of the concept, they had a problem. They would have gotten away with leaving the appellation in English (e.g. Jump List-Funktion), but it would have been nearly impossible to get the meaning of the generic concept across or even just read the German text, had the term for the generic concept been the direct loan from the English. We could argue whether the literal translation Sprungliste represents the concept well to German users.

Naming is tricky, and those who name things must be very clear on what it is they are naming. Spelling is part of naming, and casing is part of spelling. Defining something upfront and then using it consistently supports clear communication and prevents errors in source and target texts.

SHARE THIS:

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:

BIK Terminology

From the Blog

Follow Me