タイムスタンプを変更せずにSRTファイルを翻訳する方法

速答: キューテキストを翻訳し、IDとタイムコードを固定する

SRTファイルは時刻付きデータファイルであり、装飾的なタイムスタンプ付きの文字起こしではありません。翻訳するのは字幕テキストだけです。各キュー番号、タイムスタンプ、空白の区切り行、対応する書式タグはそのまま保持し、動画を確認する前にソースと翻訳後のキュー構造を比較してください。

ファイルを意識したワークフローでは、字幕を構造のないテキストボックスに貼り付けるのではなく、元のファイルをSRT Translatorにアップロードしてください。ファイルを認識することで構造上のリスクは減りますが、それでも出力結果をソースと動画に照らして検証する必要があります。

見落とされがちなルールはこれです。タイムコードの保持は必要条件ですが、それだけでは十分ではありません。翻訳後のキューがタイムスタンプを完全に保持していても、訳文が長すぎて読めない、句の切れ目が不自然、まだ登場していない話者を指している、といった理由で失敗することがあります。

SRTファイルの構造

一般的なキューは4つの要素で構成されます:

17
00:00:41,500 --> 00:00:44,200
<i>MAYA:</i> The total is €1,249.50.

1. 17 はキュー番号です。
2. 00:00:41,500 は開始時刻です。
3. 00:00:44,200 は終了時刻です。
4. 残りの行が表示されるテキストです。

SRTでは通常、秒とミリ秒の間にコンマを使い、開始と終了の間に --> を使います。キューと次のキューの間は空行で区切られます。多少の揺れを許容するプレーヤーもありますが、信頼できる翻訳ワークフローはそうした許容に依存しません。

合成データのSRT translation stress testをダウンロードしてください。会話文、イタリック、話者ラベル、日付、通貨、CJKテキスト、アラビア文字、キリル文字、アクセント付きラテン文字が含まれています。内容は架空のものなので、パーサーやエンコーディングのテストに安全に使えます。

コピーペースト翻訳がSRTファイルを壊す理由

汎用的なテキスト処理の流れでは、構造を内容と取り違えることがあります。よくある失敗には次のようなものがあります:

• キューIDを翻訳または振り直してしまう;
• タイムスタンプの区切り記号や小数点コンマを変更してしまう;
• 短い2つのキューを1つの段落に結合してしまう;
• 繰り返しのキューや一見空に見えるキューを落としてしまう;
• ファイル全体をMarkdownフェンスで囲んで返してしまう;
• 話者ラベルを地の文として書き換えてしまう;
• <i> タグを削除したり、未対応のリッチテキスト記法を出力したりする;
• 空白のキュー区切りを折り返し行に置き換えてしまう。

言語的に優れた翻訳であっても、プレーヤーが解析できなくなれば使い物になりません。

手順ごとの翻訳ワークフロー

1. 原本を保持する

元のSRTは変更しないでください。interview.en.srt → interview.es.srt のように、言語ラベル付きのコピーで作業します。

2. ソースが解析できることを確認する

翻訳前に、字幕エディタまたはプレーヤーでソースを開いてください。すでにタイムコードの重複、区切り欠落、動画とのオフセット不一致があるなら、まずその欠陥を修正するか記録してください。

3. エンコーディングを検出する

納品仕様で明示的に別指定がない限り、多言語出力にはUTF-8を使用してください。YouTubeの文字起こしガイダンスでは、英語以外の文字起こしファイルはUTF-8でエンコードすべきとされています。これは国際的な字幕ファイルの基準として妥当です（YouTube Help).

4. 構造フィールドを固定する

キュー番号とタイムスタンプ行は保護対象として扱ってください。ツール側で固定できない場合は、小さな単位で翻訳し、各バッチの後に必ず検証します。

5. 前後の文脈付きで完全なキューを翻訳する

表示テキストを翻訳しますが、前後のキューも文脈として提示してください。字幕では1つの文が複数のキューにまたがって分割されることが多く、単独で翻訳すると時制、代名詞、語順がちぐはぐになりがちです。

