Stop treating your Hindi edition as a translation

Most multi-language news sites are one site with a language switch stuck on top. The English story is the real one; the Hindi version is a field hanging off it. You can tell from the URL — the same slug, in English, with a language code in front. That single detail gives away the whole arrangement, and it costs you readers.

A headline is not a string to translate

A good Hindi headline is not the English one in Devanagari. It uses different rhythm, different length, and often a completely different angle, because the reader arriving at it has different context. If your system only stores one headline with translations attached, the Hindi desk is permanently writing in a box built for someone else's sentence.

The fix is structural: every language version is its own story row, with its own headline, its own standfirst, its own slug, and its own publish state. They're tied together so you can move between them and so search engines understand they're the same piece — but nothing about the Hindi version is downstream of the English one.

Your slug should be in the reader's language

If a reader shares a Hindi story on WhatsApp, the URL is the preview. A slug that reads as the actual headline gets opened more often than one that reads as a transliteration of something else. That means per-language slugs — not one slug reused under three prefixes.

Translation is a starting point, not a publish button

Machine translation has got good enough to be genuinely useful and is still nowhere near good enough to publish unread. The useful shape is: translate into a draft, hand it to someone who speaks the language, let them rewrite the headline and fix the three things the machine got wrong. That's twenty minutes instead of two hours — and it is still a person's byline on a sentence a person approved.

The test is simple. If a reader can tell which language your newsroom thinks in, you have two editions. If they can't, you have one newspaper that speaks three languages.