What Language Is a Roman Urdu Subtitle File?

You have made a Roman Urdu subtitle file. Now something asks what language it is in, and neither obvious answer is right. Urdu implies the Nastaliq script a reader will not find in the file. English is not what the words are.

There is a correct answer, it has been standardised for years, and almost nobody uses it.

Roman Urdu is not a language. It is a script choice.

That distinction is the whole solution. Urdu is the language. Nastaliq and Latin letters are two ways of writing it down. Language tags were built to express exactly this, through a script subtag that sits after the language.

So Roman Urdu is ur-Latn. Romanised Hindi, the written form of what people call Hinglish, is hi-Latn. The four-letter script code comes second, after the language and before any region.

This is the documented use, not a workaround

The W3C guidance on choosing language tags says a script subtag belongs in a tag when the script adds useful distinguishing information, and gives as its example that one might tag Russian transcribed into the Latin script as ru-Latn. Roman Urdu is the same situation with different letters.

The same guidance offers uz-Arab, Uzbek written in Arabic script, and offers it specifically as a subtitle case. So this is not a clever reading of the standard. Subtitles in an unexpected script are one of the situations script subtags exist for.

The rule cuts the other way too. English carries a suppress-script flag, because English is written in Latin letters and saying so adds nothing. en-Latn is noise. ur-Latn is information.

Why the wrong tag costs you something

Tagging Roman Urdu as ur tells a player, a platform and any automated system that the track is in Urdu script. A viewer who chose Urdu because they read Nastaliq gets Latin letters instead. They are not being served the thing they asked for.

Tagging it en is worse in a different way. The words are not English, so anything that acts on the tag, a translation pipeline, a language filter, a search index, is now working from a false premise.

With ur-Latn, both readings are correct. Systems that understand script subtags do the right thing, and systems that ignore the subtag fall back to Urdu, which is at least the right language.

Where the tag actually goes

In HTML, a text track carries it directly:

<track kind="subtitles" src="captions.vtt"
       srclang="ur-Latn" label="Roman Urdu">

Media servers and players that pick subtitles up from filenames expect the tag between the name and the extension, so episode.ur-Latn.srt follows the same pattern as episode.en.srt. Support for the script subtag specifically varies by player, so check yours rather than assuming.

The labelis worth attention too. It is the text a viewer reads in the subtitle menu, and it is free-form. "Roman Urdu" tells your audience what they are choosing far better than any code would.

When the platform will not let you

Plenty of upload forms offer a fixed language dropdown with no script variants in it. If Roman Urdu is not on the list, pick Urdu and move on. The file is still correct, the label in your own player can still say Roman Urdu, and you have lost nothing you could have kept.

What is worth avoiding is choosing English because the letters look familiar. That is the one option that makes downstream systems confidently wrong.

To make the track in the first place, the Roman Urdu caption generator produces one you can review, and the spelling checker will settle the words your file spells more than one way, which matters more in romanised text than in any script with a fixed orthography. Both run on the same caption generator, so the script choice is a starting point rather than a separate tool.