Category: Technical Communication

On Interviewing

Here is a sample of our assignments in semester 2 with my first thoughts upon learning about them:

  • Design and develop an online learning resource – I should be fine as long as I can find an interesting topic.
  • Blog – This is not a surprise, but it is still anxiety-inducing.
  • Share and discuss industry insights on Twitter – See “Blog”.
  • Create an e-portfolio – 1. Great idea! 2. Oh! But then, there will be recruitment interviews. See “Blog”.

Amongst these personal challenges, interviewing an industry professional seemed like the easy part. This wasn’t my first time asking questions. Firstly, questions are part of the translator’s role. Also, I just handed in my summer development project proposal, which included a thorough interview with a subject-matter expert. So, why the struggle with this assignment?

Open and closed questions

Interview questions can be classified into several types: open, closed, primary, secondary, and mirroring. In her article “Open-Ended vs. Closed-Ended Questions in User Research” (Nielsen Norman Group), Susan Farrell defines open and closed questions:

“Open-ended questions are questions that allow someone to give a free-form answer.
Closed-ended questions can be answered with “Yes” or “No,” or they have a limited set of possible answers (such as: A, B, C, or All of the Above).”

Closed questions may yield more accurate answers; however, they might yield only the answers you expect. On the other hand, open questions give more freedom to the interviewee to stray from your expectations. Consider this example from the same article:

[Closed] “Do you think you would use this?”
[Open] “How would this fit into your work?”

In order to learn as much as possible when interviewing industry professionals, we should favour open questions, in particular as primary questions to introduce new topics. We should try to limit closed structures to secondary questioning, i.e. to get complementary information.

Old habits die hard

As a project manager, I asked open questions, for example to clients: “What are you looking to achieve with this project?” But mostly, I asked closed questions to get accurate information. As a translator, agencies recommend that I ask closed questions and that I favour multiple-choice questions to expedite the answering process for clients. Of course, this is not foolproof: receiving a “Yes” to an A, B or C multiple-choice question is incredibly common, slightly frustrating, but always funny. On the other side of that spectrum, occasionally, a client will go above and beyond and provide incredibly detailed context. I am forever thankful for these caring professionals.

When I interviewed the SME for my proposal, I used a mix of both closed and open questions, though a few of the closed questions implicitly required the SME to expand on his answers. Thankfully, this SME was a strong advocate in his field and he was willing to share as much as necessary.

I have never had an unwilling interviewee. This is a challenge: learning to prepare for the worst-case scenario. Over the last few days, I have reviewed my interviewee’s profile and made notes about potential questions as I went about other business. Then I sat down to tidy everything. You guessed it: most questions were closed-ended. I managed to improve my questions by referring to the sample ones that Madelyn Flammia provides in “The challenge of getting technical experts to talk” (1993), but I was not satisfied yet.

A double focus

Earlier this week, I shared on Twitter an Informaze article entitled “The power of deep interviews” by Iryna Sushko. Coming back to it later this week, the first two tips finally unblocked something in my brain:

“Tip #1 – Start with why?”
“Tip #1a – Why do you need this question?”

I need to get as much information from my interviewee. But why do I need that information? For this specific interview, my goal is to answer my personal questions and doubts. I have a double focus: the interviewee and myself.

To a greater extent, the issue is the same with each interview. Why am I doing this interview and spending time on it? Why do I need to create this content? These seem like obvious, fundamental questions. But it is so easy to get lost in the what (What questions do I ask? What content do I need?) and the how (How do I phrase this question? How do I structure my content?).  Keeping the “why?” in mind may also prove useful to motivate an unwilling interviewee, by showing him or her why his/her input matters.

Work faster

Each time I go back to my questions, I manage to improve them a little by asking myself why I want to know something. Now, I just need to learn to speed up that process, because I doubt that I will often have two weeks to prepare interviews.

References

Farrell, S. (2016) ‘Open-Ended vs. Closed-Ended Questions in User Research’, Nielsen Norman Group, 22 May, available: https://www.nngroup.com/articles/open-ended-questions/  [last access 17 February 2019].

Flammia, M. (1993) “The challenge of getting technical experts to talk: why interviewing skills are crucial to the technical communication curriculum”, IEEE Transactions on Professional Communication, 36(3), 124-129, available: https://doi.org/10.1109/47.238052.

Sushko, I. (2018) ‘The power of deep interviews’, Informaze, 12 September, available: https://informaze.wordpress.com/2018/09/12/the-power-of-deep-interviews/ [last access 17 February 2019].

.

Strings Authoring for Localisation

Talking about intercultural communication in class this week, we delved into several topics, including localisation and writing with an international audience in mind.

According to Bert Esselink (2003), localisation “revolves around combining language and technology to produce a product that can cross cultural and language barriers”. Though at first localisation applied mostly to software applications, today global web communication means that a great number of technical authors write for localisation. Localisation best practices are a broad topic, but this post focusses on some practical strings authoring advice from a translator’s point of view.

Internationalisation

The #1 best practice in localisation is to internationalise your product. This means you should ensure that your product and your content will enable localisation for your present and future markets. “Future” is key because all languages do not have the same requirements, and you should strive to “future-proof” your code and content from the start.

