Check an Arabic SRT file

A cue is a number, a timing line such as 00:00:01,000 --> 00:00:03,000, and its text. The file has none, so there is nothing to check. It may be empty, may not be an SRT file, or its timing lines may be damaged.

Some bytes cannot be read as UTF-8, so they appear as � on screen. Arabic subtitles saved by older Windows programs are often in Windows-1256 instead. Open the original in a text editor with that encoding selected and save it as UTF-8. Characters that were already replaced cannot be restored from this copy.

A � stands in for a character that could not be read, usually after a conversion between encodings. The original character is already lost in this copy, and no tool can restore it. Export the subtitles again from their original source as UTF-8.

Strings such as Ù…Ø±Ø usually mean UTF-8 Arabic was opened as Windows-1252 (or Latin-1) and saved that way. If the file was only opened wrongly, reopen it as UTF-8. If it was saved afterwards, go back to the original; a text editor can sometimes reverse the damage, but no tool can promise to.

Each cue needs a number, a timing line, then its text. A blank line inside a cue ends it early, and the text after the blank line becomes a separate block with no timing. Players skip such blocks or stop reading the file.

A timing line must look like 00:00:01,000 --> 00:00:03,000: hours, minutes, seconds, a comma, then milliseconds, on both sides of the arrow. Players may skip the cue or stop reading the file.

The end time is earlier than the start time, so the cue can never be shown. Players skip it, and some stop reading the file. Correct the two times.

The start and end times are the same, so the cue would appear for no time at all. Give it a duration or remove it.

A blank line must separate cues. Without it, players read the two as one cue or drop the second. Add a blank line before this cue’s number.

This file starts with a UTF-16 byte-order mark. Many players and platforms expect UTF-8, so save a UTF-8 copy before you use it. The other results come from reading it as UTF-16.

The cue has a timing line but nothing to show. Players display nothing, and some editors reject empty cues. Add the text or delete the cue.

Each cue should have its own number. Players usually ignore the numbers, but some tools use them to order or match cues, and a repeated number often means a cue was pasted twice.

Numbers should count 1, 2, 3 and so on. A gap usually means a cue was deleted by hand. Most players ignore the numbers, but some tools rely on them. Renumber the file in your editor if it matters.

The line before the timing line should be the cue number. Players usually cope without it, but strict tools may reject the file.

Standard SRT writes times as HH:MM:SS,mmm with a comma before the milliseconds. A period, a one-digit hour or fewer than three millisecond digits is read by some players and rejected by others.

A cue starts before the one before it has ended, so two cues can be on screen at once. Players handle this differently: some stack them, some hide one. Make the cues follow each other, or confirm the overlap is intended, for example for two speakers.

Cues should be in time order. Some players stop reading at the first cue that goes backwards in time.

Cues with many lines cover the picture and are hard to read in time. The limit is a rule of thumb set by the limits above; change it to match your style guide.

Long lines run off small screens or force a player to wrap them unpredictably. Characters are counted without diacritics, invisible characters or tags such as <i>.

Text that stays on screen too briefly is hard to read. Characters per second is a rule of thumb, not a standard, and the right limit depends on your audience and platform. Lengthen the cue or shorten the text.

Direction controls such as RLE, LRE, RLI, LRI and FSI start a stretch of text that a PDF or PDI must close. An unclosed or stray control can make a player lay out the rest of the cue in the wrong direction.

LRO and RLO force the order of letters whatever their language, which can reverse or scramble text. Subtitles almost never need them.

LRM, RLM and ALM are invisible marks that steer direction. Inside a word, or repeated in a row, they usually come from copy and paste and can make a player reorder the text. A single RLM at the start or end of an Arabic line is normal.

Many players decide a line’s direction from its first letter. An Arabic line that starts with a Latin letter may be laid out left to right, which moves punctuation and reorders the words. An invisible right-to-left mark (RLM) at the start of the line often prevents this. The checker cannot know how your player will draw the line.

When an Arabic line ends with Latin letters or digits followed by punctuation, some players draw the punctuation on the wrong side of the line. An RLM after the punctuation often prevents this. Check the line in your own player.

Arabic has its own question mark, comma and semicolon (؟ ، ؛). The Latin forms ? , ; next to Arabic letters look inconsistent and are the marks that most often jump to the wrong side of a line.

Zero-width spaces, soft hyphens, control characters and similar marks are invisible but still characters. They can break line wrapping, search and spell checking. A zero-width joiner or non-joiner is sometimes intended; the others rarely are.

A line made mostly of question marks usually means the text was converted to an encoding without Arabic letters, and the letters became ? at that moment. They cannot be restored from this copy: go back to the original file. If the question marks are intended, ignore this.

The file has no Arabic letters, so the direction checks were skipped. The structure, timing, length and invisible-character checks still ran.