As mentioned in a previous post, a QA (Quality Assessment) step can be vital whenever we try to meet the high demands of our clients. We always do our best to deliver a high-quality job. But sometimes, some details fall through the cracks. Sometimes, our clients will require a one-step job (whether it is just the translation of a document, or just the step), or a regular two-step or three-step workflow. But no matter how many steps are involved in a particular job, it is always a good idea to perform a final QA. This step is going to help us find issues that may be skimmed over by the naked eye. Whether it is the use of tags, punctuation, source or target mismatches, numeric mismatches and so on, or any personalized check you want to perform.

We can rely on dedicated to this task. I would like to mention one in particular which has proven to be very helpful performing these tasks. I am talking about XBench. This program recognizes different types of file formats. Bilingual translation-related files in XLIFF format (such as the working files from Memsource or SDL Studio), even the old Trados’s TagEditor files, Word files, as well as Translation Memories and Glossaries from different program sources. This program comes with a preset generic checklist, which includes, among other features, inconsistencies in source and target, tag, numeric, URL and alphanumeric mismatches, unpaired symbols and quotes just to name a few. There is also an option to create personalized checklists, which can be useful when we deal with either different clients or linguists and requests for specific formats. Within this frame of checks, our job becomes easier.

Even though a QA step can be performed at any time during our workflow, it is recommended to perform it as the last or penultimate step. Normally, a final QA step should not result in major changes to the content of our project, unless we have to modify a segment due to an inconsistency in our target. Working with the content itself is the task of the translator, editor or proofreader. The QAer will deal more with the way the final job will be presented, taking into account our client’s preferences (that is, checking all instructions have been followed) and the overall consistency of our project.

Another advantage is that this step can be performed by the same linguist who has performed either the editing or the proofreading of the document. Since it won’t be a biased task (because again, the QAer does not modify the content unless it is strictly required by an existing inconsistency), the task can be performed by the same resource who has performed the previous step, or by one who will perform the next one, and in this way, saving time finding another linguist from our data base (You are welcome, PMs!). Whenever we talk about saving resources, we could be instilling the wrong idea into our clients that our final product won’t be satisfactory, but trust me, this won’t be the case.

Performing a QA task proves to our clients that we are committed to delivering a high-quality product. Some companies choose not to charge the client for this step in the workflow, making it part of their standard TEP (Plus free QA) workflow. It is an investment companies make because they know that a high-quality job means more business, and more business means more income, so everyone (clients, linguists and translation agencies) is happy.

So, to all companies and linguists out there, invest on quality! Your clients will appreciate you for it.

Tagged with:

You must be logged in to post a comment.