字幕大王流翻訳原稿作成方法その2

2022年3月28日

字幕大王流翻訳原稿作成方法その1の続きである。

前回で、とりあえずは、原文翻訳文混じりの原稿を作成し、翻訳文のみを表示することができた。次の課題としては以下である。

複数の翻訳者がおり、基本的には担当箇所を分割して作業するのだが、他の担当者の進捗をすぐに見ることができ、あるいは言葉の選び方を見ることができ、そのちょっとした誤字脱字を発見したら、その担当者に断らずに勝手に修正することができる。

すなわち、複数の翻訳者がいて、それぞれの担当箇所(複数部分、例えば、第一章と第三章と第十章といった具合)について、複数のファイルをそれぞれ作成していく。そして、自身の担当部分のみ見ていれば良いのではなく、他者の担当部分も参照し、言葉の選び方を検証したり、ちょっとしたミスを見つけた場合には、その担当者に断らずに勝手に修正できてしまうシステムが欲しい。

そんなことができるのだろうか?と言えば、少々ややこしくなるが、これができるのだ。

こういった共同作業というのは、かなり以前からプログラマが行ってきたことなのである。プログラマは、その担当部分について複数のファイルを作成するが、他の担当者がそれを見なければならない場面、それを変更しなければならない場面が出てくる。そうやって、複数の者が、同時に大量のファイルを編集して、大規模なプログラムが作られていく。

この種のシステムは、総称してバージョン管理システム(Version Control System~VCS)と呼ばれるのだが、今現在プログラマのみならず、ウェブエンジニア等も日常的に使っているVCSの一つがgit(ギット)と呼ばれるものだ。これは元々、Linuxの創設者のリーナス・トーバルズが、そのプログラムを管理するために作成したものだ。

オンラインストレージとの比較

gitに行く前に、オンラインストレージを見てみる。Dropboxが代表格であるが、ちなみにエドワード・スノーデンがDropboxを警告していたことを書き添えて置く。Dropboxにファイルを置くと、それはすべて見られてしまうということだ。

Dropboxや他のオンラインストレージの仕組みとしては、どこかにオンラインストレージのサーバがあり、複数の人間が、その同じオンラインストレージに接続することにより、そこにあるファイルを共有できることになる。

さて、Dropboxで他者とファイル共有することを考えてみると、これはまさに上で書いたことのように思えるだろう。Dropbox上に複数のファイルがあり、それぞれの担当者が決まっているものとする。互いに互いのファイルを見ることができ、修正することもできる。

しかし、この手のオンラインストレージで問題な点は、例えば、ある一つのファイルについて、同時に複数の人間が編集して、セーブを行った場合、後にセーブした方が勝ってしまい、前にセーブした内容は消えてしまうことだ。この仕組みでは、あくまでファイル単位にしかセーブできないからである。AとBがファイルXを同時に編集し、Aが編集内容を先にセーブすると、Dropbox上はAの編集状態になるが、その後でBがセーブすると、Aの編集内容は消えてしまい、Bの内容になってしまう。

だから、この種のオンラインストレージを複数で使う場合には、基本的に作り手と受け手が明確に分かれている必要がある。ある一つのファイルについて共同作業はできないのである。

VCSのやり方

Dropbox等とは異なり、VCSの場合には、以下ができる。

  • 複数の人間が同じファイルを同時に編集してもよい
  • 編集の履歴がすべて残る

例えば、AとBが、Xという同じファイルを編集したとする。Aは、そのファイルの担当者で、翻訳を追加していく、Bは、Aがそれ以前に書いた部分を検証して誤字脱字を修正していくとする。この場合、AとBが、仮に同時に編集してもどちらの編集結果も残される。ファイルXに対するAの修正とBの修正が「マージ」され、適切な形になる。

※ただし、AとBが同時に同じ行を編集してしまうと、「衝突」という状態になる。VCSはどちらの編集を採用して良いのかわからなくなるからだ。この場合は特別な作業が必要になる。

簡単に言えば、ファイルを「ファイル単位」で扱うオンラインストレージに対し、VCSでは「ファイルの中の行単位」で扱っているというイメージだ。

さらに、VCSの場合には、誰がどんな編集を行ったか、その履歴がすべて残される。例えば本日、AとBが上述の作業を行ったとすると、本日分の履歴として、「Aがどこにどれだけの追加をした」「Bがどこをどんな風に修正した」が残されるのである。この履歴は、第一日目から無限に残されていく。

そして、×月×日の時点ではどうだったかを見ることもできるし、いつ誰がどんな修正をしたかを見ることもできる。

翻訳文の場合には、てにをはの間違い程度なら許されるだろうが、プログラムでは、一文字でも間違えると致命的なバグになりかねない場合がある。そのため、厳格に「誰が、いつ、どこをどう直したのか」がすべて記録されるようになっている。

※特に、PHP、Ruby、Javascriptといったスクリプト言語の場合には、ほんのわずかな間違いも機械的に検出することができない。例えて言えば、「スペルチェッカーが無い」状態だ。そのため、こういった言語では、基本的に一文字のミスも許されない。

VCSの必須事項

VCSで扱われるファイルは、「ただのテキストファイル」である。そして、VCS内部に記録される履歴としては、何行目の前あるいは後に何を追加したか、何行目をどう変更したかという具合になる。基本的に、「行」という概念を持った文字列の並びでなければいけない。

VCSには、テキストのみならず、画像や音声なども格納できるのだが、その一部を変更したとしても、変更履歴には変更部分がどこなのかは記録されない。例えば、音声ファイルの一部を編集したとしても、「何分何秒から何秒分変更した」という履歴はとられない。単にファイルまるごと変更されたことが記録されるだけだ。

そしてもちろん、VCSではWordファイルの変更履歴を扱うことはできない。Word自体には、こういった変更履歴を格納しておく機能があるようだが、VCSから見れば、それには何の意味も無い。

まとめ

ということで、まとめると以下になる。

  • 複数の翻訳者の複数のファイルを誰でも閲覧、編集できるようにしたい
  • 誰がいつ、どんな追加・修正をしたのか、その履歴をすべて残したい

という目的のために、gitというVCSを使うことにするが、その前提条件としては、

  • 単純なテキストファイルで翻訳文を書いていくこと

次回は、具体的にgitシステムを入れてみることにする。

字幕大王流翻訳原稿作成方法その3に続く

未分類

Posted by ysugimura