The twelve steps that produce a language's translation rules before any lesson is translated, and how the result is checked.
Last updated August 11, 2026
Translating a Bible study is not the first step. Before any lesson is touched, the pipeline builds a reusable language package for that language: a glossary, a translation memory, a doctrine risk registry, and a complete instruction set for whoever or whatever does the translating.
The package is what makes the work consistent and checkable. Without it, two lessons translated months apart drift apart in vocabulary, and nobody can say why a particular word was chosen.
Everything below is published openly in the Library. The Hindi pipeline example walks through one language end to end, with every step linked to its actual output, and is the clearest way to see this concretely.
1. Analyze the core passage in the original languages. The book is studied in Koine Greek or Hebrew, mapping each key term’s semantic range and its translation risks.
2. Build the Bible terminology registry. Every theological term is assigned a risk level. This is where the danger is named: in Hindi, Critical terms like salvation, resurrection, and incarnation can silently import Hindu concepts such as moksha, reincarnation, or avatar if rendered carelessly. See what the risk tiers mean.
3. Map cross-references and biblical themes. Old Testament allusions, messianic references, and covenant themes are traced, so a translation preserves connections the reader is meant to notice.
4. Identify core doctrines and assign risk levels. Romans 1 to 16 yields about forty doctrines. Critical and High risk doctrines require human theologian review before anything ships.
5. Compare how traditions interpret those doctrines. Protestant, Catholic, Hindu, Buddhist, and folk-religion readings are compared, to anticipate where a rendering could be misheard rather than merely misread.
6. Analyze the culture and regions of the speakers. Honour and shame dynamics, worldview, persecution risk, and literacy patterns all shape how a doctrine needs to be explained.
7. Survey the existing Bible translation landscape. Existing Bibles in that language are evaluated for register, source texts, and denominational influence. Where established wording is sound, the pipeline anchors to it rather than inventing something new.
8. Find the gaps in theological vocabulary. Where the language has no safe equivalent, and Hindi has no single word for justification, the strategy is decided up front: a compound phrase, a transliteration, or a paraphrase.
9. Write the translation memory. Every approved rendering is locked in, with rejected alternatives recorded alongside it, so every document uses identical vocabulary. In Hindi, salvation is always उद्धार, never मुक्ति or मोक्ष.
10. Generate the AI translation requirements. A complete instruction set for any AI translator: system prompt, forbidden substitutions, tone and register rules, and the escalation rules that send a decision to a human.
11. Summarize for decision makers. An executive summary states the risks, the vocabulary gaps, and exactly how many terms need theologian oversight.
12. Publish everything to the public Library. Nothing about the translation rules is hidden. Any reader can inspect why a word was chosen and object to it.
Publishing is not the same as being right, so the output is tested. Ten Romans lessons were translated into Hindi using the package, then translated back into English by a translator who never saw the originals. The two English versions are then compared word by word: text lost in the round trip shows struck through in red, text gained shows in green.
That comparison is the honest measure. It shows what actually survives a round trip, rather than asserting that the translation is faithful.
Two points in this process are deliberately not automated: