WORKFLOW

Trends come and go – crowdsourcing and transcreation, just to name a few – but since the advent of servers and the cloud, one trend seems to remain: Translation jobs are becoming increasingly smaller and more frequent.

When I embarked on trying to solve the problem of continuous localization, I was baffled by the number of different practices that exist among translation companies — I continue to find new ways of doing things even after four years of dedicating all my time to this!

While I do think that some of these practices are actually further aggravated by the translation companies themselves separating the sales and the production functions, large buyers have always had the bargaining power to introduce different settlement/payment models.

Having worked almost all my life in translation technology, I’ve also noticed that core innovation around payment models always came from TMS providers — practitioners usually express the need, but it is typically technology companies that create the solutions. As a co-founder and former business partner of memoQ, I was actively participating in designing the first innovations in pricing in collaborative translation, including homogeneity which is also known as internal fuzzy matches, and the post-translation analysis (also known as post-editing analysis).

What I see now is that the genie is out of the bottle: Large buyers prescribe the same workflows for projects that take days to translate as for projects that are only about 15 words. The admin overhead for the entire supply chain has increased dramatically, but people are still talking about TM leverage. While the practitioners spent hours at the latest GALA conference discussing why word-based leveraging is wrong now, I feel that the reason why words are still here is that it allows the luxury of not noticing the elephant in the room: admin costs have increased dramatically, and customers and eager salespeople are responsible for that. Without the makeup of the “word count,” this industry becomes hideous.

And don’t get me wrong, it’s not only the buyers. Translation companies are notorious for converting words to time, which makes as much sense as buying a liter of apples. There is some correlation, but hardly anybody knows or measures how much it is. One company I know has managed to win a contract where the buyer was progressive enough to have them charge by the hour. How did they do it? They didn’t take the time to change the supply chain to hours and have an hourly profit, which was the goal of the buyer, but they converted weighted words to hours.

So I thought it was time to explain the context of these innovations and see what difference they make between small and large projects.

CSA Research published this very interesting finding that speaks for itself:

There is, though, an alternative, optimistic reading to this: If you were able to reduce the admin and overhead by 50% to translators, they would be able to spend 50% more time on translation and research. You’d get 50% more translated within the hour. If you also reduced admin and overhead to the LSPs by 50%, they could spend 24.6% more on translators, and they could also increase their profit by the same amount.

Compounded, a 50% reduction in admin and overhead could lead to having 69% more content translated for the same budget! Is there any special word-based payment type that can beat this? The focus should be on cutting unnecessary processes, and getting the vendors to comply.

Source: CSA Research.

The birth stories of the different analyses

The Trados CAT analysis and its rounding implications

It is commonly known that the CAT analysis introduced by Trados was one of the main reasons why the translation industry became so translation memory-focused. Trados was the first tool to quantify the ROI of an investment, and without competition, it was an easy sell — you could quickly see when your investment paid off, especially when outsourcing where these figures were turned straight into dollars.

What did this create? First, a complicated format for quotations. Why the translation industry cannot easily use a decent CRM for the whole sales process is exactly because of the multi-line analyses that depend on four things:

• The source files,
• The content of the translation memories added,
• A percentage per rate table,
• A word price.
• But there is a fourth topic: the rounding rules.

Imagine you have a word price of 0.175 cents. You agree that you pay e.g. 33% for 100% matches, and 66% for let’s say 85-99% matches.

What you see is that the result is different if you round to two decimals each line, or if you first add up the numbers and then round it to two decimals. What is worse, this issue is more likely to come with small word counts than larger ones! Project managers spend valuable time adjusting the last cents of their word counts to the client POs.

Other companies agree on a fixed rate per match bracket, which not every tool supports out of the box. Here, converting this to a percentage can be a problem, because to get the exact figures, you may need to use many decimals.

It’s also interesting to mention that because of the translation memory approach, the same text can cost different amounts depending on the time of quoting, as your translation memories usually grow over time from other, related projects.

How homogeneous is the text?

One thing that Trados already introduced, and it’s the cuckoo’s egg in the analysis, is repetition. Why? Simply because the repetition is the only bracket that does not depend at all on the translation memory. However, repetitions also depend on the segmentation of the text.

Especially in software materials, however, there have been a lot of almost-repetitions.

Even if you don’t have a translation memory when you translate the first sentence below once it takes less time to translate the second one.

• Sentence 1: “What are the best practices for managing my translation memories?”
• Sentence 2: “What are the best practices for managing my glossaries?” 

