Language happens to be one of the most difficult obstacles we face as a Japanese company working with an American company for a technology project. To begin, I’d like you readers to watch a short clip from the movie, “Lost in Translation”.
Notice how the director is going on and on about something, and their hired interpreter has basically chopped it down to being “Look into the camera”? That’s a bit like the problems we’re currently facing.
For their latest automation, the customer has a list of requests for the interface. To address any ongoing programming issues, our customer sets weekly conference calls between US and Japan. Our customer does not speak Japanese, and only a select few of us speak both Japanese and English. None of the interpreters are engineers of software or machinery. Long story short-
REQUEST FROM CUSTOMER: Return back to Format “A” for a portion of interface data (Prescription Number + Store Number = XXXXXXXX-XXXXX) as originally used during prototype testing. Current format “B” is only Prescription Number ( = XXXXXXXX)
OUR UNDERSTANDING/COMMENTS: We never, EVER had the store number displayed before. When was this request made?? We will adjust the software to reflect this change.
THE RESULT: The store number is now visible on the main Stand-by screen, and NOT on the requested areas by our customer. Fix is on the way, 24+ hours lost on unnecessary work and revisions. Again.
How did this happen? Like the Suntory Commerical, weak translation/language barriers can cause various setbacks to the nature of the project and its organization. Adding to this a massive workteam and timezome difference, the delays have a profound effect- loss of one day can equal the compound loss of a week’s worth of other groups’ working time.
The first problem is that our translators, including myself, vary in terms of in experience. Experience, in this case, can mean background, or project understanding, as well as fluency and the interpreter’s available vocabulary.
Now, add to this the problem of the translator’s “style”. Most companies who rely on internal translation/interpretation, they trade the strength of project/product knowledge for wildly variant translations. From our weekly conversations, I’ve heard translations that are “approximate” to “gisting”. And because none of us are career-interpreters who happen to work for the corporation, I’ve never heard a “Perfect”, 100% translation. An example of the types based on the above story-
Customer says: “We’d like the revert the Rx number format on the interface in the fill drug process to the way it was before, with store number after the prescription number.”
Perfect Translation: – (Exactly as above.)
Approximate Translation: “They’d like to revert the Rx number format back to the way it was before with store number.”
Gisted Translation: “They want to add the store number to the interface.”
How have we addressed this problem? The obvious solution would be to hire professional translators- possible experience problem, but nigh-perfect transmission. But seeing as how funding and manpower are limited, our solution has been to have additional written e-mails for more difficult issues that are not being resolved or being “lost in translation”. In addition, the interpreters roles have expanded to include “policing” the conversations. Recently implemented, we’ve not had enough time to assess the effectiveness of our new system, but our “initial” exchanges have proved to be insightful and much more accurate.
So, have any of you had any experience with major translation mistakes during projects? If so, how did your company deal with it? If you had to compromise (as we did), what did it “cost” your company, if anything?