The How-To Library

Designing a Stress Test for a Translation Project — Towards a Global Benchmark

Wish Matrix of Client and Translator

Every client prefers his or her project to be done within deadline and of best possible quality. This is a wishful thinking because real life lies between the emails of the sender and the delivery by the translator (by the time called deadline). And real life always and invariably upsets calculators. From the vantage point of a client, there are only empirical data for guidance with no general reference or benchmark. For the translator, the reference is only his/her availability and other factors known only to himself at that time of acceptance.

There is no global benchmark on the quality / deadline / cost trinity for a translation project. As far as I know of.  

The essay would like to put forward the idea of designing a model, which would easily lead to such a benchmark. This can be implemented by user data generated by the users of portal like www.translatorscafe.com  

Existing Empirical Model:

The whole thing, the most profound aspect of the project – the cost, deadline, and quality ratio becomes a matter of instant fixation – like futures and options. People, who deal in futures and options tend to hedge, i.e. manage their risk by building many imperfect cushions or dampeners around. In translation industry – there is no such model, no such hedging, and no such risk management. Whereas any translation project at any stage can feel the stress due to as diverse events as that of a viral infection of the translator or an earthquake in Indonesia, disrupting under-sea fibres.

Result: Stress, Low Quality Delivery, tug-of-war with deadline and sometimes – deep bitterness between two parties who blame each other for no other reason than this: Their contract was not taking real life into account.

We need a model. What the model would do would function something like ELISA test. The model should be 99.9% reliable in its negative result and 95% reliable in its positive result.

The Model: Input, States and Output

Let us call this Model as ProTest. ProTest will be actually incorporating protests on cost, quality, deadline from client and translator to reach a stable and amicable state.

ProTest will be inputted by outsourcer first with their input – quality, cost, and deadline. The model will have essentially 3 states:

1. Stable(e.g. 2000 words – 2 days – with proofing by independent translator, ms-word document)
2. Unstable (e.g. 12000 words – 3 -days – proofing – PDF as source)
3. Oscillating (e.g. 6000 words technical – 2 days – impeccable accuracy)

Same will be done by the translator with his data for the same three basic parameters.

Reconciliation of Output and Decision Making:

The model can give altogether 3 X 3 = 9 states. The most relevant ones will be:

Stable (Outsourcer) / Stable (Translator): Project accepted. Operational Terms and Conditions to be decided.

Stable (Outsourcer) / Unstable (Translator): Deadline extension / Increase of Fee / 2 more linguists included with no proofing. Project cannot be accepted at this stage

Stable (Outsourcer) / Oscillating (Translator): Translator requests deadline extension to make it stable or demands higher price.

The idea is to tweak parameters by both the parties to make a stable / stable system. This will eliminate many post-acceptance hassles and bitterness.

Teaching the Model:

The model can be taught by the users themselves. TC can take input from thousands of projects done everyday across all languages and we can follow a Wikipedia model of self-correction and appendation. The model can be inputted by clients and translators.

In course of time, a global reference will emerge across languages and project types and that will help translators understand what is demanded of them and outsourcers will understand how much stress the system is capable of.

This will make expectation realistic for both the parties and claims of many adventurers exposed.

Recommend this article: Tweet