SimulTrans

I am a member of the Society of Technical Communications Management Special Interest Group.  This group has an email forum where questions are often circulated about various topics.  One that came up today asked about the best way for processing scanned PDF files.

SimulTrans occasionally receives scanned PDFs from clients who have lost their initial source files or who have inherited materials through an acquisition or distributor relationship.  While it is never optimal to embark upon a translation project without source files in their native format, occasionally these scanned PDFs must be used.

Responding to the person who asked about the best way to prepare scanned PDF files for translation, I wrote the following reply, which I thought more people may find helpful:

At SimulTrans, we often need to OCR scanned PDFs for translation.

While we have used Adobe Acrobat Professional's OCR capabilities, we have found the ABBYY FineReader application to be even more effective for this purpose.  We like the ABBYY product because it allows us to define zones in each PDF for conversion (separating text blocks from graphics and defining how columns should be read), offers recognition in many languages, and provides cleaner output in a variety of formats.  The OCR results are not perfect, but better than we have seen with other tools.

It looks like they offer a free trial (http://finereader.abbyy.com/), so your team could run some tests to see if this product might be a good fit for their needs.

Almost every night I read books to my sons at bedtime.  We each pick a book and then use alphabetical order of the titles to decide the order in which we read the three books.  My sons ask questions about sorting, such as how to deal with spaces, what articles (a/the) should be abandoned, and if capitalization matters.

Here at SimulTrans we face similar questions each day, multiplied by the dozens of languages in which we translate materials.  Whether sorting index entries, items in a table, or database entries in a software screen capture, we need to take into account the proper collation sequences for each target language.

Today I received an email with a spreadsheet containing the "Final Pricing" for a client from an Account Manager at SimulTrans.  We have worked this this customer for over 10 years, and I do not believe today's pricing spreadsheet is any more final than its dozens of predecessors.  Like most of SimulTrans' customers, this client often requests new languages and services while also being subjected to the ebb and flow of localization costs as they are affected by currency exchange rates, competitive pressures, and negotiation savvy.

I decided to write about this "final" pricing spreadsheet not to highlight that rates can change, but to make the point that it is always a bad idea to label any file as "final."  I see this moniker used in source files from customers, cost estimates we develop for prospective clients, project schedules from SimulTrans' project managers, and even some deliveries sent at the end of projects.

For the past couple weeks, SimulTrans has been undergoing our annual financial audit.  Like most companies, each year we invite external experts to come in to review our financial records, ensure we are accounting for everything correctly, and provide some input on the health of our business.  Thanks to changing auditing standards, I have had an opportunity this year to spend a bit more time with the auditing team, as they have expressed more interest in our operations behind the numbers.  It is always helpful and interesting to get the perspective of outside consultants in our programs.

Realizing the value these annual audits provide, I was thinking that perhaps companies could benefit from localization audits.