Back Translation methods Pros and Cons?

Question

After watching the training videos and reading the Helps, it seems that there are two methods to make a Back Translation. One is to create a new project and then have the back-translator type in his back translation of the text. The other is to use the Interlinearizer to make statistically guessed glosses of the text. Then the back translator would correct, if necessary, and approve the glosses.
I was wondering if those doing translation work had a preference based on their experience of which method to use. Are there pros and cons that would lead me to choose one method over the other? Would there sometimes be constraints in the translation project that would direct me to one method? We are trying to make the best back translation as efficiently as possible. Any advice will be appreciated.

Answer 1

It is important to note that we have made a significant change in Paratext 9.2 beta to address back translation concerns. In my translation experience, it is bad practice to allow a translator (who understands the vernacular) to be influenced by the NIV or whatever model text Paratext is set to use to guess the meanings of words. I would rather see the beatitudes start with “Lucky are the…” than “Blessed are the…” just because NIV proposed the word blessed.

We made it possible in 9.2 for a translator to pick no model text as an option when creating an interlinear. Let the consultants continue to use it to get the gist of the text, but let’s stop predisposing our translators to using the “correct” glosses.

Incidentally, in this case, the predictions will still work, but will only be based on words that you have already glossed. So you will start out with very few predictions and it will increase as you get more text interlinearized.

Comments

I’m really glad to hear about the option to pick no model text. Less clutter.

I was wondering recently whether PT might add a transliterator (for names) into the interlinearizer. For non-Roman scripts being checked by consultants not familiar with that script, it’s nice for the consultant to have some impression of how a name is represented in the translation – but having to type out the transliteration for each new name (especially in genealogies!) is quite time-consuming, so the temptation is to use the suggestions from the model text. The transliterator could (presumably) be trained by the user, or could self-train.

---

The Biblical Terms tool has for this. It is called Adapt Names. You could read about it in Help. Maybe that functionality could be made to be accessible to the interlinearizer. You can do this type of thing with another program called Adapt-it. Using that would mean that you would stop using the interlinearizer in Paratext. It is not a trivial to move data between the two programs. Main - Adapt It (adapt-it.org)

Answer 2

This thread will be interesting to watch.

How we do back translations depends on why we need a written back translation, what its purpose is, who will produce it, who will use it, and how long we will maintain it, and how long we intend it to remain useful. The answers to those questions will vary widely.

Our multi-language team publishes translations in diglot form, the vernacular in one column and a shared, readable, publishable back translations in the LWC in the other column. Shared here means more than one translation in a language family uses the exact same back translation. If you want to know why we do that, see the BT2019 paper Ben Pehrson and I wrote about it here. In it, we describe how requests for diglot scriptures from local church leaders led us to rethink the purpose of our back translations and how we produce them. Your situation is probably very different from ours so you will probably need a very different BT strategy. But the questions we did not expect to ask ourselves about back translations may help you think through your BT strategy.

john_nystrom
Aitape West Translation Programme
SIL PNG

Comments

Thanks for that paper. Indeed I have been considering the same thing for our central belt Nigerian context where pastors often serve communities where they don’t speak the local language, and where there are multilingual households and churches.

I have major problems with back translations and see many people going through the motions, just because it seems necessary to do it. I would much prefer myself to lean on the actual translation and some support from a decent interlinear gloss (I call the interlineariser the ‘glosser’) since we frequently see back translations cover up problems and make you think there are problems which aren’t actually there in the translation. So a back translation brief/purpose/audience statement may be important and we need to be careful not to press a back translation produced for one purpose (eg a crib for the consultant) to serve a different purpose (an alternative to LWC scriptures).

---

This is an important question of practice, and the answer may well be different for different teams. Paratext has different functionalities to meet a range of needs. The existence of the Project interlinearizer or the “Guess translation” features do not imply everyone must use them. It seems since this is question of practice you might want to post this question on MAP or the BT list. Those are the forums where translation as a discipline is discussed by a much wider audience. You might frame the question differently to something like “What are the qualities of a good back translation, and how does one train a team to produce one.” Once you decide what kind of back translation(s) you need then how to achieve that using Paratext will be apparent.

Answer 3

Mark,
I’ll share my own experience. The teams I have worked with use the Interlinearizer to produce their back translations. It does produce a very literal translation, which carries with it some of the flavor of the grammar of the local language. When they approve the glosses, they’re exported to the back translation itself. They can always go in and tweak that back translation if it isn’t understandable. This whole process works great for consultants who are able to understand a very literal translation, or who already have some familiarity with the grammar/structure of the languages they’re working with.

If the consultants who will use the back translation will struggle to understand that more literal style, then a manual back translation could be better. If the mother tongue language and the back translation language are too dissimilar, then the Interlinearizer may never produce something very readable, and a manual back translation might be better.

Interlinearizer: Generally quicker, easier to update at each stage of translation. May better reflect the structure or grammar of the original text. May not be clear or natural enough to resolve a consultant’s concerns.