Internationalisation has technical and linguistic aspects. Technical aspects include ensuring your platform and code will support the specificities of each locale, including different character sets and orientations. Three pieces of advice here:

  • Prefer Unicode to maximise compatibility.
  • Do not hardcode text in graphics. Otherwise, you will need to extract the text for translation, and create new localised graphics. Different characters and right-to-left orientation will add extra work.
  • In doubt, check with a localisation specialist before authoring.

You can find more technical advice online, for example on web pages by Microsoft, Google Developers, Mozilla, and Oracle. As you can see on these pages, technical best practices are not enough to get your strings ready for localisation.

Authoring strings for localisation

As a translator, technical issues tend to be solved when I receive the strings, but linguistic issues may remain. Why should you care? After all, it is up to the translator to solve these issues. Yes, but:

  • The translator most likely translates the strings out of context in a computer-assisted translation (CAT) tool. He/she only sees the translatable text and the description keys/strings. More on that shortly.
  • If the translator misinterprets a string and introduces errors in the translation memory (TM), these errors will persist until a) you do the in-context review (best-case scenario) or b) a diligent user (the world?) gives you feedback.
  • If a translator sends you questions for each unclear strings, this translates into extra work and time lost for both of you – maybe extra cost as well.

Below I provide a few pieces of strings authoring advice based on the biggest pain points I have experienced as a translator.

#1 Rule: String descriptions are the best

Unfortunately, translators often localise user interfaces without any visual support. They may have access to the live website/app, but the international version may not be available yet. A demo version of the software may not be in the cards. Translators may have access to screenshots, but these do not display the whole content. There is a simple solution that is beneficial to all the users of the strings files – descriptions. In most strings files, you can insert a description key to clarify the translatable content that follows (button, menu item, alert, etc). This is very useful especially for very short strings. Consider these examples:

  • “Bookmark” and “Contact”: Buttons? Menu items?
  • “Empty”: Button? Message alerting you to an empty folder?
  • “Login”: Form field? Button? Yes, it should be “Login” (form field) and “Log in” (button). Without context, spelling mistakes can create confusion.

You can also insert a description string to clarify some items: what do the placeholders replace? If there are numerical variables, what is their numerical range? Etc. A description string is very helpful in case of length limits (see below). If you struggled to stay within a limit, the translators are likely to struggle as well. In case of a very short string, explain what the button, message or menu item does. It will help to find a shorter alternative.

Keep it short, but do not sacrifice clarity

Clarity is essential in technical communication, but even more so in web/software localisation because length constraints are frequent. Many languages need more space than English to express the same idea. For example, even if instructed to “keep it short”, languages like Latin languages, German, etc., can be up to 30-35% longer than English. Make every word count. This is especially true for menu items, app strings, and Google Ads. If there are absolute length limits:

  • Do not reach the limit in English. Plan for the 30-35% expansion rate. Of course, that may not be possible if the limit is 6 characters.
  • Avoid abbreviating. Abbreviating may not solve length issues in some languages. If available, choose an alternative that does not require abbreviating. If not available, provide a description string.
  • State the limits clearly as a number of characters. CAT tools can highlight strings that are over these limits.

Because of length limits, you may resort to complex noun clauses. Please don’t. If you can. What is a complex noun clause? In a complex noun clause, several words form a complex term without any clear functional link between each word. Typically, one word is the subject and the other words modify this subject. Consider these two examples from the Oracle Guidelines:

  • “Empty File” – Is the file empty? Is it a button to empty the file?
  • “Quantity Changes Impact Rate Master”. Do changes in quantity impact the rate master? Does the quantity change the impact rate master?

As the source of most translators’ questions, complex noun clauses are the best argument in favour of description strings. If you cannot avoid such clauses, clarify them.

List the strings in a logical, not alphabetical, order

Here is why you should avoid ordering strings by alphabetical order, and prefer a logical order by webpage, menu, section, type of string, etc.:

  • A logical order makes it easier to refer to a specific string in case of questions or updates.
  • Picture this: there are two “Empty” strings in the strings file. One is a button in Menu X, and the other is a message in Menu Y. You want to edit the message to clarify it, but both strings follow each other in alphabetical order and there is no clear description key. How long will it take you to identify the right string? And the translator?
  • Concatenated strings are unlikely to be displayed together in alphabetical order. Eg.: you split a sentence into String #1 and String #2. If you order the strings logically, String #2 will be directly after String #1, providing the translators with the right context. Alphabetical order makes this unlikely. Have dozens of concatenated strings and this becomes a puzzle.

On the topic of concatenated strings…

Avoid concatenating, and be careful with placeholders

When concatenating strings, you assume that grammar and syntax rules are the same in all languages. Mozilla provides a good example of concatenation issues and recommends using placeholders instead. This is invaluable advice, but it is not always enough because abusing placeholders and variables also causes grammatical issues. Consider this real-life example:

“Delivery is scheduled {0} {1} {2} from {3} at {4}”