Homogeneity or internal fuzzy can work if two prerequisites are met:

• The translator goes segment by segment from the beginning of the text to the end. The fuzzy match that the second segment gives if the first one is in the translation memory is not necessarily the same bracket as the other way around.
• The entire translation project is performed by one person. Well, let’s refine this for 10 years later: the translation memory that is being created is available in real time to the translator who translates the segment.
  This method does not work if:
• Anybody in the supply chain splits up the text, because it may happen that the match you have foreseen to be there is not available for the actual translator.
• Or if the translator does not work file by file, segment by segment in order.

This capability should only be used for translation analysis (never on MTPE, review, etc.), and for brand-new translation projects to be performed by one person. If you have a good translation memory, the difference between normal and internal fuzzy matching is very little. Also, if your updates are frequent, and your texts are small, there is very little chance that you gain a significant amount on this. If you want to implement continuous localization, do so only if you can guarantee that every job will be translated by one person. Don’t send jobs of 5,000 words with a 24-hour deadline, because then you are stealing money from the translator. From the administration perspective, this is plain sailing: It does not add any overhead.

Source: CSA Research.

Internal fuzzies created post-translation analysis

In the case of a collaborative situation, homogeneity does not work, because the beginning of the text may be translated after the end of the text, and translation memory usage depends entirely on the order of translation.

In my previous example, if there is no initial translation memory, and the first sentence is translated already, and I am translating the second sentence, I have a fuzzy match. If the first sentence isn’t translated, I am not getting any match and would like to be paid the full word price. It also does justice to the actual work performed, because if we are two translators, one of us, who does more work, gets paid for no match, and the other one gets paid a fuzzy rate.

Normal fuzzy matching requires a translation memory and gives you the translation price upfront. Post-translation analysis requires an agreement between the entire supply chain because to get a better price and get every translator paid fairly, the compromise is that this analysis goes bottom-up instead of top-down: the client’s analysis is the sum of the translators’ analyses.

Because of the administrative overhead – and also because it makes the buyers’ budgeting harder – this is not a preferred method for most translation projects. Use it exclusively in the case of larger, collaborative projects, for example when adding a new language, or translating a completely new training material or product. Just like homogeneity, this is also exclusive to translation projects, and should not be used for review, transcreation, or MTPE.

 Bundling and the curious case of cross-file repetitions

With the previous examples, it already became clear that bundling and unbundling is a central topic to finding the right pricing model that saves the most for the buyer and at the same time does not take away money from the translator. While the price obviously differs for a translator as for an LSP, the right pricing model must:

• Minimize the admin overhead on all levels (to keep translator capacity high).
• Approximate the time spent translating — only ask for fuzzy discounts if the amount of work spent on that segment is less than what you would spend if you were to translate it from scratch.

There is, however, one aspect of project management at LSPs — the main aspect — that makes it very hard to establish fair pricing for anything but the simple fuzzy matching, and this is the bundling and rebundling of translatable content. (Also bear in mind that if using fuzzy matching, the translator should at least be able to leverage all translation memories used for content analysis.)

The buyer has a need for translating certain content, which can contain a small or a high number of content units or files into a number of languages. Some of these are more urgent than others. When it comes to the theory, there are two extremes: On the one hand, we have the classical waterfall localization, where all the content is ready before translation starts, isn’t prone to change, and large volumes are outsourced at once. On the other hand, there is real continuous localization, where anything that changes is immediately sent to the vendors, without any buyer project manager bundling it further. The truth is reality is more of a hybrid model, because the waterfall model is hard to maintain in a fast-paced environment, whereas real continuous localization requires very well-defined processes and detailed agreements and only works in the most mature localization organizations.

However, there is one significant variable that most buyers ignore and that affects pricing: Will the content that is outsourced be translated by one translator, or will it be rebundled to be translated by multiple linguists?

If there is rebundling, only the fuzzy analysis or the post-translation analysis should be used. But when there is no rebundling, and the content is translated by one single linguist, you can safely rely on the calculations of translation management systems.

One typical setting in the fuzzy analysis that I see often used by translation companies and I find to be very unjust towards translators is the cross-file repetitions, because this depends fully on the bundling as much as the internal fuzzies do. While technically this is a straightforward approach in the case of traditional TMSes that work with projects, I don’t understand how is this different from applying homogeneity. If you don’t get all the files as a translator, you will separately translate those repetitions as no matches.

