Localisation

That’s all, folks!

Virtual Team Project – Wrap-up

Our virtual project came to an end on Monday 25^th March with the delivery of our English instructions and their French translation. Let’s wrap this up with a look back at Team 2s.

The project

Team 2 had ten members at its disposal to create and translate up to 1,200 words of instructions to help a non-technical audience to carry out a simple task in an online tool. With all team members having to maintain a blog during the semester and after agreeing that WordPress is less than intuitive for first-time users, the team set out to write instructions for beginners who want to set up their first blog in WordPress.

Team communication

Aren’t ten people a bit much to write and translate 1,200 words? Probably, but the point of the project was virtual collaboration. Collaborating with nine other people is challenging no matter the project. this was evidenced by our inability to find a suitable time for a single live team meeting over eight weeks.

If we were working full-time on this project, I would have expected my teammates to find the time for a live online meeting. But, on top of being spread out over four time zones, we all had jobs, studies, and other commitments to juggle. So, I did not push the issue. We already had the WhatsApp chat for live, on-the-go communication. I did not want to risk alienating one of our team.

That being said, I recognise that a live meeting would have been beneficial to break the ice and adjust our communication styles. Body language can be misleading, but it provides cues faster than written or phone communication. Instead, like most of the team, I tried to share about myself little by little in my messages, for example about other on-going assignments, and I brought in some emojis, but only the standard ones (smiling, laughing, crying) in non-ambiguous situations to avoid misinterpretation.

Another advantage of live online or face-to-face meetings is that they speed up decision-making. Live meetings with an agenda greatly improve productivity and certainty: people engage to make binding decisions in a defined timeframe. Only smaller details may need adjusting later through email or chat. I learnt that collaborating mostly through an online chat is more time-consuming, especially in our specific setup (see above). Sometimes, I had to “chase” members to get their input on a group decision. Did they not care or were they genuinely busy? I found gauging situations in an online chat even more arduous than in emails.

In general, I tried to stay positive in all our communications. Everyone will encounter difficulties, make errors and become frustrated at some point during a project. I have always found that I need to take a step back to re-frame my frustrations in a positive light. Despite the sense of urgency I feel when using WhatsApp, I forced myself to wait before answering messages, to try to rephrase my messages and consider other points of view. I used to do this as project manager, but I have not had to practise it as much as a translator, so I had to pay particular attention to knee-jerk reactions.

I also tried to point out our team’s progress regularly, focussing on all we had achieved and how “little” was left. I hoped this sense of achievement would maintain a positive mindset. Other team members also used this strategy, so I assume it resonated with them.

Leadership

I have been working in virtual teams for about ten years now, as project manager and translator, so I may have been more prepared than other teammates. However, I think no one is ever really completely prepared because each experience depends on the other virtual collaborators involved and the context.

As a translation project manager, my projects did not use to require all team members (vendors, salespeople, and clients) to interact. All communications and decisions went through me. This experience was quite different. Here, we were all collaborating live on WhatsApp and Google Drive. In addition, despite a variety of backgrounds and expertise, I felt that we were all qualified to give our input on all aspects of the project because this was the first experience for all of us. So my role was closer to a moderator, starting discussions, offering suggestions and trying to reconcile everyone’s input.

We had very few disagreements, which we resolved through votes if there was no single correct solution. However, I wonder if this means we were all in agreement with my suggestions, or if my teammates either thought I knew better from my experience or chose not to make their own suggestions. Given our context, I could understand the latter option. I just hope it was not the first option as I made sure to explain my approach several times.

The process

Writing

The writing team decided on a combination of alone work and collaboration. Within one weekend, we had the first draft with input from the four writers. I was not expecting this strategy, but it worked well for us. Each writer was able to feed on available content and to add their own input while keeping their own style. No one had to dedicate more than a few hours of their busy schedule and the writers could compare styles and make informed decisions on the most appropriate one.

I see how this strategy could easily become messy in a large scale project if an official writing style has not been agreed yet. However, I find this strategy was an effective way to play around with writing styles and learn from others. Also, it made each writer into a researcher and tester who had to go through the previous writers’ inputs before starting. No, the content was not 100% accurate in the first draft, but close. So, I think this strategy was a good decision from our writers for this project.

Then, over the two following weeks, the writers edited various drafts and I asked the whole team, including the translators, to give feedback to the writers. Given the pressure on the team to have the English instructions ready in about two weeks, I thought that having everyone’s input would be beneficial for the writers. Other team members were helpful, including the translators who noticed some inaccuracies. However, after a few editing loops, we started stalling. In hindsight, I would rather the writers edited and proofed in isolation until the final draft was ready for testing and final quality review. The QA team would have had a fresh look unencumbered by pre-existing knowledge.

