How to Deal With Disparate Holiday Schedules Across Continents

Yesterday was a holiday here in the U.S. (Thanksgiving), and many people make a long weekend of it, hosting friends or family or visiting them. In Europe, however, where most of my clients are located, it was a regular workday, as is today. As a result, e-mails responding to my latest marketing effort and/or offering translation projects kept arriving while I was preparing for out-of-town guests and an elaborate dinner for 8+. That's the downside of working across borders, I guess.

While some holidays are pretty much standard across countries and cultures (New Years, for example), many are not. In addition, the earlier timezone in Central Europe means that e-mails from Germany, Austria, England, etc. have already poured in before I even get out of bed at 7 a.m. my time. One possible answer to this situation would be to limit my working hours -- and thus the hours during which I respond to e-mails -- to the standard work day in New York City, where I live. That would, however, likely cost me a number of projects, if not clients.

So instead I rely on technology to let me deal with business during off-hours in New York. Business e-mail is routed to my smartphone (in addition to MS Outlook on my desktop computer), and I can even write short MS Office documents (Word, Excel) on my phone. That means I can answer e-mails while setting up breakfast for my family or cooking dinner for guests. If the e-mail requires additional research or information I can at least respond that this is a holiday and that I'll reply more fully by a specific time or date.

Had we driven to visit my daughter and her husband in Philadelphia, instead of them coming to us, I would have taken my netbook to write this post, then used their internet connection to actually post it. Instead, I'm taking a quick break from hosting and cooking to write it from the desktop in my office. Mobile technology is great for staying in touch even when we're doing other things!

How do you deal with disparate holiday schedules and the demands of your own family and friends?

Follow-Up Is Time-Consuming

No more blog-writing on the train. I'm back in New York and writing this one on my PC's large screen -- it is an improvement over the 10" screen on my netbook, I must say.

After attending the tekom conference in early November, I wrote follow-up e-mails to everyone I had met there, as well as to the people to whom my contacts had referred me. (Many of the exhibitors were sales persons and gave me the name of their vendor management person.) Since I didn't have direct internet access from my netbook, that meant writing them all in one large Word file, copying that file onto a USB stick, then using a gmail account I had set up from the browser on my uncle's computer to copy and send each of the e-mails separately. It took probably a couple of hours to write and send these 40 or so e-mails.

Later during my trip I started to receive the first replies to my e-mails, usually asking for more information. Using the same gmail account from my sister's desktop, I replied that I'd supply that information upon my return to the U.S. the following week. These e-mails came in small doses, but let's say another half hour or so for checking my e-mail and replying to these.

After returning to New York on Monday of this week, I followed up on these e-mails and supplied the information requested -- most frequently by filling in online vendors questionnaires. Since each questionnaire was in a different format and requested different information (including the version numbers of some of my software and similar items I had to look up), it took a while to complete them all. Another hour and a half for this, I'd say.

Wednesday I input the information from all the business cards I had collected at tekom into my Outlook Business Contact Manager, including a note on whether the person in question was a direct contact or someone I was referred to and a note on the language of communication (English or German). That process was quite time-consuming since all the phone numbers and such on each business card had to be input and checked on screen. I probably spent a couple of hours on Outlook.

Yesterday I created cover letters to send brochures to either the person I was referred to or, if no referral occured, the direct contact. Since the text was slightly different for referrals versus direct contacts and some letters were in English while others were in German, a mail merge operation didn't seem to make much sense. I therefore wrote sample letters, copied them into a Word document and then personalized each one by copying the address information from the Outlook record, then adding the salutation and, in the case of referrals, the name of the person who had referred me. Once that file was done, I could load my printer with letterhead and let the entire file print on its own. Let's say an hour total for this operation.