6. 訳先言語に合わせて再分割する

リタイミングの権限がない限りキューのタイミングは維持しつつ、キュー内の改行位置は訳先言語に合わせて調整してください。冠詞、前置詞、名前、強く結び付いた動詞句の直後ではなく、自然な句の境界で区切ります。

7. 構造検証を実行する

ソースと翻訳後について、キュー数、ID、タイムスタンプ、順序、タグ、空白区切りを比較してください。言語レビューの前にこれを行えば、読み込めないファイルに対してレビュー担当者が時間を浪費せずに済みます。

8. 翻訳後トラックを通しで確認する

自動チェックでは、字幕が話し始める前に表示されていないか、重要な画面上テキストを隠していないか、速い掛け合いでも読めるかまでは判断できません。

改行、イタリック、話者ラベルを保持する

訳先の構文が変わる場合、ソースの改行を機械的に保持してはいけません。キュー自体は保ちつつ、訳先言語で読みやすい改行位置を選んでください。

たとえば、次のソースの改行はよくありません:

We approved the proposal
after the final review.

訳先言語では条件節が先に来るなら、自然な改行位置も変わる可能性があります。目標は意味のまとまりを保つことであり、ソースの行をピクセル単位で一致させることではありません。

意味のあるイタリックは、出力先で対応しており、かつスタイルガイドで必要とされる場合にのみ保持してください。話者ラベルは一貫して保持します。YouTubeは文字起こしワークフローで、音には [music] のようなキュー、話者識別には >> を推奨しています（YouTube Help);

キュー数とタイムスタンプ順序を検証する

次の不変条件テーブルを使ってください:

ファイルサイズを代用指標にしてはいけません。翻訳による膨張で訳文ファイルは大きくなり得ます。バイト数が近いことは何の証明にもなりません。

字幕を動画と照合する

通常の再生速度で確認し、特に次の難所を含めてください:

• 最も速い会話;
• 2人の話者が素早く交互に話す場面;
• 名前、日付、通貨、測定値;
• シーン切り替えをまたぐ会話;
• 看板やローワーサードと競合するテキスト;
• 歌、効果音、画面外の声;
• 最初と最後のキュー;
• 対応する各書式タグを含むセクションを少なくとも1つ。

構造検証の後は、subtitle translation QA checklistを使って可読性と分割を評価してください。

よくあるSRTエラーと修正方法

すべてのタイムスタンプを保持すべきでない場合

ソースのタイミングに欠陥がある、訳先言語で大きく異なる分割が必要、または動画自体が再編集されている場合は、タイムスタンプ保持を約束してはいけません。そのようなケースでは、監査用参照としてソースを保持しつつ、明示的にリタイムした翻訳後トラックを作成してください。

タイムスタンプ固定は翻訳上の制約であって、字幕作成そのものの代替ではありません。

FAQ

SRTファイル内のテキストだけを翻訳できますか?

はい。キュー番号、タイムスタンプ、区切りを保護したままテキスト行を翻訳してください。そのうえで、すべてのソースキューに対して意図した訳文キューが1つずつ残っていることを検証します。

翻訳後の字幕は同じキュー数であるべきですか?

タイミングが固定されているなら、はい。件数が異なるのは、キューが結合、欠落、分割された強い兆候です。専門的なリタイミング作業では意図的に件数を変えることもありますが、それは記録されているべきです。

タイムスタンプを変えずに改行だけ変更できますか?

はい。改行はキューのタイミングではなく、表示テキストの一部です。訳先言語の自然な句の境界へ移動してください。

翻訳済みSRTファイルにはどのエンコーディングを使うべきですか?

多言語テキストではUTF-8が最も安全な既定値です。文書化された納品システムで要求される場合にのみ、レガシーエンコーディングを使ってください。

翻訳したSRTは読み込めるのに、見た目がおかしいのはなぜですか?

解析できることと適切に表示されることは別のテストです。ファイル構造は正しくても、キューが長すぎる、分割が悪い、動画の版に対してタイミングが合っていない、またはプレーヤーのフォントスタックで未対応である可能性があります。