Using models for translating contracts (quick tip 9)

illustrated-archery-target
Translating a document requires knowing what it looks like in the target language, especially in a format-heavy genre like contracts. And knowing what the document looks like in the target language entails having models of it, either in your head — if you know the genre inside out, or on paper, particularly when translating a new type of document. Models help in a couple of ways.

First, and at first glance, a model can drop big hints on how to translate any obviously equivalent parts of the document (e.g., headings). Of course, where formats diverge greatly, you may not find any key translations jumping off the page.

Second, models can reveal technical terms specific to a particular contract type. Thus, models can serve as context-reliable dictionaries.

Third, models can shine a light on how the target language favours expressing information in the genre. In our case, models show us the style and syntax of contracts. And where you spot matching function across the divide, you can emulate target conventions to produce more authentic translations (versus blindly rendering source conventions). You can most often do this by mimicking the verbs and tenses used in the target language.

What kind of models?

So models can help. But what kind of models? I think any authentic and reliable example of the kind of contract you’re translating. So we don’t aim for perfect. Nor even does a model have to fit the kind of style or register we use. (Presuming you’ve already made decisions about this kind of thing. As opposed to using the models to decide on style and register, in which case you’d probably want to qualify the characteristics you identify by consulting a greater number of samples and style guides.)

When I first started thinking about what kind of models to seek out, I envisaged perfect models that exhibited to a T the style and register I wanted to use. But this is impractical and out of step with how I actually use models when translating.

So while now — after having read a few contract style guides — I do have some excellent models that I can use, it’s unrealistic to think that one or two exemplars will do. In practice, I use any old models of the type of document I’m translating that I can get my hands.

Furthermore, given the non-equivalence in legal translation and contracts (at least structurally), in practice, even a perfect model can only take us so far. We will always have to do extra work. What really matters is finding a model of the same type or as close as possible. E.g., a supply agreement will provide more help for translating a supply agreement than a sales agreement will.

Prescriptive

What happens in practice? At least in my case, I use models to identify and check key terms and expressions for the type of document I’m translating. So nowadays, having already set the criteria and rules I want to use in contracts, I don’t use models for general contract language.

Not quite the corpus approach that I know some academic translators use for both general and technical language in journal articles. Because a true corpus approach entails paying more deference to the samples. This means you need a high-quality and fairly uniform base of samples, which I imagine would be easier to compile for academic writing.

But when it comes to contracts, we need to get a little more prescriptive. Aside from the greater contrast in the quality and style of potential models you find about the place, non-equivalence rears its head more often. So while we can use models to mine technical expressions, we temper more general legal language according to our criteria. Thus, in the real world, any old model will do if you’re prepared to take the good and change the bad.

Written by Rob

Rob Lunn is a freelance legal translator based in Spain. He translates from Spanish and Catalan into English.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.