The translation process was quite smooth, at least from the English team’s point of view. One of the two translators acted as the main point of contact, and no questions or issues were pointed out in the English text. That is, there were small formatting issues that the translators corrected in the French, but they did not inform us despite our asking several times. Thankfully, it was nothing that our last proofreading would not have highlighted, but I am not sure what I would do to prevent this in future projects for non-obvious issues with a language unknown to me. I can only think of having a separate bilingual editor, one who has not worked on the translation.

This lack of communication during translation was disappointing because I explained to the translators how their input would be beneficial for the English text and for their teammates, and that non-translators would likely want to talk about translation in their blog posts. And one of the translators was active in our chats while we were writing the English text. I know this lack of teamwork is a common gripe among people working with translators, so I was disappointed that we did not lift the curse in our team despite communicating our expectations.

Finally, graphics localisation reminded me not to take my knowledge for granted. For me, it was obvious that localised graphics should look exactly like the source graphics and that graphics text should never be translated separately from the rest of the translation or using different resources. As both situations happened during the project, I realised that I had made assumptions based on my experience. I remember discussing the first issue during my translation degree and I know that non-translators may not be aware of the second issue. But this knowledge has become second nature and I forgot for a second that it is not universal. I will have to be more careful about this in the future.

The tools

Apart from Microsoft Word, we used three tools, Google Drive and Google Docs for storing and editing files, and WhatsApp for communication.

Google tools

Google Drive is a handy tool for sharing content. It took a second to master the sharing options. Other than that, I only have good things to say about it. The layout is clear, navigation is easy. We did not have any bugs. Google Drive kept its promise. Great!

Google Docs is another story. Overall, it is easy to use and intuitive, though I struggled to find some formatting options and it is not as rich as MS Word in terms of formatting. But the biggest issue is that it is prone to random formatting changes during editing and, if you implement formatting in Word and then open the Word file in Google Docs, some of the Word formattings will be corrupted and it will not be reinstated once you download again to Word. This means that once we implemented the final formatting on the instructions, we could not use Google Docs anymore.

Dropbox did not seem to have these issues for other teams. One Drive with Word 365 online might also be a good alternative if everyone can access it. I would be interested to collaborate either on Dropbox or One Drive to test whether they are efficient collaboration tools.

I never used WhatsApp professionally, so I was anxious about that. I always keep my personal content off my professional tools and emails, so I was uneasy having both personal and professional chats hanging out next to one another. Nothing to hide, but also no valid reason to have both in such close proximity. For one, in the moments where I decided to rest my mind from work or studying, I did not enjoy receiving this project’s notifications while I was talking to friends in another chat.

Another issue was that discussion and decision-making were very messy at the beginning. So much to decide! Do we keep all topics in one group chat or do create several chats for each topic? In a tool like Slack, I would definitely go the route of “1 topic = 1 chat”. In WhatsApp, we kept one chat and nobody even suggested splitting topics in different chats. I suspect mayhem would have ensued. Instead, in the same chat, I would start a topic with a long summary message and I would try to have one message per question so that other members could use the Reply message option to answer a specific topic/ question. Then I would summarise the decisions we agreed on.

The first ten days or so, I maintained chat minutes every day. This is when we had the longest discussions and I thought a summary of who proposed what and what decisions we took would be helpful. Members would not have to go through the whole chat thread then. I abandoned those minutes once our chats became shorter and focused on editing feedback. I kept using the long message structure, so anyone looking for new questions or decisions could look for these messages specifically to get a summary of discussions and decisions.

WhatsApp is not all bad. It allows for more informal communication and for resolving issues on the go. However, for me, it is not adapted to the professional follow-up of a project. I have never used a tool like Slack or Basecamp. Students in other teams used them and had good feedback about their usability and the learning curve, so I would like to try one of them in a future project.

Conclusion

Would I want to work in a virtual team again? It is very likely to happen given the nature of technical communication and the rise of remote work. Based on this experience alone, I have nothing against virtual teamwork in itself. Having worked in both virtual and face-to-face configurations, the main challenge really is the lack of cues that help to gauge a situation, like body language and tone. If you always work with the same team, this challenge fades progressively, especially with live online meetings. Otherwise, I find the configuration no less efficient than face-to-face teamwork as long as you have the right tools to facilitate collaboration.

The last stretch – the localisation review