Manual Back Translation: Produces a more natural sounding result, may better convey how the text will be understood. May conceal structural issues or may hide mistakes (the translator can write what they think it should say rather than what they’ve actually written).

I think the main restraints then, will be on who will use the back translation and how clear it needs to be. If the consultants using it will can understand the somewhat literal style of an Interlinearized back translation, and if the back translation does not need to be very clear/natural, then the Interlinearizer is a great choice. If the consultants require a more clear/natural translation, or if the back translation will have other uses that require it to be high quality, then a manual back translation could be better.

One other constraint. The Interlinearizer will work especially well for languages with words with minimal morphemes. For example, with aglutinating languages, where words have many morphemes, the Interlinear requires a bit more work. But for languages where words have few morphemes, Paratext can get very good at guessing correct glosses with minimal extra input. The Bantu languages I work with have many variants due to tense/aspect, subject, object, etc. All of that variation means that Paratext takes longer to guess good glosses for every possible combination. But even so, the Interlinearizer is very helpful in reducing the time we spend working on back translation.

Answer 4

Our situation: highly isolating language, BT made by native English speaker (OTT – me!). I use the interlinearizer then smooth out the output once it’s exported to BT. This helps me (1) be super-consistent; (2) remember to include details like INCL/EXCL, PERS/IMPERS, etc; (3) avoid “hiding” potential ambiguities that the consultant should be aware of (since the truth is, I don’t really know what the translation sounds like to a native speaker). This has worked fine for us, since our consultants do fine with an unnatural BT.

Here’s what Gen. 1:6-8 sounds like in our BT. Note that bracketed explanations are added in the “smoothing out” phase.

\p \v 6 After that \nd God\nd* said: «let there-be IMPTV a lofty/open place/region in-the-middle-of the water, in-order-to divide~apart water from water». \v 7 Like that indeed \nd God\nd* made the lofty/open place/region, he divided~apart the water, allowing [“allow” and “let” consistently translate the verb meaning “give”, which could also be translated “make” or “in order to”] some water to be under the lofty/open place/region, (and) some water additionally (to be) allowed to stay above the lofty/open place/region also. \v 8 After that \nd God\nd* called that lofty/open place/region saying “sky”. Then there-was night/dark there-was morning, the second day.

The interlinear still takes a fair amount of work, since before exporting each verse, I select the most appropriate glosses from the available options for each word/phrase in the translation language. I also add “filler” words like articles (which our language lacks) over on the interlinear side, to reduce the clean-up needed on the BT side.

Answer 5

Good question!

Speaking as a consultant, we view both the IL and the standard BT as useful windows into your text and we’re happy to use either (or both!). My personal preference is for the IL or at least a more literal BT. (Perhaps another consultant can give their reasons for preferring the standard BT.) I’d rather take more time and have a better idea of what’s going on in your language than blow through verses and miss something important. For example, I was looking at a draft recently and one sentence had a different word order than everything else. That is a big clue that there is something going on there, and it could easily get smoothed over in a BT. And we deal with languages that don’t use articles and have different word orders all the time, so don’t worry about making it easy for the consultant.

Ideally, you’ll be working with a consultant for multiple books (maybe several years), so we’ll start learning your language (the IL is better for that). I’d rather put my notes in the draft itself, rather than in the BT because it is easier for the team and helps keep them focused on how their language sounds rather than the LWC.

Finally, the IL is nice because it is smart. It learns as you go along so eventually you’ll be confirming a lot of words instead of writing a new BT from scratch for every verse. Plus I believe the IL is being programmed to tie in more Biblical Terms tool.

Some other questions:
Are you going to produce a dictionary or grammar? Use the IL.
Are related languages going to be looking at your translation while they’re drafting? Maybe the BT.
How strong is the person doing the BT in the LWC? If they’re not very good, the IL might be better because it is less likely to introduce back translation problems. But conversely, if your person doing the BT is very good in the LWC, they can bring out nuances without obscuring the underlying structure of the language.

I hope that helps.

-anon062569
Translation Consultant
Seed Co., Americas Area

Answer 6

I know consultants who use only the interliearizer (not even exported to the BT project). That works well if the text is locked while the consultant makes their notes, and they are familiar with the structures and orthography of the language.

Others use a free BT written by a speaker of the language not connected to the team PLUS the interlinear. That’s helpful to see both what is actually written in the translation and also to see how people understood the text. Also it helps to make sure notes which just turn out to be “BT error” are at a minimum.

Answer 7

We (SIL NLP team) are working on a method of using Machine Translation to produce a draft Back Translations.

We anticipate that it will be most useful for those working on an OT translation. It requires the NT translation and Back translation to train the model. Slightly less might work, and it wouldn’t have to be all NT data. In fact it would probably work better with a mix of NT and OT.

At the moment we are testing it with Back Translations into English, Spanish and Swahili.

The quality depends to some degree on how accurately the NT and NT BT, but this is one reason to consider revising a BT even if the main purpose for the BT wouldn’t require it to be updated.

If you are interested in testing this please get in touch. We have a few project teams testing it now who are generally finding it useful.
dcb .