Start a new topic

Subtitle file upload (re-upload): careful about extension and encoding

 Several queries and requests on this forum and in the tickets concern messed up subtitles that have been uploaded, in particular reuploaded after saving has failed in the Amara tool.

The correct way to do this is explained in three Solutions resources:

  1. How to add existing subtitles, captions, or transcripts to videos;
  2. How do I upload subtitles and transcripts?
  3. I was working on a video but it timed out. How do I save my work?

Two features must be paid attention to, especially in the third case when you save a subtitle file via the so-called "download" link that appears in a dialog box when your work session times out or when you can't save it: extension and encoding.

A) The extension must correspond to the formating

This so-called "download" link opens a text that must be copypasted in a text editor, then saved with the same extension that is indicated in the dialog box. By default, this is DFXP formatting, so you must save the output as a .dfxp file.

  • At times, the dialog box offers a drop list with other formatings - SRT, SBV etc - but if you're having problems saving, i.e. communicating with the Amara server, it's better to cautiously stick to the offered DFXP.
  • If your desktop writing software refuses to save with the proper extension, save as encoded .txt (see B), and then change .txt to the proper extension in the Finder.

B) The file to be (re)uploaded must be UTF-8 encoded

This is particularly important for languages that use accented letters: if the file has a different encoding than UTF-8, these accented letters get messed up on Amara after the upload. And this even obtains in English for some signs like quotes.

How to encode a file in UTF-8 is explained under "Uploading text transcripts" in How do I upload subtitles and transcripts?, and the need to do so also obtains for subtitle files, not just for transcript files.

1 person has this question
Login or Signup to post a comment