Three Tips to Internationalize Content

Last week, while I was talking to one of our teammates from the UK, this thought of writing for the international audiences drew my attention. I thought I should prepare a list of some generic points to consider while preparing content for international audiences. In this post, I share the that list with you. As a technical communicator, not often it is that I get to try my hands on localization (or internationalization, for that matter). Nevertheless, it is nice to know about the following points and put them to practice, whenever possible:

Culture-proof the references

This is by far the biggest cause of worry for the content writers. “He plays football” sounds a simple phrase to translate. But, as you know, more than one games share the spelling: The American football, the British football, and then there’s the Australian football. The English people wear black for formal parties and weddings. In contrast, it is not supposed to be good to wear black for weddings in India. As a communicator, if I come across any information that has a reference to a culture, I will like to either supply additional information or simply remove the reference.

I also make sure that I do not use any idioms, phrases, or initialisms that are specific to a location, culture, or race. For example: The Indians could have lost that match, had the other team not done a Devon Loch at the last minute. When you use idioms – like the one I used – you (or your translators) have to invest a lot of time searching for its equivalent counterpart in the language they are translating.

For those who don’t know, Devon Loch was a racehorse (Yes, racehorse is one word!) that collapsed just short of the winning line of one of the national horse races in the UK. That was in 1956, I suppose. So, you can use the idiom, only if you have the time and willingness to share the unnecessary background with the readers – assuming that your translator remains to be sane to translate it in multiple languages for you, multiple number of times.

Just for the fun of it, imagine translating the funnier idioms in the following sentences:

  • Today’s politicians are all talk and no trousers. (No imaginations, please!)
  • I’ve been a developer for donkey’s years. (Yes, trouble for you!)
  • Honesty will prevail in this world when pigs fly. (Seriously!)

There are also times when you generally refer to things from your own culture and expect others to know about it – unless you tell them about it. I’ve celebrated Ganesh Chaturthi ever since I was a child. But, to hear that this is a festival to celebrate the birth of the elephant-headed god was still weird for me. Still, the additional information helped my colleague explain our UK counterparts on what the festival was about.

Mind the Formatting

Formatting is one of the key aspects when it comes to comprehension. Translation can cost you the information if the formatting isn’t proper. During my stint as a freelancer, I’ve worked with a lot of clients who required translations from the English to the Hindi or Marathi language. And, in either of the cases, I faced issues especially with the alphabetical lists. Items marked until A, B, C, D, E, and F were fine, but anything beyond that became a little weird to read in Hindi and Marathi.

But, the comprehension is affected even when the language remains the same. For one of my clients, who, being from the US, used the MM-DD-YYYY date format, I had to get detailed clarifications for their date-based stamps that included one-digit dates. For example, 1-11-2016 is 11-JAN-2016 in the US, but 1-NOV-2016 in the UK. Not only is the date translation incorrect, but the difference is much as 10 months.

In some Indian languages, the bulleted list doesn’t exist in their legalese. So, whenever I’d receive scripts for translation, I’d double check for possibilities on using the numbered and unnumbered lists in their respective translated sections. It was time consuming, but definitely worth the time and effort. Speaking of the languages, some countries read right to left, like the Arabic or Urdu, or top to bottom, like the Mandarin. Are there any points that you consider when you localize, or if I may say, internationalize your content? I’d think considering placing screenshots in the middle of a page and using icons that aren’t specific to a gender, race, or ethnicity. But, I’m curious to know your opinion on it.

Error-proof your Data

The differences in the units of measurement are known to be fairly common ones. A 5’ is both five inches and five feet. In fact, this is so confusing that in some cases I’ve seen even 5” (a double quotation mark instead of a single quotation mark). Depending on the context of furniture designing, real estate, and even food – pizzas and cakes are measured in inches – the unit of measure will change. But, it isn’t as easy as it sounds. The standard unit of measurement for length in the US are Yard and Mile, while in the UK are Meters and Kilometers.

Then there’s also about the data integrity. If for a UK reader, I give data references like “the barren land is as big as the Lake of Utah, in the Utah state (UT, US)”, the reader will most likely either not understand it or completely misunderstand the estimate. Also, notice how states appear in the addresses in the US, such as the one we discussed. I cannot use the contracted form when I write the same information for the Indian audiences. For us in India, for example, the contractions UT and TN will never stand for the US states of Utah and Tennessee, but for the Indian state of Uttaranchal and Tamil Nadu.