Virtual Team Project – Week 8

No more experiments this week. The graphics designer created the French graphics while the translation team finalised the translation, then I reviewed the translation against the source English instructions.

The translation required very few edits, mostly small consistency edits in terminology and syntax, which are expected when two or more people collaborate on a translation. Even in a one-person translation team, typos and other issues are likely, especially after spending a long period of time on a project. Four weeks ago, I talked about how editing gets less efficient with each round of reviews. And even advanced spelling and grammar checker software will not spot some issues.

During my review, I noticed some localisations choices, but I also noticed small issues in the English that the French translators did not reproduce. For example, in one instance, the glossary definition of a term was inserted with the bookmarked term within the instructions. This must have happened after during the last review before I created the PDF because this insert is too obviously out of place to be missed during a review. And the French team did not reproduce this issue. Similarly, the bold formatting on some UI terms was missing in some English terms, but not in the French UI terms. Great for the translation, but we did ask the translators several times to inform us of such issues so that we could improve the English text.

I recognise that as translators, we spot a lot of small details or bigger issues in source texts, but I know that in many cases the translator feedback gets lost along the way back to the source writer. So, spending time on detailed feedback of typos, missing words, unclear sentences, etc., can be very frustrating. And sometimes, as happens with editing, the brain corrects an error without even registering the issue.

Still, we did ask the translators for feedback several times, so I was a bit annoyed. At least, there are no major edits in the English that would require extra work from the writing team. That’s a victory!

The translation is now ready and formatted. The translation team is letting it rest for a while before reviewing it one last time. Hopefully, we will be ready to deliver this weekend.

Next week: the final recap blog post…

Who should localise the graphics?

Virtual Team Project – Week 7

This week, the translation team worked away on the translation and the French graphics. They now have an almost final draft which requires some editing and formatting. However, my fears about the graphics have materialised.

When the translation team said they would take care of the French graphics, I was on the fence.

On one hand, they are in the best position to get the most accurate French screenshots, because they are accessing each screen during the translation. Also, they know both languages so they can easily match the French to the English, whereas our graphics designer is Irish and may not have the necessary level in French to do that matching work as quickly. I am sure he could do it, but it would take more time.

On the other hand, graphics design is another complex task that requires specific skills and tools. It’s one thing to dabble in Photoshop and to know how to edit photos and how to create simple drawings, it’s another thing to create elaborate graphics from screenshots and to be able to replicate the same process multiple times.

I had to create localised graphics as a project manager and maybe my more than inadequate skills in graphics design influence my opinion, but I think the graphics design skills should take precedence in graphics localisation. Give the designer the right screenshots and you should be fine. Give a non-designer the right design tools and I’m not sure you will get the right results. The non-designer might do great work, but it will be harder to recreate identical designs.

Nevertheless, the translation team showed a lot of confidence that they could take care of the graphics, so I decided not to push my preferences. This is one aspect of teamwork that might be the hardest to manage. Knowing when you should push back and impose a decision vs knowing when to take a step back and accept that other options might work just as well.

Today’s experience is timely. The person I interviewed for our interview assignment yesterday mentioned this as one of the biggest challenges of leading a team. In a team, everyone is an expert in an area and values their own input. One of the project manager’s jobs is to balance these egos, including his/her own. And I don’t mean “ego” in a negative, self-centered sense.

Our timeframe played a significant role in my decision. If we had to turn around the translation and the localised graphics within a few days only, I would have tried to impose the graphics designer option. However, this assignment is about honing our collaboration skills and trying new working strategies – and we had four weeks. Also, we agreed that the graphics designer would review the graphics and might intervene if necessary.

This weekend, the translation team shared their draft with localised graphics. The graphics are of high quality, with a good resolution and some interesting ideas, but they are very different from the source graphics. I had not anticipated this. It was obvious to me that the localised graphics should be identical to the source graphics (except for the text, obviously). However, the translators did their own thing here. I have never seen localised graphics that are completely different from the source graphics except when the available localised content is also completely different, which does not happen that much. I do wonder if that might happen more than what I have experienced…

This particular project is a valuable experiment in graphics design if only because it shows that different designers may come up with highly different graphics to showcase the same information, and all options may be valid. Still, with only one week left, we cannot spend more time experimenting. Other team members agreed that our graphics designer should take care of the localised graphics in order to ensure a consistent look across languages, and the translation team has provided him with the screenshots. We are now on the last stretch of this project and everything seems under control. We do not have any other “experiment” in progress, so I am cautiously confident.

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].