Cross-file repetitions should only be used for quoting if it is guaranteed that one single translator will work on all those files — but in that case, I personally don’t see why someone shouldn’t use homogeneity. I have yet to understand why anyone would need to use cross-file repetitions — for me, it seems to be an outdated concept.

Talking about files

Actually, files are an old-fashioned way of bundling — it’s an old practice that still lives with all of us. While files exist for software localization projects as well, given that files are not affecting the context, they are mostly hidden from the translators’ eyes and just presented as metadata. Traditional TMSes also can normally merge files into one view, but still, most of them work with the file as a unit simply because they were conceptualized for documents such as Word, InDesign, Framemaker, etc. If those files are numerous and very short, it is easy to forget about one of them. A lot of human admin time goes into making sure that the entire project is translated on time. However, files also mean simplicity in unbundling: they are a customer-defined, logical unit. If you distribute files or bundles of files between multiple translators, you normally cannot go wrong with context. If you split a document into two halves, it is much more likely that the translator will ask more questions.

Enterprises often try to help LSPs by putting multiple files into projects. While this really removes management time for the initial LSP, translators very often only see jobs. A job is one language pair, one workflow step (e.g. translation or review), and may contain the downloadable files, reference files, or translation links. For the process, the ideal thing is to see one file at a time, but for the administration overhead, the more jobs you need to register and track, the more admin work you have. Ten files of 10 words is much harder to manage than one file of 100 words, due to the effort that’s needed to check if everything’s going to be delivered. One easy way to check for delivery of files is to stipulate up front that you want the files delivered with a certain naming convention. While without opening the files you cannot know if the contents are correct, you can easily automate checking the number and names.

Using files or links is fine, however, try to avoid adding complexity to the already tricky situation by having the administration based on the file level. Instead, focus on bundles: aim for single translators, making sure that bundles do not exceed 2,000–2,500 weighted words per day in projects with a deadline of over 48 hours, or 1,000–1,500 words in shorter turnaround time projects (as translators may already be working on something else).

Post-editing metrics

In the early 2010s, Memsource — which is now Phrase — was the first one to successfully introduce the concept of reverse fuzzy matches, which was mostly used for machine translation post-editing projects. Before they popularized this approach, many thoughts went into using a Lehvenstein distance to quantify changes, but it didn’t really lend itself to be translated into pricing. However, building a temporary translation memory from one set of texts and then applying the same source matching on the other set of texts (while comparing the edited vs the original or the original vs the edited yields different fuzzy results, both are feasible), and creating a standard CAT discount table turned out to be not only possible but also very workable.

Such a table is quantifying the work of the post-editor or reviewer at least as well as the fuzzy CAT analysis but suffers from the same problem as the post-translation analysis: It needs to be done after the work is done.

In my view, there isn’t much difference in quantification between MTPE and actual proofreading/review — just like bad MT, there are also bad translations — though the latter is probably much more research-oriented. Still, given the growth of MTPE, the industry has developed some other methods to address the problem of upfront costing, which is based on regular measurements, but only applying changes to the rates at times. Human review is either charged on the word count, with a different CAT grid (e.g. only locked, or context segments are not charged for, everything else is charged at 100%), or in many cases, it is based on a conversion between weighted word count and hours.

One recent and interesting technology is machine translation quality estimation, where the business aspect is that it aims to judge the actual MT used upfront and estimate upfront the time saved, similar to the old CAT grids. This way, a third-party provider can take over the task of regular measurements.

MTPE CAT grids do not cause any difficulty in project administration, except for the overhead to the LSPs/enterprises to gather the post-editing analyses to be able to reiterate the pricing, which is as much a separate process from translation projects as LQA is. Converting word counts to time is a bigger issue. Theoretically, it would be possible to apply a different weighting, but many business management systems do not support this complexity (in fact, out of the commercially available ones, I have only seen one that does it out of the box). Maybe it would cut administration time to just add a single line of weighted words for review, and calculate review capacity also in weighted words, just like translation?

Updates and reimports and cancellations

Updates, changes, and reimports to translation projects are the biggest source of administrative costs. While this was standard in the waterfall model — and due to the size of the projects, it took a small percentage of the budget — in a continuous localization model customers should own their mistakes. Ideally, once a project is running, there should be no updates. In that regard, SLAs should bind the client not to intervene in the project under a certain project size once it was approved.

Being a provider of automation, we do see this happen, and then no clear rules apply. For example, one LSP was taking changes free of charge until the project manager assigned the translations — should this be the concern of the customer? Not separating the stages of a project goes down the supply chain. While technically it is very simple to reimport a document and quantify how much of it is already translated, there is no easy way of establishing the cost of what the translator has already worked on, except the post-translation analysis. If you have a fuzzy analysis, it does not tell you which part of the document the fuzzies come from, and which part of the document has almost entirely no matches.

An update should be a cancellation and a restart of the whole process, with the newly updated translation memories. It doesn’t matter if you just remove a single file from a bundle, or change a document. Even if it’s the same word count, and the analyses don’t change, changes need to be communicated down the entire supply chain, projects need to be updated, and making sure that the changes were implemented adds significant extra costs.

While TMS programs enable updates, this is a slippery slope for business management. The setup complexity for the translator to work on the updated files depends very much on the toolset: If they’re working on your TMS, it is fairly easy, but when they are working in their file-based tools, many projects have to be recreated and any of them may be the point of failure (and deliver the translation without implementing the change). However, if their post-translation (post-editing?) analyses don’t get automatically created, many of them don’t even know how to do it.

If you do continuous localization, set up a little budget for human error on your end. In modern corporate culture, most employees want to be nice to colleagues and not be held responsible for mistakes. Even if a mistake was made by a colleague, it is often solved by requesting more from vendors rather than pointing out colleagues’ mistakes. This approach, while understandable on the human level, costs you way more than a few projects that won’t be used, especially if these projects are only a few hundred words.

Project-related tasks outside the project workflow

While fortunately this is relatively rare, I have seen one big translation buyer implement this at large. Post-translation/post-editing analyses, while very useful, are already problematic because of the lack of technology support. However, a project is a project because it has a beginning and an end. One company sends updated figures, but days or weeks after the project is done, for small projects, that LSPs then apply across their vendor base. In this case, the initial analysis is a way to establish a weighted word count and a deadline rather than a basis of costing. There is not a single commercial business management tool I’m aware of that allows importing CAT grids into multiple projects at a time. Even if there were, ID matching is difficult across the supply chain. And the worst thing is that this on their end is a regular activity, rather than anything bound to the projects, so the project records can also not be closed for an indefinite period. If this is a continuous localization scenario, why is there no timeline communicated to the vendors?

Another hard-to-manage workflow is the implementation of client review. LSPs do this as separate, non-paid tasks. This falls into the admin costs, together with LQA. Consider how you can decrease these costs by providing better style guides up front, or by limiting the scope of internal reviewers to those who are already trained. Also, consider your LQA sampling — if you do LQA on every project, how is it different from proofreading? What are your strategies for improving, and not just measuring, language quality?

Standard teams and forecasting

Just like in every other profession, context switching is hard for translators too. Language quality is best guaranteed with a limited number of end customers, or end customers who all follow a regulated terminology (e.g. European Union institutions). In an ideal situation, processes are agreed, documented, and not deviated from. Everyone in the supply chain knows what kind of projects can come, in the case of different types of projects, and how the administrative information is sent and received (most LSPs use portals here, but some of them work in emails).

This takes time to work out: MLVs introduce their own systems to keep track financially of payables and receivables and delegate the right bundles to the right teams. SLVs, if used, add another layer, mostly using simpler systems. Translators have to use their direct clients’ business systems but have to often work in the end client’s translation management structures. This requires careful thinking and setup.

Technology is also an important aspect here. The above-mentioned quantification is supported by some translation tools, not by others. Business management systems such as Plunet, XTRF, Protemos, or Quahill have integrations with translation tools, but only to a handful of systems — for example, if you as an end customer use GlobalLink or Smartling, there’s not a single commercial tool out there that can propagate the information automatically. Also, none of these tools have automated support for post-translation analyses. There are many gaps in the supply chain’s tooling, and you as an end customer have approximately as much impact on their tool choices as they have on yours — if the cooperation is close, considerably more.

The only way you can really help here is to be as explicit as you can by defining the terms of cooperation in project management and requiring documentation from your main language partners that prove that they provide all information to their vendors (or it may actually be an even better setup if your agreement allows you to have conversations with their vendors). Your language partners hire their vendors on the basis of the expected volume, and it is much easier for them as well to train people whose capacities they’ll use to a large extent, rather than just occasionally.

Finally, just as you can create a style guide to assist with your translation quality, a process guide also can help. It is not actually very different from your style guide, because just the way you introduce your product lines and areas of operation to your customers, you can also introduce the translation management considerations, translation areas, and job types