Conclusion

I am a technical communicator, so I will only seldom get to try hands on localization and internationalization. But, in the limited amount of time and scope, I will find this list handy. Do you too have such a list? If yes, what are the points on your handy list?

Why Isn’t a “Help” Helpful Enough?

It is strange – and true – that technical communicators, like you and I, are into a profession that most others care a damn about… unless, of course, they are in dire need. No wonder most of the users yearn for the documentation only for troubleshooting their stuff. “I want to somehow get through this”, they intend. So, for the most part of their exploring the product, the users are busy finding answers to their how-does-this-damned-thing-works questions. Why is it still that we are unable to design formats that can make the users’ troubleshooting pursuits easy and manageable?

If I think about this whole thing as a user, it seems a daunting task for me to search for something I am not sure about; All I want is to solve my problem. But, how do I go about the help? How do I know where exactly to look for? How do I make sure to turn all the stones before I take a step further? How do I know how much information is sufficient? How, just how?

The users, I find as a technical communicator, use the following justifications for sending verbal curses to our so called “Help”:

  • Can I search for pictures? Does your help contain data/metadata to support searching for pictures?
  • I am lost. Where am I? What was I searching for? Is this what I was looking for?
  • I am tired. I’ll rather sleep.
  • I believe the reviews on the Internet provide more information than you can possibly cover in your next ten iterations. Sorry, I prefer the reviews.
  • I got the Internet; I will Google things up! I don’t need you.
  • I have other, better things to do.
  • I want a PDF. Do you take orders?
  • Is that a Help? Almighty, help me!
  • That many pages… are you kidding me!
  • The help only answers questions on information that is otherwise obvious and easy to locate and resolve. Why would I need answers to such simple things?
  • This help is outdated. Is there a new version?
  • This isn’t what I was looking for.
  • What I read partly solved my problem. What about the issues that remain? And, where can I find information about how to resolve those issues? Hello, are you listening?
  • Why aren’t there any graphics? Your writing sucks!
  • You call those graphics? I am better off with the written text.
  • You can’t expect me to read 20-odd pages just to look for a one-line information tidbit.
  • Your help does not contain the keywords that I am searching for. Why?

Sadly, this isn’t any one-person opinion. Most of them have equally creative, purposeful, and heartfelt verbal abuses for the help texts we share with them. Fact of the matter? The help isn’t helpful enough. Yes, it is true that a product is like a shrine with a thousand doors, and that the devotees can enter from anywhere. Yes, it is true that each devotee has a story to tell and a prayer that they want heard. And, Yes, it is true that it is close to impossible to predict the needs of each devotee. But, hey, isn’t that what we do every day as technical communicators? Just some food for thought.

Don’t Fix What Isn’t Broken!

We all learn. And, here’s the post on one such thing I learned, recently. For one of the projects I worked before I switched jobs last week, I was the only tech-comm contributor who held the dual role of preparing technical content as well as marketing collateral for the flagship product.

Until that time, I thought that technical writing made me be proud of one habit of pursuit: Perfection. I have grown, learned with time. And, I have gradually improved on my work and writing style. Consequently, I have developed this habit of looking for perfection in what I deliver, both in my work and in the blogs I publish.

The tasks required me to prepare the “usual” user and administration guides and then some customer-facing, enticing marketing collateral to increase the purchases of our products. I took up that dual role on the special requests from the content writing team lead, because I – being the sole writer for the thread – could explain the products’ core strengths.

Though there were a lot of things that I improved upon in the project, there were some that I had to leave untouched as I wrapped up. Friday was my last day at the office. I also had the other engagements at my home to look into before I joined my new company on Monday. So, I was hardly left with any energy and time to manage the tasks pending with me.

I knew – and still know – that had I tried harder, I could have managed a couple of additional edit iterations on the marketing collateral I prepared. I wanted to share only the perfect content with my then customers and colleagues, but I was short of time. Just one more write-up. One more edit iteration cycle; another better version. One more day. One more feature. One more document. One more inch toward perfection… just… one… more…

