24/03/2023

It’s Quality Time again. Welcome to a new episode in our series of expert interviews on quality in the broad field of language services. This time Eva-Maria Tillmann, head of quality management at oneword, talked to Mareike von der Stück from Schmeling + Consultants. A lively conversation about a number of issues including consistency as a decisive factor for text and translation quality – and the fact that thinking for yourself is just as important for compliance with standards as the content of the standard itself.

oneword is a full-service language service provider with a primary focus on translation and translation technologies. Since 2020, we have been in regular contact with the consultancy firm Schmeling + Consultants from Heidelberg with regard to standardisation in technical documentation and to share expertise. The company advises and audits technical writing teams and enables them to “efficiently produce high-quality technical documentation and to anchor methods, processes and knowledge in the organisation”.
Mareike von der Stück is Senior Consultant and Expert in Language & Technology at Schmeling + Consultants. She supports industrial, commercial and service companies in the standardisation and structuring of technical documentation and the use of editorial systems.

Eva-Maria Tillmann (oneword GmbH) and Mareike von der Stück (Schmeling + Consultants GmbH)

Eva-Maria Tillmann (EMT): Hello Mareike, I’ve been looking forward to this conversation for some time. The idea came to me after reading the interesting article you and Mr Schmeling wrote on the topic of consistency in the last issue of “technische kommunikation”. Can you briefly summarise for our readers what it’s about and why this topic is so important to you?

Mareike von der Stück (MvdS): I’d love to. And thank you, I’m also very much looking forward to our chat. This article deals with the concept of consistency as defined in Standard 82079 Part 1 as one of its fundamental principles – and how technical writers create consistent information in terms of content and presentation. Then it’s a question of the limits of consistency and whether it is really the standard’s most important principle. Or whether there might also be contradictions with other principles, so that there might be reasons to be inconsistent.

The topic is so important to me because I deal with standardisation and optimisation on a daily basis and consistency in presentation and content plays a very important part in achieving standardisation. The two go hand in hand: you can’t standardise anything if you don’t do it consistently.

“You can’t standardise anything if you don’t do it consistently.”

But I also find it interesting when you come across borderline cases in client projects where you ask yourself: do we enforce the consistency principle now or are there reasons for us to do things differently because our output we might then be more concise or comprehensible?

EMT: Can you give examples of meaningful inconsistencies?

MvdS: A good example is warning labels. Many technical writers are very clear on how a warning is regulated and what content it must have. According to the SAFE principle (only available in German), the warning needs to include information about the severity, the type and source, the consequences and avoidance, i.e. measures to avoid the danger.
However, the standard also says that you only need to warn the user about things that represent new information. So if it’s clear that you can burn yourself on a hot hob, I can simply point out the “hot hob”. In this case, however, I am no longer being consistent because I actually need to add “Danger of burns! Do not touch!”.

EMT: That makes sense. If the consequences are clear, there is no need to state them explicitly. This continues through to translation, i.e. whether a translator can understand everything correctly if consistency is dispensed with. I’m not just thinking about the completeness of warnings, but also of consistent terminology in a source text, for example.

MvdS: Yes, definitely. There must be no misunderstandings that could have serious consequences. In other words, not using synonyms that actually mean the same thing. Or not alternating indiscriminately between the long form and the short form.

EMT: Translation errors due to inconsistencies in the source text are cases where you can see that something has to be standardised, not because it is in the standard, but because it makes sense and has consequences.

MvdS: For sure. Consistency is not a goal because the standard says so, but a necessity in terms of comprehensibility and usability. We always have to look at two sides: on the creation side, it’s about whether a piece of information serves the people who create it, and on the reception side, it’s about how the readers and users who receive this information benefit from it. And users naturally benefit from consistent information because it is easier to understand.

“Consistency is not a goal because the standard says so, very often it’s a necessity.”

Because it is more understandable if I use the same terminology. Or even the same representation instead of having different list symbols, for example. Likewise, I always formulate requests for action and instructions actively: I don’t ring the changes by occasionally putting them in the passive voice such that the person I am addressing doesn’t realise that he or she has to act.

There is a benefit on the application side completely independently of whether the standard prescribes it or not. And on the creation side, I always have efficiency gains, especially when I use content management systems (CMS) and reuse text modules. If I’m consistent, it means I have a rule for how I do it – and if I work according to that rule, I’m always faster than if I am continually reinventing the wheel.

EMT: That makes sense! In the field of translation, we naturally want source texts to always be consistent. How can technical writers ensure this in editorial systems or even without using editorial systems? What are they doing to live up to what documentation standard 82079-1 prescribes?

MvdS: A key point is to look at what rules I need, at what level I need them and how detailed they need to be. That’s why we always start with an editorial guideline: one, sometimes very thick, document in which all the possibilities and impossibilities of linguistic standardisation for this one company and this one editorial department are exhausted and defined. On the conceptual side, we also use standards that already exist. For example, the standardisation method Funktionsdesign (functional design) or the tekom guide “Rule-based writing” (only available in German). In everyday editorial work, our customers also use so-called authoring assistance systems or language checking systems, which check the writing rules that have been agreed upon beforehand. These are good tools for consistent text production.

EMT: This is all very reminiscent of the tools and guides we use in translation.

MvdS: Yes, translation issues are also an important reason behind the decision to standardise source texts in order to produce standardised target texts.
What I always find tricky, however – and here I am interested to hear your assessment as an expert – is the question of whether a standardised source text in the source language automatically results in a standardised target text. Is that so?