There were no explanation regarding what {0}, {1} {2}, {3} and {4} meant. The author could not say for sure what each stood for. Searching the other strings, we solved the puzzle:

  • {0} stands for “every”
  • {1} is a numerical variable ≥ 1
  • {2} stands for “day(s)”, “week(s)” or “month(s)”
  • {3} is the start date
  • {4} is the delivery location

This works (somehow) in English, but it does not work in French, with or without concatenation. “Day” and “month” are masculine while “week” is feminine, and “every” has to agree in gender. Also, the numerical variable is not needed when it equals 1. For {3}, the proposition is “à partir de lundi 11 février”, but it is “à partir du 11 février”. Here is the French translation with text instead:

Every 1 day(s): “La livraison est programmée tous/toutes les 1 jour(s) à partir de {Date} à l’adresse {Address}”

To be grammatically correct, it should read:

“La livraison est programmée tous les jours à partir de {Date} à l’adresse {Address}”

To reduce the number of alternative strings, we end up with awkward English and localised strings. At least two variants of “{0} {1} {2}” are necessary in French, one for masculine and one for feminine (we could live with the unaesthetic “(s)”). Languages like Russian require even more variants because there are three possible declinations for “day(s)”, three more for “week(s)”, and another three for “month(s)”, depending on the preceding number.

Do not overdo it with placeholders. Limit the number of placeholders that contain variables. If you cannot, define with target linguists the number of variant strings you need to provide for localisation.

Conclusion

String authoring should abide by technical communication guidelines regarding clarity and cultural sensitivity. More than other content types, strings must be concise, but never at the expense of clarity. Though it may seem like a burden at first, providing descriptions and inserting variant strings to account for different writing rules will make strings management easier for you and your localisation teams.

References

Esselink, B. (2003) “The evolution of localisation”, Multilingual Computing and Technology, available: http://www.intercultural.urv.cat/media/upload/domain_317/arxius/Technology/Esselink_Evolution.pdf
[last access 10 February 2019].

Globalization Documentation (n.d.) Microsoft, available: https://docs.microsoft.com/en-us/globalization/
[last access 10 February 2019].

Internationalization (i18n) open source libraries and APIs (n.d.) Google Developers, available: https://developers.google.com/international/
[last access 10 February 2019].

Localization content best practices (n.d.) MDN Web docs, available: https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices#Avoid_concatenations_use_placeholders_instead
[last access 10 February 2019].

Understanding Translation Issues (n.d.) Oracle, available: https://docs.oracle.com/cd/E17984_01/doc.898/e14698/translation_issues.htm
[last access 10 February 2019].

When a picture is not worth 3,400 words

About that controversial cover of “M, le magazine du Monde”

In communication theory, noise refers to anything that might distort the message, like a bad connection, prejudices, misconceptions…

M, le magazine du Monde is a weekly magazine published by Le Monde, a reputable French newspaper. Its 29 December 2018 cover caused a stir on social media. The cover presents a side profile of French President Emmanuel Macron, jaw clenched and a stern look in his eyes. He is set on a white and red geometrical background. His costume represents the Champs-Élysées packed with people brandishing French flags and taking pictures. The cover title is barely legible. A literal translation could be: “From his inauguration to the “yellow vests”, the Macron presidency plays out on the Champs-Élysées.”

So, what is all the fuss about? Well, for many people in France – and other countries – the association of this exact side profile and a crowd of people raising one arm in the air is an obvious call back to Hitler’s ascent to power. Especially with the red, black and white colour scheme. Just look at the comparison tweet that is embedded in the article linked above. The image on the right is very recent: it is a 2017 Lincoln Agnew illustration for Harper’s magazine. But French readers will recognise each of its components from experience or from seeing them over and over again in school History books and documentaries.

To be fair, some on social media also identified a call back to communist propaganda with the use of the Russian constructivist imagery and colour scheme. Le Monde apologized, confirming the Russian constructivist angle of the cover.

What about the article then? Well, nobody really talked about the substance of the article on social media or elsewhere. I wanted to find out but New Year’s celebrations got in the way and the cover is what stayed with me. I suspect I might not be the only one.

Is the cover consistent with the article? You can read it if you have a subscription to Le Monde. In brief, the article details the important role that the Champs-Élysées avenue has played in Macron’s own ascent to power: his ties to the finance world, his inauguration parade, the Bastille Day parade that drew envy from Trump and was followed by the resignation of the Chief of the Defense staff, a police officer dying in a terrorist attack, the Les Bleus bus driving through the crowd after their 2018 Word Cup win, and the now famous “yellow vest” protests.

So, the article is somehow consistent with the cover title, but it is much more nuanced than the imagery and it can lead to various interpretations. Nevertheless, one can hardly imagine that the designers of this cover did not predict the controversy, the noise that it would create. Was the noise – or buzz – intentional? How many upset people bothered to read the article?

With the Web 2.0, anybody can communicate anything, and it is hard to stand out only on the merits of your message. Communicators need strategies to be heard: How should we package the message? Are all message components consistent? When should we broadcast our message? Should we look out for bad buzz or should we live by Oscar Wilde’s philosophy: “There is only one thing in the world worse than being talked about, and that is not being talked about.”