<Pause>

Please realize that I don’t WANT to commit mistakes – no one wants to. Also, I don’t think that I am perfect. But, knowing that fact does not – and cannot – stop me from TRYING to be perfect. And, here comes the wisdom: I AM WRONG.

Don’t try to fix what isn’t broken.

The truth is: One of the biggest challenges in technical communication is feedback. And, it is good to assume that even if the users provide feedback, it is only for what (they know or they think they know) is missing from your documentation. Assumptions are good. So, if they never get back to you, you can ASSUME that you are good to go. Like it or hate it, it has always been the way to go for technical communicators.

But, if that is true, then what is perfection?

Perfection is the state of being “all correct” in a situation, given a premise, under specific parameters, and at a certain point in time. Given that to be true – I can’t find a definition better than that – I think perfection is BAD. It stops you from progression. Progression toward a version better than you created. Perfection is status quo. And, I want to continue to flow. I want to continue to evolve.

Once upon a Time in Technical Writing

Stories are the commonest way the ethics, histories, information, insights, and knowledge have passed on to the younger generations. Through its multiple forms, storytelling focuses on building touch points to get messages across: Something that we too do as technical writers. I try to find the threads that storytelling shares with technical writing. And, here’s what I find as I try to delve.

Do you create video reviews on newer technologies, too?

Time and again I get to answer the question about what I do for a living. Yes, it does get irritating at times. But, mostly I love answering such questions. This time around, it was a marriage party and the questions were from the father of a curious teenager.

“So, I heard you are a writer!”

Is that a question? No, he knows that I am a writer. It’s just a rephrased form of “So, though I know that you write, I’m curious to know what [the hell] you do for a living?!” There still are traces of suspicion, amazement, and non-knowledge, which I liked. Tip: Never let the other person know that you know how it all starts.

I said I don’t just write. Just to be informative, we – in India – mentally associate writers as mostly boring, wage-less people who write because they cannot do anything better than that. So, I said, I don’t just write, I work as a technical writer.

I continued, “I prepare technical documentation for a software company. We, as a company, create software blah… blah… blah… and I get to create user manuals, troubleshooting guides, and the other *important* stuff, which is similar to the guides that you get when you purchase mobile phones.”

“Hmm… OK!” [Expected reply.] That’s a sign for you to continue. So, we talked for some more time before this happened…

“You see, my son keeps searching on YouTube… he mostly searches for [and watches] videos, spoofs, reviews, and funny stuff on technology… Do you do anything of that sort?”

Spoof? Well, No! Reviews? Still a No. Videos? Maybe! He probably intended to say “tutorial” for “spoof,” but alas there weren’t any translators available. Nevertheless. That’s another word to add to the list of what I DON’T do for a living.

Toward the end, I could give him a fair idea of what I do to earn a bread (and the other edible stuff). It turns out, he too wrote occasionally. No, not the way I do, but he wrote poems and diary entries. He wanted to start writing more intently and found “So, I heard you are a writer” to be the only way to crack a conversation about it. I totally respect that.

We kept talking for about half an hour; It was nice talking to him. Our streams of thoughts converged when he asked me about that “one *all-important* thing about my profession.” From where I can see, there is only one answer to this question: Curiosity.

Though we never really concluded the conversation, I got to know one thing toward the end: the curiosity of the curious teenager was very much visible in the eyes of the now curious father. He was content with my reply, it seemed. But, I think I saw a writer in the making.

Connect Those Pesky Dots

“For god sake, once, just once, connect those pesky dots. Can’t you see that I can’t understand anything? Even a word?” That’s what I often say when I look at bad write-ups. I just can’t connect those pesky dots to see what the story is. But, am I the only one who rubbishes write-ups that often? Don’t you too?

I think a write-up is bad because it doesn’t tell me anything. So, if it is poem, I am like “Uh!” and if it is a story, I’m like “So?” Write-ups that do not take either me or my learning from, for example, point A to point B are bad write-ups for me. I do not read poems. Not from all the writers. I am choosy, because not all writers do justice to their works. But, here’s one who I read quite often, and every time I see a new poem, I realize the poet wants me to step into her shoes and flow through the story she narrates.