EMT: Standardising the source text is definitely a huge advantage. That alone is why we wrote DIN 8579, in which the topic of consistency plays a prominent role. We notice from many queries, from feedback, and from the corrections in the customer review, that translators can misunderstand things if the source text is not consistent, or translate incorrectly if, for example, the same component has two different names. Such translation errors and the additional effort required to correct the text can be easily avoided by using a standardised source text.

What editorial guidelines are for writers and editors, style guidelines are for translators. Depending on the language, they contain different things to ensure consistency and standardisation. The same applies to terminology databases and translation memories: translators can use them to search for definitions and previous translations, because consistency must be ensured not only within a single document, but across several documents and sometimes across the years. Not infrequently also for a customer’s different departments and intended uses.

MvdS: Are there specific requirements for consistency and standardisation for translations as well?

EMT: Yes, absolutely. At least if the client specifies them. ISO 17100, for example, requires – even if clients do not explicitly say so – compliance with reference material provided and terminological and lexical consistency. The reference material may be a terminology database or, for example, a style guide. But if there is none, the translators will of course use the source text as a guide: what is consistent there can also be translated consistently. But with inconsistency in the source text, misunderstandings become more likely. So then the software manual may not match the interface that users are looking at, or perhaps a customer can’t find the tool shown in the flyer on the online store because it’s called something else there.

MvdS: What do you think are the biggest challenges in creating consistency in translation?

EMT: The challenge is actually a consistent source text. The source language document is not only there to be translated – someone also has to work with it. Someone who operates a machine with the original-language instructions needs consistent terms and names of parts, just like someone who works with the translation.

MvdS: That’s a good way of describing it. I’d like to get back to the style guides and the hope that what is standardised in the source language is also standardised in the target language. And what immediately comes to mind is requests for action, which in English could always be translated with an imperative like “push this button” and in German descriptively with “den Knopf drücken” or imperatively with “drücken Sie den Knopf”. How can we ensure here that consistent translations are always used if no style guide is provided?

EMT: Well, it’s rare for a client to provide one. It’s definitely the exception. This means that the translator is really in charge. That’s why we work with regular translators who know the company and the context. But they still have to do a lot of research in the translation memory and reference material. With a style guide, it’s much easier.

MvdS: And it’s definitely better to make sure the information is consistent up front than to look afterwards to see why something didn’t work. This also avoids the costs of revising the text.

EMT: Exactly. This also works smoothly if, for example, you have a brand-new system and have just produced a 400-page description of it. In this case it’s very likely that the translators will translate it consistently, because they don’t just change style or terminology part way through.

It becomes challenging when the source material comes from different points in time and there are only parts that still need to be translated – and when everything must also be consistent across several projects.

An important point is also optimum communication between the client and the translation service provider, so that linguistically standardised source information becomes linguistically standardised target information. For example, through guidelines and specifications in the briefing and through queries and feedback.

When creating a text, do your clients think about what they want from translations in terms of consistency, how they can deal with queries and how they can check translations and give feedback on consistency?

MvdS: In our standardisation projects, this topic is actually not that common. But of course it’s part of our expertise as a consulting firm – and an area that we advise clients on, for example in process analysis and optimisation.

EMT: ISO 17100 is often criticised for the fact that, in principle, it only holds service providers responsible for the provision of translation services – and clients very little if at all, for example, if they do not answer questions or do not provide reference materials. If this is the case, you can really only work to the best of your knowledge and belief.

This is why there is now also the as yet unpublished ISO 11669 standards project for translation projects, which is aimed at clients. It contains a lot of information for planning translation projects: what are the requirements, what are the risks and how to derive specifications for the translators. In other words, a lot of detailed answers to the question: what information do I need to give to the translation service provider so that my translations are no less efficient than the source documents I put so much work into?

MvdS: Then this standard fits in well. And the standard for translation-oriented writing is the interface, the ‘missing link’, which connects the standardised source information with the standardised target information in the best possible way. Here, the two sides of our world of source and target language come together beautifully.

EMT: The intention is also that technical writers create documentation with the documentation standard, optimise it with the standard for translation-oriented writing and identify the requirements for the translation with 11669 – and then, as soon as it goes into translation, we process it in accordance with 17100 or 18587.

MvdS: Let’s talk about the style guide again, because given what we have just said I think it’s even more important than before and editorial guidelines are also a constant issue for me. If you could wish for a style guide, Eva, what would it look like? What would its scope be and what things would it definitely contain?

EMT: It would definitely be short and shouldn’t make anything artificial. You say yourself that it’s difficult for writers and editors to remember all the rules. And translators don’t just work for one company, but often for several clients a week. So when they pull out a company’s latest style guide for an active job, they shouldn’t have to read 20 pages every time.

In addition, I would like the guide to only contain things that are really important for consistency or for certain spellings, i.e. things that prevent misunderstandings or risks when using the product. And of course everything that is important to the company, i.e. corporate guidelines on product names, for example.

MvdS: I’ve taken note. (laughs)

EMT: Wonderful. Now, finally, let me ask you a question in my turn: If you could have a message pop up on the start screen of all editorial systems that would be displayed to writers and editors every time, what would it be?

MvdS: There would be two different ones. Message 1 would be “Shoulders down!” because most of us knowledge workers are very tense when we sit at our desks. Message 2, the substantive one, would probably be something like “Think for yourself!”. Standards, style guides and editorial guidelines are very important tools, but they don’t completely take the place of your own thinking. And you need to be able to apply them correctly.

“Standards and guidelines don’t take the place of your own thinking. And you need to be able to apply them properly.”

EMT: I think that’s great, especially since the standards are structured in such a way that you really have to think about how you can and want to implement them.

MvdS: That’s why the people involved, who know their stuff and how to do the job, remain the most important factor in creation, translation and project management.

EMT: A great final sentence, Mareike. Many thanks. And thanks for such a great chat.