After that was done, I had to print an envelope for each contact. My all-in-one printer/copier/scanner/fax only prints one envelope at a time, and misfeeds if loaded with more than 6 or 7 envelopes at a time. So the envelope printing process took quite some time, although I was signing and folding the cover letters at the same time, then stuffing envelopes as they printed. That entire operation must have taken another 45 minutes or so.

Next, the trip to the post office. The lines at our local post office are usually fairly long, but they now have a nifty self-service machine. Except that machine only does 5 stamps at a time if you don't want standard U.S. postage. I mailed more than 20 letters, in 5-stamp intervals, so that took a little while, too, maybe 15 minutes.

After all this I've received the first requests for test translations. I won't include the time spent on these here, but just the "advertising" portion of this follow-up has taken me a full workday. Maybe its time to investigate customer relationship management software after all ...

Why Don’t People Read the Documentation?

It looks like this is turning into a train blog. This time I'm sitting in the train back from Salzburg, Austria, where I visited an uncle who makes flight simulators and also supports them. He told me how customers don't read the documentation he wrote, but instead call him whenever they have trouble operating his equipment. That seems to be a universal problem for technical writers: customers don't bother to consult the help files or printed documentation, then complain if the equipment doesn't work the way they think it should work. They think, for example, that a specific action should be triggered by a particular button. When that button doesn't perform the action they expect, they call the customer service desk rather than consulting the documentation about the correct button to press.

On the other hand, how often have you and I attempted to decipher badly written, badly organized and/or badly translated documentation for some device we bought? Small wonder that customers give up on even trying to consult documentation after they have encountered a few such texts that were written in programmer speak, contained factual errors or were translated into garbled English. If customers are to get into the habit of consulting help files or booklets, they must consistently encounter files or booklets that actually help them solve problems with the devices they handle.

This, in turn, means that the documentation -- in whatever form -- must not only be accurate and well written, but also well-organized, with a device's particular audience in mind. A cell phone intended for senior citizens, for example, needs to be accompanied by an extensive printed booklet illustrating each step with large screen shots. A software developer kit that lets programmers write code for a certain computer platform, on the other hand, requires only very specific online information and can include acronyms and IT terminology.

While technical writers need to keep their audience in mind when writing the source text, we translators all too often forget -- or never know -- who might be reading our document. Just as the original writer's word choices depend on the target audience, so do ours. Sometimes we can glean from the source document who the likely readers might be, as in the examples cited above. But if that is not obvious and the client didn't tell us, we should ask. No need for extensive audience analysis, but the answer to "Will this document be provided to the consumer or to the technician servicing the device?" or a similar question should provide enough information so that we can gear our choice of vocabulary and sentence structure towards the target audience.

If we consistently ask this question, agencies and end clients will get into the habit of providing that information with the project. This will (hopefully) result in documentation that is useful to the end consumer, leading to them actually reading the documentation.

How Multilingual Are Europeans? Observations From tekom

I wrote this on the train back to Vienna, Austria, after attending the tekom conference in Wiesbaden, Germany, for the past couple of days. A word about the trains here: I was sitting at a table in a high-speed train with WiFi internet access (unfortunately not free), travelling about the distance from New York to Montreal for around US$50. Quite a number of conference participants were at Wiesbaden’s main train station tonight -- even people from the surrounding towns who in the U.S. would probably have driven to the conference. Seems the Germans (and other Europeans) are on to something when it comes to reducing travel’s environmental impact ...

tekom is the technical communications conference in Germany, held twice a year -- in Berlin in the Spring and Wiesbaden in the Fall. It had quite a large translation component, including more than 60 translation agencies exhibiting at the fair held concurrently with the conference. As with most international events, the conference languages were the local language (i.e., German) and English. This lead to a panel composed entirely of German native speakers discussing the topic at hand with each other in English for the benefit of audience members who don’t speak German. Similarly, I overheard several informal conversations in English where clearly none of the participants were English native speakers.