But then there are those writers, who can beautify their words, and still fail to get the messages across. In contrast, I would love to read those writers who can break the ice, tell me a story, and make me smell the flowers as I read through their texts – just like the Juhi’s poems I just shared with you. Such writers, I believe, are a lot more effective. That’s because they have a message for me. Beautification is not a message. Beautification may be important, but not for me.

My take? Fiction, non-fiction, biographies, and poems: I see that the quality of write-ups (good or bad) depends on the flow of thoughts from the intentions to the messages. This flow is what can help us connect those pesky little dots. The message in the flow is about something that I either need to know or am interested to know about. And, as long as the writer can help usher me through the tides of the emotions, and still communicate the message and bring me (or my learning) from point A to point B, I’m good.

Plain, simple rules, aren’t they? Flow and message! But, why am I writing this to you? Why? Or, is it not something you already know? How many of us not write to rant out our pain? How many of us write for the fun and soul in writing? I am not sure. Not sure, because I know that writing isn’t always for a purpose. Not sure, because we know that we know the principles or the idea, and yet not follow it. Most of us don’t. But, I think I do. Do you?

The Next Big Thing: Workshop

Next month, I am conducting a couple of workshops at the STC India Annual Conference, in Pune. I like to talk about technical communication. And, at the conference, I’ll meet a lot of those would like to talk to me about this faculty of knowledge. Also, information design, as a topic, has always fascinated me. And, this time, I am conducting the workshops on the same topic.

In one of my recent interactions, with the Information Design batch at the National Institute of Design, we discussed some design principles. This is one of the reasons I chose to talk about information design at the annual conference. I see that a lot of new writers in our faculty of knowledge are turning toward information design. And, all this just makes me more curious about the topic.

I plan to keep the same flow of thoughts for both the workshops: I will make my point; then I will help you explore the topic; and then we all will draw conclusions on it. The first workshop is on the pre-conference day, and the second on 11 December. You can read more about the first and second workshop using the following links: Workshop#1 and Workshop#2.

The colleagues at my office too are excited about the workshops. In fact, some of them have asked me about how they too can attend the conference. In case you have not registered for the conference, do so quickly. Those of you who regularly follow me on the social network have asked me questions about the workshops. One such question is about a typical format of workshops. That is an interesting question. In fact, that’s how I began my research when I was invited to speak at the conference.

My research says that every workshop (and the speaker) is different. So, there cannot be a fixed format for workshops. However, I think there is one template that every speaker follows: First, make a point and describe it; second, create an exercise for the attendees; third, restate your point in light of the exercise to help your attendees connect the new insights with the thought you initially established; and in the end, leave your attendees with a thought.

But, there is one thing I would hate to do at my workshop: lecture about things. This is YOUR time as much as it is mine. To be a little too specific, you have two hours with me on the pre-conference day (that is 10 December), and 45 minutes on the day that follows (that is 11 December). Please remember that these are interactive workshops. So, the topics cannot steer ahead if YOU don’t participate.

At the workshops, I aim to talk about some intuitive design principles that can help map the need of the user with the benefits of your products/service. But, unlike what most of us think, these principles do not belong to information design. The principles are what I call the torchbearers, because they remain same no matter what faculty of knowledge I apply. This is enough now: I won’t spill the beans! Attend the workshops to know more.

Heuristics in Information Design: So that you get only what you need

Heuristics, unlike what most of us know, is not ONLY about the trial-and-error way of doing things. Heuristics are those basic guidelines that mostly cover the generic application of common sense. And, I don’t see a better faculty than technical communication to apply this technique. Here’s what I have to share.

Three Tips for Effective Localization

In this post, I take a closer look at the localization project in which my team and I assisted. I take cues from this project, and the similar ones that I have done previously, to discuss the top-three points for localization. This post is special to me, because it has helped me unfold those chapters of my life, which I had come to forget. If you are new to localization, this post will help you scratch its surface. If you already are into this field, I hope that the post will help add some new points to your localization plans. Click here to read the full post.

Trends in Technical Communication

In response to a reader’s question, I explore the impact of soft skills on the trends in technical communication. But, do the skills and trends have anything in common? Can the soft skills affect trends? If yes, how? Well, there are a lot of questions. And, I attempt to solve some of them in this post. Read the full post.