The text is correct in its original script. Now it has to appear in a second script as well — so a reader who knows Tamil but not Devanagari (or the reverse) can still follow every syllable. This is transliteration, and it is a different job from translation, with its own quiet traps.
New here? This is one article in a Gurugo Labs field series drawn from a client engagement to produce a traditional trilingual (Sanskrit · Tamil · English) devotional book — but it reads on its own. This article: what it means to render a text into a second script faithfully, why that's different from translating it, and where the process trips people up. One distinction you'll need: translation changes the language to carry the meaning; transliteration changes only the script to carry the sound.
Two jobs that are easy to confuse
Take the Sanskrit word शान्ति. There are two completely different things you might do with it.
You could translate it — carry its meaning into another language: शान्ति means peace. The English word shares nothing of the original's sound; it shares its sense.
Or you could transliterate it — carry its sound into another script, leaving the word itself untouched. Written in Tamil letters, शान्ति becomes ஶாந்தி: the very same word, the very same sound, now readable by someone who knows the Tamil script but not Devanagari.
For a devotional book this distinction is everything. The mantras are not there to be translated — a reciter needs the exact sounds, not a paraphrase of their meaning. So what a trilingual prayer book mostly needs is faithful transliteration: the same sacred syllables, presented in each script so that any reader can pronounce them correctly.
Why transliteration is mostly mechanical — and why "mostly" is the catch
Here is the good news. Unlike translation, which needs human judgment about meaning, transliteration is rule-based. Each sound in the source script maps to a letter or letters in the target script. Because it's a system of correspondences, software can do the bulk of it, converting a whole document from one script to another in one pass. Free tools exist that do exactly this for Indic scripts.
The catch is in the word mostly. A mapping between two scripts is almost never perfectly one-to-one, because the two writing systems were built for different sound inventories. That mismatch is where every transliteration problem lives.
Where the traps are
Three kinds of mismatch account for nearly all the trouble.
1. The target script doesn't distinguish a sound the source does. Classical Tamil, for instance, doesn't natively mark some of the distinctions Sanskrit insists on — aspirated versus unaspirated consonants, certain voiced sounds. To transliterate Sanskrit into Tamil faithfully, you need the extra letters (the Grantha characters) developed precisely to write these Sanskrit sounds in a Tamil context. Miss them and distinct syllables collapse into one, and the pronunciation guidance is quietly wrong.
2. A mark in the source has no clean home in the target. Special signs — nasalization marks, certain accents — may transliterate into something unexpected, or leak through as a stray symbol that has to be handled deliberately rather than left to the automatic pass.
3. Conventions differ. Even where a mapping exists, there are choices: how to render a particular vowel length, whether to use a script's own numerals, how to show a sound with two accepted spellings. These aren't errors so much as decisions — but they must be made consistently across the whole book, or the same word will appear two different ways on two different pages.
None of these is a reason to distrust automatic transliteration. They are simply the places where the automatic pass must be checked and corrected by someone who knows both scripts — the same lesson as proofreading, now applied to the second script.
The workflow that keeps it faithful
The reliable pattern is machine-first, human-checked:
- Transliterate automatically from the verified source script. Never transliterate from an unverified text — every error in the original is faithfully copied into the new script, doubling the correction work.
- Fix the systematic issues once. Settle how the special sounds and marks should map, and apply that decision uniformly, rather than patching word by word.
- Verify against an authority, especially at the mismatch points, and above all for a sacred text, where the transliteration is a pronunciation guide and a wrong letter teaches a wrong sound.
Because transliteration runs from the source text, it has a useful property: correct the original and you can regenerate the second script cleanly rather than hand-editing two copies in parallel. Keep the original script as the single source of truth, and let the second script be produced from it.
How we solved it on the engagement
We treated the original Devanagari as the single source of truth and generated the Tamil from it with an established Indic transliteration engine — never typing the second script by hand. Two decisions made it faithful. First, we pre-normalized the source so the special marks the engine handles badly (a nasal sign that would otherwise leak through, for example) were resolved to clean, mappable characters before transliteration. Second, we fixed the script-mismatch points systematically — ensuring the Sanskrit-only sounds picked up their correct Grantha letters, and settling the convention choices (numerals, vowel lengths) once for the whole book so no word appeared two ways. The Sanskrit scholar who verified the original then checked the transliterated output at exactly those mismatch points, because there the letters are a pronunciation guide and an error would teach a wrong sound. When the source was later revised, we simply regenerated the Tamil rather than re-editing it — the payoff of keeping one source of truth.
⚙️ For the hands-on reader
- Use an established transliteration engine that supports the specific script pair and its extended letters; don't hand-roll a character map for a real language.
- Handle stray or leaking marks by normalizing them in the source before transliterating (e.g. resolving a nasal sign to a plain anusvāra), so the engine sees something it can map cleanly.
- Decide the conventions (numerals, vowel-length spellings, ambiguous sounds) up front and record them, so the whole book stays internally consistent.
- Always transliterate from the corrected source, and regenerate rather than hand-edit when the source changes.
Takeaways
- Transliteration carries the sound into a new script; translation carries the meaning into a new language. A prayer book mostly needs the former.
- Transliteration is rule-based and largely automatable — but no two scripts map perfectly, so the automatic pass is a draft, not a finished result.
- The traps cluster at mismatches: sounds the target lacks (needing extra letters), marks with no clean home, and convention choices that must be applied consistently.
- Always transliterate from the verified original, fix systematic issues once, and verify the mismatch points with someone who knows both scripts.
- Keep the original as the single source of truth and regenerate the second script rather than maintaining two by hand.