English is not only the lingua franca at global events, it has become the official corporate language even at companies headquartered in non-English-speaking countries. A conference participant from Swiss pharmaceutical giant Roche, for example, said that all documentation for company products is originally written in English and then translated into any number of languages, including German and French, the two major official Swiss languages. His colleague was Rumanian and the two conversed in English with each other during the dinner we attended. The other two women who joined our table were from the Czech Republic, so the rest of the dinner conversation was in English, as well.

Such an international mix makes sense at a global conference, but I found that at least within the technical communications field many companies have become much more mixed in terms of nationalities than they were until not that long ago. I spoke with a representative of the German multinational Bosch’s language division who was from India. That conversation took place in German since the representative is based near Stuttgart, Germany, and speaks excellent German. Another language services provider, OmniLingua, has offices in Germany and Greece, among other countries. I spoke to the company’s representative in German, but was asked to forward my information to the company’s vendor manager, who is Greek. That e-mail is to be in English (I asked).

I found time and again that linguistic preferences could not be assumed based on a person’s -- or his/her company’s -- name. As movement within the European Union increases, many companies are becoming more polyglot, including employees from different linguistic and cultural backgrounds. At least among the educated professionals who attend such conferences, fluency in the company’s corporate language, in addition to English and one’s native language, as well as knowledge of the language of the country/region where one lives, is assumed.

In addition, professionals are expected to understand English-language literature relating to their profession. That professional use of English, however, also has its drawbacks. My brother (who still lives in Austria) recently noticed at an international youth event that while his professional English vocabulary is fairly extensive, he lacks basic vocabulary for other areas of life. (In case you are curious, he produces precision brass instruments for professional musicians.)

Compare such assumptions with the fact that many U.S. professionals only speak English, with maybe a basic knowledge of whichever language they took in college for a couple of years (likely Spanish or French). On the other hand, if all English speakers learned German to the extent that German speakers learn English, nobody would bother to translate German documentation. Where would I find clients then?

What Services Can Translators "Upsell"?

I've recently read up on marketing my services better. A few articles in a recent New York Enterprise report and elsewhere got me thinking that simply translating text may no longer be sufficient to get enough work at prices that let me live in New York City.

"Upselling" -- or adding products/services (for a fee) to consumer's core purchases -- seems to be the word of the day (or year). I can't seem even to shop for groceries anymore without the cashier trying to sell me something I don't want or need. Sometimes this can border on the ridiculous as when a toy store cashier tried to sell me batteries to go with a simple old-style board game.

While I will not subject my own (prospective) clients to the kinds of hard sell I experience in stores, I could be offering additional services on my website and in my marketing materials. So what services would it make sense to add?

1. Besides translating a website's text, I could update the source code pages with the new text, adjusting table width and similar code as necessary.
   
2. Besides translating a PowerPoint presentation's text, I could adjust the layout and text sizes to make everthing fit.
   
3. Besides translating a whitepaper's text, I could translate the flowcharts contained in the paper, resizing text as necessary.
   
4. In addition to accepting Adobe PDFs as source format (a necessary evil in our industry, it seems), I could provide the completed translation in that format, as well, with the original images intact and properly placed.
   

I could provide all these services with relatively little extra investment (except for buying MS Visio), although I would have to become more adept at some of the software involved. For example, I know basic PowerPoint features (and have created PowerPoints before), but I'd have to play around with the program some more to get up to speed on more advanced features. Similarly, I have used a previous version of MS Visio, but would need to teach myself the current version.

There are certainly other services translators could add to their core business, including working with other file formats (such as FrameMaker); writing the source text, as well; providing a country-appropriate layout for the text (probably more applicable for translations into right-to-left or top-to-bottom languages, such as Chinese or Arabic). I might explore some of these next year.

So what's your "upsell" -- or what could it be?

PS: I will be attending the tekom conference next week in Wiesbaden, Germany, and visiting family in Austria, so postings for the next few weeks may be more sporadic.

What in the World is Erse?

Yesterday's New York Times crossword puzzle asked for a 4-letter "European tongue". Based on other words around it, my husband and I came up with E_SE. None of the lesser-known European languages we could think of -- Sami in Scandinavia, Romani and Sinti in Eastern Europe, Basque in Spain, Gaelic in Ireland, Alsatian in France, Romansch in Switzerland -- would fit that pattern. It turns out (we had to wait for the solution in today's paper) that it's Erse. So what language is that and who speaks it?

Well, googling "Erse" gets you a manufacturer of components for audio and video equipment in the top spot, but then a couple of definitions from Wikipedia and several dictionaries, including Merriam-Webster. According to them, it is an alternate word for Gaelic, based on the Middle English word for Irish, Erisch.

Aha, not a language/people I had never heard of. So what would other languages be called in Middle English? Again, enter the web. There is an online Middle English dictionary housed at the University of Michigan. So German was called Alemaine back then (presumably related to the French Allemand). Next question then: how did we get German from Alemaine?

Enter the Online Etymology Dictionary. Apparently, German doesn't come from the Middle English Alemaine, but rather is based on the Latin germanus. Caesar used the plural, germani, to designate tribes in northeastern Gaul, possibly based on the name of one of those tribes. There is also a Celtic word "garim" meaning to shout and speculation is that germanus may be derived from that. Anybody who has ever been to an Oktoberfest can attest to the noisy character of that occasion -- although that probably holds true for any celebration largely based on an alcoholic beverage, no matter the culture.

What one doesn't learn when doing crossword puzzles! They do help expand one's vocabulary, even if this particular word will likely be of little use. A large vocabulary helps anyone working with language -- writer, editor, translator. So solving crossword puzzles (in both source and target languages) is a useful pastime for a translator. To that end, I'll buy a couple of crossword puzzle books when I go to Austria late next week.

If this piqued your crossword interests, here are a couple of sites that offer free online crosswords:

In English:

• Boatload Puzzles
  
• WebCrosswords.com
  
• Thinks.com (this one comes with a timer for the uber-competitive crowd)
  
• Los Angeles Times daily puzzle
  

In German:

• Freizeit Freunde
  
• Nordbayern.de (this one features instant feedback on your entries)
  
• Focus Online
  

Happy puzzling!

A 12-Step Program for Large Projects

I just completed a 3-week-long translation project that consisted of one 700-page long source file (63,000 words plus screen shots). In the process, I learned a few lessons on how to handle such mega-projects more efficiently. Here are my 12 steps for working on such projects:

1. Read the text in its entirety (on screen to save trees) and note important/recurring terms in an Excel spreadsheet or Word table
   
2. Research the terms you noted above and fill in the spreadsheet/table. This is your own glossary.
   
3. Divide the source file into smaller files. When doing so, make both the table of contents and the index separate files.
   
4. Import the glossary spreadsheet into your translation memory software and translate the table of contents and index. Add all terms in these two files to your glossary.
   
5. Translate your first source file, revising your glossary terms, if necessary, and adding any new terms you encounter.
   
6. Edit that translation before going on to the other files. This way you will have a solid basis for recurring text in the other files.
   
7. Translate the other files, one by one. If you change your mind on a term, add it to a list of changes to make to previous files.
   
8. After translating all files, edit the translations one by one. Make the term changes you noted above while you are editing.
   
9. Now convert each of the translated files back to MS Word (or whichever format is used for the deliverable).
   
10. Check that the formatting isn't too egregiously off in the Word documents and nothing is garbled.
    
11. Combine the Word documents back into one large file, checking for missing/duplicate text at the points where the files are joined.
    
12. Send the completed translation off. You may need to use a service, such as You SendIt or Dropbox, to transfer the file back to the client, if it's too large for e-mail.
    

One more thing I learned from this project: electrical engineering is actually quite interesting. Maybe I'll pick up an "Electrical Engineering 101" book one of these days ...