目次
[HOME]

TES4:OblivionのMod翻訳方法メモ

はじめに

 Modの翻訳に興味がある方向けの資料として、私の翻訳の手順をメモしておきます。 コンセプトは『フリーソフトだけでオーソドックスな手法で行う』です。 色々実践的な範囲で必要な情報もまとめました(間違っている恐れもあるけど)。 参考になるならばどうぞ。
尚、2011年に現状に合わせて修正を行いましたが、 以前のもの(2007年に作成)も資料として残してあります。 原則を知る事は応用に於いて絶大な効果が有ります。 よって、翻訳やMod作成を続けていこうという人は古い記事も目を通しておくと良いかもしれません。

翻訳方法の概要

 『翻訳Modの作成』の流れのサブカテゴリの順番は、以下の詳細説明を読む前に頭に入れておくと実際の手順を理解するのに理解しやすくなるでしょう。
 ここでは幾つかソフトを使います(フリーソフトのみ)。 入手等は一番下の必要/便利なソフトから可能です。 勿論同等の処理を自分で出来るならばここで紹介したソフトを用いなくても構いません。

目次

略語

翻訳Modの原理

はじめに

 『翻訳Modの原理』は単純に言えば『海外言語データを日本語に置き換える』事です。 ごくまれに『日本語化パッチを入れれば全部日本語になる』と誤解する方が居ます。 大抵は『日本語化パッチに翻訳済みデータが入っている』と誤解しているのでしょうが、 『日本語化パッチ内に翻訳を行う小人さんが居て自動的に訳している』 という感じに考えている節がある人が時折現れるのはいやはやとは思わなくも無いですけど。
 さて、Oblivionのゲームの仕様上で『日本語に置き換える』には幾つかの方法が有ります。 それを理解しておけば以下の流れも分かりやすくなると思うので先ず最初に解説しておきます。

基本的方法

 公式ToolのCSのみでも実現できる方法です。

基本的方法01

 典型的な例であるJPWikiModを例に挙げます。 画像での説明で一目瞭然の様に、Oblivion.esmのデータを上書きする形になっています。 ゲーム開始時のLoadは全てのesm/espを読むと推測され、しかも日本語Modの上書き範囲は広範に渡るので、 ゲーム開始時のLoad時間はとても長くなります(試しに日本語Modを外せばすぐに分かります)。
これはCSではesmファイルを編集できない為こうせざるを得ないのです。

基本的方法01'

 さて、次はModの例です。 Modの実装形態は2種類あります。 esmファイルによるものとespファイルによるものです。 esmファイルによるModは上述の通り、CSでは編集ができません。 そこでJPWikiModと同じように追加でespファイルを作成する事になります。 構造がちょっと複雑になっただけで原理はJPWikiModと全く同じです。
 ここで『CSじゃesmが編集出来ないのになんでesmなModがあるの?』ということに気付いた方は鋭い。 実はesmファイルを編集/作成する方法は存在します。 ですが公式ToolであるCSだけでは不可能で有志によるToolを導入して初めて可能になるとだけここでは述べておきます。

基本的方法02

 espファイルによるModはCSでの編集が可能です。 ならばespファイル内のデータを日本語に書き換えるだけで翻訳Modができちゃいます。 この方法だと重複するデータがなくなるのでJPWikiMod(及びその派生版)で顕著に現れるようなLoad時間の増加はかなり防ぐ事ができます。 但し、オリジナルのespファイルを修正する事によるデメリットも生じます (特に配布時に影響する。補足:日本語化のデータの配布方法にまとめ有り)。

イレギュラーな方法

 公式ToolのCSだけでは実現できない方法です。

イレギュラーな方法01

 さて、以上が基本的な翻訳Modの構造になる訳ですが、その他にも方法は有ります。 先ずは『esmファイル自体を編集する』という方法です。 『CSでは編集できない』のであれば『CS以外で編集する』、若しくは『CSで編集できるようにする』という方法でこれを実現できるのです。 画像が基本的方法02のFig.3とほぼ同じですが、実際、仕組みは全く同じです。
 この方法のメリットはesm/espファイルの数を節約できる事と読み込みデータ数を減らす事によるゲーム開始時のLoad時間の短縮が挙げられます。 デメリットはesmに修正を行う事になる為、翻訳Modの提供や利用時に若干不便さが発生する事です (補足:日本語化のデータの配布方法に或る程度まとめ有)。
 この手法はこの文書では扱う内容ではないので詳しくは触れませんが幾つかの実際的方法を書いておきます。
『TES4Editで編集する』(esmファイルの編集も可能)
『Wrye BashやTES4Geckoのesm/espの変換機能を利用する』(espに変換しCSで編集、esmに戻す)

 尚、この方法を行えばOblivion.esm+日本語ModのLoad時間の激増問題を理論上回避できます。 これを実験して公開されている方も居られるので2chのスレッドを探してみると良いかもしれません。

イレギュラーな方法02

 もう一つ、CSのみでは実現できない翻訳手法があります。 それは『espファイルをMasterにする』方法です。 CSはesmをMasterにしたespしか作成出来ないのです。 しかし有志の皆さんの開発力は偉大でして、あるespファイルに任意のespをMasterにするように変更するようなToolが幾つか開発されました。 これを利用すればespファイルで提供されるModもJPWikiModのようにespファイルを追加するだけで日本語化が出来るようになります。 画像が基本的方法01'のFig.2とほぼ同じですが、要するに仕組みは全くそれと同じです。
 この方法のメリットはespファイルを追加するだけでよいので利用者にとっては極めて楽です(但し、ロードオーダーを必ず、『Masterにしたespファイル』→『翻訳Mod』としなくてはならない)。 また、オリジナルのespには修正を加えないのも利点でしょう。 逆に、espの追加はesm/espの数の上限(約255)を圧迫するのはデメリットです。 また、ゲーム開始時のデータ読み込み量が増えるのでLoad時間が長くなると思われます (同じく補足:日本語化のデータの配布方法に或る程度まとめ有)。

どの方法で作成すべきか

 基本的には翻訳したいModの形態にあわせて臨機応変で選択しましょう。 また、利用者の事を考えつつも翻訳者が一番楽な形態を選択するのが良いと思います。 補足:日本語化のデータの配布方法に配布という観点からの比較まとめもあります。
 但しこの文書は初心者向けという観点から、基本的手法にのみ焦点を絞りイレギュラーな方法の解説は行いません。 イレギュラーな手法を行いたいとしても、先ずは基本的な事を押えるべきですし、それを押えれば解説など無くとも イレギュラーな手法を理解及び実行できると思うからです。 その辺を踏まえたうえでこの文書をお読み下さい。

翻訳Modの作成

 Oblivionの翻訳を行う際の手法は色々進歩を遂げています。 この項では2011年時点での推奨方法を解説します。
 尚、段階毎のナンバリングが飛び飛びだという事に気付いた方が居られるかもしれません。 これは従来の手法からやらなくて良くなったものを除外したからです(つまり、抜けている部分だけ楽になった!)。 従来の手法も資料として残してありますので比較してみると面白いかもしれません。

[B] 翻訳したいModのテキストデータを抽出

 Mod(単体)のデータを抽出します。

手順

  1. espexportで翻訳したいModと出力ディレクトリを指定し、Export

    espファイル、出力ディレクトリ共にD&Dが可能
    CS:open mod



  2. 出力ディレクトリにExportされているか確認

    開いてチェックしてみる事
    CS:open mod



補足:その他

[D] テキストデータ翻訳

 翻訳は基本的に英文の部分を日本文に置き換えるだけですが幾つか知っておくべき点が有ります。 共通事項として、翻訳作業はShift_JISで行う必要がある事を記憶して置いてください。
 尚、表示例では半角スペースをアンダースコア"_"に置換していますが、 現行の日本語化パッチでは不要な処理である事をここに触れておきます(半角スペースをアンダースコアにするとテキスト処理等で幾らか不便になる)。

手順

Dialogue
Quest Stages
Script Messageboxes
Names
Books
GameSettings
Descriptions
FactionNames

補足:文字化け

解読
 解読するだけなら文字コードを指定して開く事の出来るアプリを利用すれば大体いけます。 文字コードを何に設定するかを試行錯誤する必要がありますが、ISO-8859-1(Latin-1)かWindows-1252にすれば大抵は成功します。 Windows-1252はISO-8859-1のMS的拡張なのでWindows-1252の方の可能性が高いでしょう(大抵はWindowsで開発されているので)。 英語と独語はISO-8859-1(かWindows-1252)でほぼいけます。 仏語、露語等はISO-8859-1(やWindows-1252)では表示しきれない事が有りますがそれでも適切に文字コードを設定すれば文字化けは解消されます(その言語が読めるかはあなた次第)。
文字コードを指定して開く事の出来るアプリには、MS Office、OpenOffice.org及び大抵のWebブラウザが挙げられます。 特にWebブラウザは大抵の環境で導入されている上にかなり広範な文字コードに対応しているので一番手軽かと思います (当該のファイルをWebブラウザにD&Dしてブラウザの読み込み文字コードを弄れば良い)
厳密な解読
 厳密に解読したい場合は文字化けしているファイルをバイナリエディタで開き、文字化け部分の値を調べます。 その後、ありえそうな文字コードで当該の値を検索するのがセオリーです (というか、虱潰しでチェックするという方が正確か)。
 バイナリの値で言えば0x80-0xFF辺りに着目すれば良いです。 Windows-1252とISO-8859-1を区別したい場合は0x80-0x9F付近に着目です。
解読したらどうする?
 基本的に文字化けするものはASCIIの範囲の文字で代用が出来ますのでその様にするのが適当でしょう。 大した量も無いでしょうし手作業で置換して大丈夫でしょう。
やってはいけない事
 文字化けしているファイルを文字化け文字を解読前に編集して保存してはいけません。 必ず文字化け解読後に編集すべきです。 何故かと言うと、文字化けとはエディタ(等のアプリ)が文字コードの判別に失敗している状態であり、 不正確な判定を元に処理する事はオリジナルのデータの変更(バイナリデータの変化)を伴う可能性が高いからです (例えば『あ』という文字であっても、そのバイナリはShift_JISは0x82 0xA0、EUC-JPは0xA4 0xA2、UTF-8は0xE3 0x81 0x82である)。 エディタにも内部処理コードがShift_JISのものとUnicodeの物がありますが、この問題に関してはどちらも大差がありません (内部コードShift_JISの方が可能性として化け易くはなるが)。
文字化けの捜索
 先ず最初に文字化けを発見する事が大事であるのは分かりました。 しかし、その対象データが多い場合は目視での捜索は大変です。 データを翻訳しながら文字化けっぽい部分があったらオリジナルデータを参照するというのはそう悪い戦略ではありません。 ですが、エディタ等によっては文字化けが分かりにくいものも有ります(表示出来る文字が無い時は見掛けをスペースにしてしまう物とか)。 よって厳密を期したいならば他の手をとるべきでしょう。
 ではどうすれば良いのかと言うと、正規表現で検索(若しくはGrep)できるエディタを使います。 ASCIIの範囲の文字ならば日本語環境でも化けない事を利用し、それ以外の文字が存在しないか検索するのです。 ASCIIの範囲の文字を正規表現で表記すると、 [\x00-\x7F] となります。 それ以外の文字を見つけたいので、その否定表現の [^\x00-\x7F] を使って検索すれば良い筈です。 上手く行かない場合は [^\x{01}-\x{7F}] で試してみてください。
何故文字化けするのか

 『英語圏ではASCIIで表現できるんだから文字化けするはず無いじゃん』とお考えの方。 それは間違っていません。 ただし、『ASCIIの範囲の文字を使用しているならば』という条件が付きます。
英語圏ではISO-8859-1(Latin-1)Windows-1252という文字コードが良く使用されますが、これらには 日本語環境で多用されるShift_JISとは異なる文字が割り当てられているエリアがあります これらの文字が使用されるとShift_JISで表示できず、文字化けるのです。 また、日本語環境では文字コード判定の優先度がShift_JISの方が高いのもあるかと思います。
 以下に文字化けの例を挙げます。 例ではHTML上の工夫(文字参照)をしてWindows-1252で使用される文字を表示しています。 一応表示は出来ていますが、本来はシングルバイト文字なのにマルチバイト文字になっています。 これにより文字コードというものが一筋縄では行かないものである事がお分かりになると思います。
 また、その表示できない文字と次の文字が組み合わさって偶然Shift_JISの文字になる事があります。 英文中にいきなり漢字の文字化けが出るのは大抵これです。 しかし、必ず漢字になる訳ではなく、Shift_JISに該当する文字が存在しない組み合わせになる事があり これはその組み合わせやエディタやその設定によって表示が異なります(何も表示されなかったり中黒になったり等)。 寧ろそちらの方が多いかもしれませし、表示されないと言う事は見つけにくい、或いは 字面から判断しにくいという事も覚えておくと良いかもしれません。 その場合は文字コード指定で読み込めるアプリを使うしかありません。
 余談ですが、以下の組み合わせ例で漢字が全て "chi"なのはなかなか興味深いことです (Shift_JIS設計時にそうしたのでしょう)。

Windows-1252とShift_JISでの文字化けの例 Windows-1252の例は日本語環境で正確に表現できないので文字コード上で同等とされる文字で表現。   Shift_JIS (CP932) Windows-1252 (CP1252) ======================================================================  0x82 該当文字なし ‚  0x85 該当文字なし … (正しくは一文字で ... をあらわした物)  0x91 該当文字なし ‘  0x92 該当文字なし ’  0x93 該当文字なし “  0x94 該当文字なし ” ----------------------------------------------------------------------  0x82 0x50 1 ‚P  0x82 0x51 2 ‚Q  0x92 0x6D 知 ’m  0x92 0x6E 地 ’n  0x92 0x6F 弛 ’o  0x92 0x70 恥 ’p  0x92 0x71 智 ’q  0x92 0x72 池 ’r  0x92 0x73 痴 ’s  0x92 0x74 稚 ’t  0x92 0x75 置 ’u  0x92 0x76 致 ’v ----------------------------------------------------------------------  0x82 0x20 該当文字なし ‚ (二つ目の文字は半角スペース)  0x85 0x20 該当文字なし … (二つ目の文字は半角スペース)  0x85 0x21 該当文字なし …!  0x85 0x22 該当文字なし …"  0x85 0x27 該当文字なし …'  0x85 0x29 該当文字なし …)  0x85 0x3F 該当文字なし …? ----------------------------------------------------------------------

 夫々の文字コードの構成の概要は次の通りです。ISO-8859-1の0x80-0x9Fの部分の 制御文字は文章を書くという点ではほぼ無関係と言えます。 よってその領域を記号に割り当てているWindows-1252は実用上、ISO-8859-1の上位互換に 相当します。

ISO-8859-1&Windows-1252&Shift_JIS | ISO-8859-1 | Windows-1252 | Shift_JIS ======================================================================  0x00-0x7F | ASCII領域(共通) ----------------------------------------------------------------------  0x80-0x9F | 制御文字 | 図形文字 | 漢字/記号の1バイト目含む ----------------------------------------------------------------------  0xA0-0xFF | 記号及び特殊アルファベット類 | 半角かな含む ----------------------------------------------------------------------

 元の文字コードが分かれば文字コード変換Toolでの変換も可能です。 但し、日本で公開されているToolの多くは海外の文字コードに対応して無いものが多いです。 コマンドラインツールになりますが、 iconv(Unixの分野で利用されている。WindowsではCygwinやGnuWin32等を導入すると利用できる) が対応文字コードの点では便利でしょう。 但し、iconvはnkfと異なり、文字コード自動判定機能はありません。 以下は全て同じ意味です。

> iconv --from-code=WINDOWS-1252 --to-code=SJIS INPUT.txt > OUTPUT.txt > iconv -f WINDOWS-1252 -t SJIS INPUT.txt > OUTPUT.txt > iconv -f CP1252 -t MS_KANJI INPUT.txt > OUTPUT.txt

 Toolでの一括変換は予期せぬ結果になる事が有るので必ず事後にDiffを取って変換結果を確かめるべきです。 例えば0x85はWindows-1252では ... を1文字で表したものになりますが、これをShift_JISに変換すると …(三点リーダ)に変換されます。 文字コードの変換的には正しいのですが、シングルバイトの半角英数にマルチバイトの 記号が入るのは(少なくとも当方の感覚では)美しくありません。 この場合は素直にドット3つ "..." で置換するのがベストな解決法でしょう。 実際、同じような文でその様な記号が必要な時はドット3つで大抵は記述されています。 つまり、その部分の文を書いた人の(語弊はあるが)ミスであると推測されます。
 ここで一つ注意してください。それは使用するFontにより表示される文字が異なる事があると言う事です。 以下の例をご覧下さい。

■ 三点リーダ  MSゴシック:  Verdana   :  Gulim    : ■ 円記号  MSゴシック:\  Verdana   :\  Gulim    :\ ■ チルダ  MSゴシック:~  Verdana   :~  Gulim    :~ ■ 波ダッシュ  MSゴシック:  Verdana   :  Gulim    :

HTMLソースを見て貰えばお分かりの通り、Font指定が異なるだけで夫々は同じ文字です。 余り大きな問題ではありませんが、一応念頭においておくべきかと思います。 文字化け等の問題は文字集合(文字コード)だけではなくFont(PC設定やFont Link等)やお国柄事情等いろんな要素が絡んできてかなり複雑なのです (Unicodeにおける波ダッシュとその対策等はその良い例)。

 話を本題に戻しまして、実際のOblivionのデータ内でどれだけASCII以外の文字が 使われているのかと言うと、かなり少ないです。 Vanillaなデータではあの膨大なデータ量にも拘らずASCII範囲外の文字が使われた例は数えるほどしかありません(しかし、Fallout 3ではかなり増化していた)。 SIの領域もそんなに目に付きませんでした。 ところが、(品質管理の徹底度がVanillaより低いと思われる)DLCでは そんなにデータが無いにも拘らず文字化け箇所は沢山有ります。 使用文字チェックは適当なScriptでも簡単に出来るような事 ([^\x00-\x7F]でgrepするだけで良い)なのですが それでもそこまで多いのは気をつけないとどうしても混入してしまうと いうことなのかもしれません。 日本語環境であっても場所と場合によって使えない文字記号があります。 それを一応なりとも把握している人は多くない事(半角カタカナ、 丸囲み文字が駄目と言われてもどうして駄目なのか、何処で駄目なのか、 何処なら使っていいのか説明できる人は多くないでしょう) から類推するとどうしようもない事なのでしょう。
 尚、文字化けした英文をそのままにして日本語化パッチを導入した Oblivionで表示すると多分文字化けそのまま出力されるんじゃないかと思います。 日本語化パッチ無しなら多分文字化けしない気がします。

補足:書物の簡易HTML

 CSWiki等を見れば詳しく載っていますが一応抜粋しておきます。
 一つだけ覚えて置いて欲しいのは、この簡易HTMLは実際のHTMLの感覚で使うとはまります。 実際のHTMLとは似て非なるものであり、凝った使い方をしようと考えない方が良いと思います。 まあ、HTMLレンダリングエンジンは案外高度な物なので独自実装と思われるこの簡易HTMLが 色々怪しいのもやむをえないとは思います。
<font>
<div>
<img>
<br>
<p>
<hr>
簡易HTMLモードとプレーンテキストモード
 書籍データは2種類の表示モード(簡易HTMLモードとプレーンテキストモード(共に仮称))があります
その他
実際の表示例 #1

番号指定の場合は日本語化パッチの物が適用される(表示例はIPA P明朝)
Font名の直指定は無視され、番号指定の1のFontが使用される よって、日本語化パッチを入れている環境でFontを変えたい場合は Font名ではなく番号で指定しなくてはならない
fontタグはネストしない

<font face='Kingthings_Regular'>Kingthings_Regular.fnt</font><br> <font face='Kingthings_Shadowed'>Kingthings_Shadowed.fnt</font><br> <font face='Tahoma_Bold_Small'>Tahoma_Bold_Small.fnt</font><br> <font face='Daedric_Font'>Daedric_Font.fnt</font><br> <font face='Handwritten'>Handwritten.fnt</font><br> <br> <font face='1'>Kingthings_Regular.fnt</font><br> <font face='2'>Kingthings_Shadowed.fnt</font><br> <font face='3'>Tahoma_Bold_Small.fnt</font><br> <font face='4'>Daedric_Font.fnt</font><br> <font face='5'>Handwritten.fnt</font><br> <br> <font color='ff0000'> <font color='0000ff'></font> </font> <br> 1<br> 2<p> 3<br> <br> <hr> <div align='right'>右寄せ <div align='left'>左寄せ <div align='center'>真ん中

mHTML:Book2

実際の表示例 #2

imgタグ+brタグだけの行は表示されない
divには終了タグが無い (念の為の検証)。よってネストが無い
fontタグでdivタグの効果がリセットされる

<IMG src="Book/fancy_font/a_70x61.dds" width=70 height=61><br> <IMG src="Book/fancy_font/e_78x61.dds" width=78 height=61> <br> <IMG src="Book/fancy_font/f_59x61.dds" width=59 height=61>F<br> <div align='right'>右寄せ <div align='center'>真ん中 <IMG src="Book/fancy_font/a_70x61.dds" width=70 height=61>A<br> </div> <IMG src="Book/fancy_font/e_78x61.dds" width=78 height=61>E<br> </div> <hr> <div align='right'>右寄せ <div align='center'>真ん中 <IMG src="Book/fancy_font/a_70x61.dds" width=70 height=61><font color='0000ff'>a</font><br> <IMG src="Book/fancy_font/e_78x61.dds" width=78 height=61><font color='0000ff'>e</font><br> <div align='right'> <IMG src="Book/fancy_font/v_63x62.dds" width=63 height=62>V<br>

mHTML:Book2

実際の表示例 #3

fontタグでdivタグの効果がリセットされるが、正確に言えば終了タグでリセットされるっぽい

<div align='center'><font color='0000ff'>A</font><br><font color='0000ff'>B</font>C<br> <div align='center'><font color='0000ff'>A<br><font color='0000ff'>B</font>C<br> <div align='center'><font color='0000ff'>A<br><font color='0000ff'>BC<br> <div align='center'><font color='0000ff'>A</font><br> <font color='0000ff'>B</font>C<br> <div align='center'> <font color='0000ff'>A</font><br> <font color='0000ff'>B</font> C<br>

mHTML:Book3

実際の表示例 #4

書籍データ開始部がタグで始まるならば簡易HTMLモードになるが、タグの前に半角スペースや改行があってもこの判定には影響しない。 但し、開始行のタグの前の半角スペースは表示の上では無視されない。
モード判定のタグは何でも良い。それが簡易HTMLに無いものであっても良い。
連続半角スペースであってもそのまま表示される。 -- (01)
実体参照は利用できない。よって半角の<と>を使用したい場合、簡易HTMLモードは利用できない -- (02)
通常HTMLでのコメント記法が利用できる(但し<と>に挟まれる物は表示しないというルールが適用されている可能性大) -- (03)
通常HTMLでは許される、コメント内のタグ記述は不可能 -- (03b)
通常HTMLでは文法違反な記述もコメント(若しくはタグ)と解釈される -- (03c-03g)
存在しないタグは表示されないが、改行を含めても大丈夫。 但し、>の前には必ず改行以外の何らかの文字が要るっぽい -- (04)
タグの中身が日本語の場合は上記の法則から逸脱する。 文字によっては上手く解釈されない場合がある。 日本語化パッチとの兼ね合いもあるような気もするが法則がいまいちつかめず不明。 コメント記法を含め、日本語をタグ内に記述しない方が安全 -- (05)
タグには>は本質的に不要な気配がある。 即ち<が全てのマークアップを御破算にし1からマークアップを開始するように見える。 -- (07)

<AdoringFan> あいうえお <br> かきくけこ <br> さしすせそ <p> たちつてと なにのねぬ<br> ---------- 01<br> 半角スペース*1<br> 半角スペース*2<br> 半角スペース*4<br> 半角スペース*8<br> ---------- 02<br> &quot;&amp;&lt;&gt; &#34;&#38;&#60;&#62; <hr> ---------- 03a<br> <!-- HTMLコメント(正しい記法) --> ---------- 03b<br> <!-- <font>HTMLコメント(正しい記法)</font> --><br> ---------- 03c<br> <!-- HTMLコメント(正しい記法) --> ---------- 03d<br> <!--HTMLコメント(間違った記法)> ---------- 03e<br> <! --HTMLコメント(間違った記法)--> ---------- 03f<br> <! --HTMLコメント--(間違った記法)--> ---------- 03g<br> <!HTMLコメント(間違った記法)> ---------- 04a<br> <AdoringFan> ---------- 04b<br> <Adoring Fan> ---------- 04c<br> <By Azura, by Azura, by Azura!> ---------- 04d<br> < By Azura, by Azura, by Azura! > <br> ==========<br> <hr> ---------- 05a<br> <たまねぎ><br> <あどりんぐふぁん><br> <タマネギ><br> ---------- 05b<br> < たまねぎ ><br> < あどりんぐふぁん ><br> < タマネギ ><br> ---------- 05c<br> <!--たまねぎ--><br> <!--あどりんぐふぁん--><br> <!--タマネギ--><br> ---------- 05d<br> <onたまねぎion><br> <onあどりんぐふぁんion><br> <onタマネギion><br> ---------- 05e<br> <た まね ぎ><br> ---------- 05f<br> < た ま ね ぎ ><br> ---------- 06<br> <Adoring Fan>TAMANEGI</Adoring Fan><br> ---------- 07<br> > > > > > < < < < < > <br> ---------- 08<br> <Adoring 閉じ忘れ たまねぎ <AdringFan> おにゃぉーん <br> ---------- 09<br> <font color='0000ff'>正常チェック</font><br> ==========<br>

mHTML:Book41

mHTML:Book42

飾り文字
 書物の段落の頭で用いられている装飾アルファベットは画像で実装されています。 以下はその一覧です。
Book/fancy_font/a_70x61.dds Book/fancy_font/b_60x61.dds Book/fancy_font/c_59x61.dds Book/fancy_font/d_80x61.dds Book/fancy_font/e_78x61.dds Book/fancy_font/f_59x61.dds Book/fancy_font/g_68x61.dds Book/fancy_font/h_62x62.dds Book/fancy_font/i_51x61.dds Book/fancy_font/j_60x61.dds Book/fancy_font/k_61x61.dds Book/fancy_font/l_61x61.dds Book/fancy_font/m_65x62.dds Book/fancy_font/n_63x62.dds Book/fancy_font/o_69x62.dds Book/fancy_font/p_59x62.dds Book/fancy_font/q_67x62.dds Book/fancy_font/r_73x62.dds Book/fancy_font/s_61x62.dds Book/fancy_font/t_52x61.dds Book/fancy_font/u_66x62.dds Book/fancy_font/v_63x62.dds Book/fancy_font/w_69x62.dds Book/fancy_font/x_69x62.dds Book/fancy_font/y_62x62.dds Book/fancy_font/z_66x62.dds

補足:その他

[E] importとセーブ

 CSは基本的に日本語表示には対応していません(一部出来る部分も有る)。 これに有志の作のパッチを当てる事で日本語表示を可能にする事が出来ます。
ここで用いている画像のCSは有志作ではなく自分向けに作成したパッチ (文字化けの解消と表示サイズを多少弄る程度)を当てています。

手順

  1. 翻訳データをimportしたいesp/esmファイルをOpen

    espファイルの場合は"Active File"でopenしないとファイルを編集できないので注意
    CS:Knights.espを開く



  2. 作成した翻訳データをimport

    ScriptMessageboxes、Books以外の項目はこれだけでOK
    CS:import



  3. Booksの翻訳を組み込み

    Booksはメニューからimportが可能。 その場合はOblivionディレクトリ中にあるBook Exportディレクトリにimportしたいデータを放り込んで行えばよい。 但しこの場合、書物に対応する物が無いファイルがあった場合はエラーが出る(importファイルは "書物のID.txt"となる)。 またCSの仕様と思われるが、importした書物には冒頭に"<div align='left'><br>"が、行末に<br>が付加される。 HTMLモードを使用したくない場合は邪魔である。 しかも設定等で切る事は出来ない。 これを何とかしたい場合は 『CSから対象の書物を開いて手作業で張っていく』 のがオーソドックスな手法である(面倒だが)。
    そして実はもうひとつ解法があり『CSの 実行ファイルへのバイナリ修正』である。これを行うと上記タグ自動追加機能を殺せるようになる。 この方法はOblivionの日本語化パッチ内の添付文書に有るので目を通すと良い
    CS:book



  4. Named Scriptをセーブ(Compile)

    OblivionのScriptにはNamed Script (CSのメニューから開けるScript Ediorで編集するもの) と、Result Script(QuestやDialogueに付加されるもの)の二種類がある。 先ずは前者から。
    Scriptで押えておくべき共通事項は、 『編集するだけでは変更はゲームに反映されず、セーブ(Compile)しないといけない』 事である。 また、 『必要なデータだけをセーブ(Compile)すべし』 という事も重要である。 これは何故かというと、CS編集時はVanillaなデータもロードされているがそれらを変更しなければ保存時にModには反映されない(これは感覚的に理解出来る筈)。 しかし、Scriptに於いてはセーブ(Compile)を行う事が即ち変更と見做されるのか、Modに保存されてしまうのである。 全くScriptのコードに触れなくても、である。 勿論このModに組み込まれてしまう分は容量の無駄になる訳である。 よって、翻訳データが入っているScriptだけをセーブ(Compile)すべき、という事になる。
    さて、以上の事を押えてようやく以下本題に移る。

    Named ScriptはCSのメニューから開くエディタで編集する。
    CS:ScriptEditor
    この画像でSaveのボタンを押せばScriptはセーブされる。 しかし、右のRecompile Allは押してはいけない。 これを押すとVanilla内の翻訳にも関係ないScriptも含めて本当に全てがModにセーブされてしまうのである。 つまりScriptが重複する事になり、無駄にサイズが増大するのである(大体+3MB)。
    よって基本は、翻訳データの組み込まれたScriptを特定し、一つ一つセーブ(Compile)するのが普通の解法である。 Scriptの特定は上で述べたScriptMessagesのExportデータのフォーマット解説が参考になるだろう。

  5. Result Scriptをセーブ(Compile)

    Result ScriptはScript Editorからは編集もセーブも出来ない。 よってNamed Scriptとは別作業となる。
    Result Scriptは2箇所に有る。 先ずはQuest Stageに付与されているものが一つ (MenuBar → Character → QuestsのQuest Stagesボタン)。
    CS:QuestStages

    もう一つはDialogue(台詞)に付与されているもの (MenuBar → Character → QuestsのTopicsやConversation等のボタン、或いはMenuBar → Character → Filtered Dialogue)。
    CS:Quest Dialogue
    これらも基本はNamed Scriptと同じく翻訳データの組み込まれたものをちまちまとセーブ(Compile)していく事になる。

    Result Scriptも『Recompile All』に相当する方法は有る。 以下の画像の『Recompile All Results』がそのボタンである。
    CS:ResultScritpt
    ただ、こちらの場合はModにそれらのResult Scriptが貼り付けられたQuest(やDialogue)が存在しなければModに組み込まれない様なのでNamed Scriptよりは余り気にしなくても良いかもしれない。 また、Named Scriptの『Recompile All』より警告を出すレベルが甘いように思われる。 これらは本格的に使用したことが無いので当方では未検証。



  6. Modをセーブ

    ツールバーのセーブボタンかメニューバー(File → Save)からセーブして完了。
    翻訳対象がesmの場合は新規espの保存になる。 翻訳対象がespの場合は上書きで良い。



補足:Scriptの簡単なセーブ方法

 さて実際に上の作業をして『どのScriptに翻訳データが入り込んでるのか分かるかっ!』と絶望する方。 Yes yes yes!! 多分みんなそう思っています。 確かにExportしたデータ記載のFormIDやEditorIDを辿ればどのScriptに組み込まれる翻訳文かは当たりを付ける事が出来ます。 しかし、それは極めて面倒でもあります。
そこで、発想の転換、『全部セーブしてVanillaと重複するのだけ削除』しちゃえばいい。 『全部セーブ』は上の『Recompile All』と『Recompile All Results』で出来ます。 では『Vanillaと重複するデータ』の削除はどうすれば良いのでしょう? 方法は3つあります。 『TES4GeckoでClean Plugin』『Wrye BashでDecompile All』『TES4Editで手動で削除』です。

補足:Shivering Islesの有無とScript

補足:OBSE拡張使用のScriptのセーブ

補足:Scriptそのほか

補足:ConstructionSetあれこれ

 翻訳に関わりそうな色々

補足:その他

[F] 公開

手順

  1. 配布するファイルを作成
    補足:日本語化のデータの配布方法としてまとめたので参考の事。
  2. ドキュメントを作成
    翻訳作業者のメモやサポート情報・利用規定・クレジット・オリジナルに関する事の情報等は書くべき。 オリジナルへのリスペクトを忘れずに
  3. 配布アーカイブを作成
    アーカイブ形式(圧縮形式)は作成者の好みで良いが、 圧縮率を考慮しつつ一般的なアーカイバでも対応している形式を選択するのが好ましいだろう (例えばACE形式とか普通に解凍出来る人は多くない)。
    OblivionのMod界隈ではRARや7-ZIPが良く見られる。 7-ZIPは無料で利用できる上に圧縮率も高いので良く使われるのだが 『7-ZIP形式の知名度が比較的高くない』 『圧縮メソッドによっては解凍時にメモリを多量に消費する(PPMdの最高圧縮設定が特にヤバイ)ので解凍環境を選ぶ事がある』 (7-ZIPの公式Toolで圧縮すればメモリ消費量を案内してくれるので要チェック)、 『開発途上の形式なので7-ZIP対応と謳っているアーカイバでも解凍できない事がある』 (特に統合アーカイバプロジェクトDLLを使用せず独自実装をしている物に多い) という点に注意する必要は有る。
    RARはリカバリレコードが使えるので破損に強いが有料ソフト(rar形式だけの為に4,000円弱を高いと見るかどうか)なので元々所持していた場合等以外はお勧めしにくい(展開はフリーソフトでも可能)。
  4. 公開
    お好きな場所に。 問題回避の為に或る程度コントロールできるようにしておく事が望ましい (自分のサイトに置くとか、アップローダでもきちんと削除キーを設定しておくとか)。
    ObMMでウィザード形式にする場合はOblivion Mod ManagerのScriptも参考になるかもしれません

補足:日本語化のデータの配布方法

 方法は幾つか有ります。当方が考えるメリットデメリットを書いておきますので参考にしてください。 尚、基本的にオリジナルModの製作者の意思を尊重するという行動方針で考察を行っています。 作者の意思を考慮しないのであればこの考察は参考にならないと思います。
 世間には色々な人が居ます。
『二次配布?改変?いくらでも勝手にやってくれ!あ、良い改善案有ったら教えてね』
『作った物に責任を持ちたいから配布は全部自分でコントロールしたい…』
『これは俺様のだ。文句は言わせぬ。改変なぞ許さぬ。パクり禁止!パクっただろって?知らんがな』
『俺の大作が狙われている。天災な俺の素晴らしい芸術を奪おうとするヤツが居る。対抗する為に協力してくれないか。夜に教会の裏に来てくれ』
とか。一般論では語りにくいものです。 しかし、創造への敬意を示し彼の意思を尊重する事は、たとえそれがその時点では 面倒に感じたとしても、結果的に関わる全ての人を(色々な意味で)幸せに出来る良い 選択であると信じています。
一般的な注意事項
 日本語化する事でエンバグしてしまった場合、オリジナル作者に苦情、若しくは 悪意が向かう可能性が有る事に注意しなくてはならないでしょう。 日本語化が原因だと気付きづらい不具合も発生する事はありえます(VanillaではNamesのRACEカテゴリの件)。 利用者側での原因の切り分けは恐らく期待すべきではありません。 また、エンバグではなく利用者のミス(例えばバージョンが違うModに適用した、等)であったとしても その様な危険性は有り得ます。
加えて、利用者は案外添付文書を読んでくれないものです。 しかし、だからといってドキュメントを書かない事の理由にはなりません。 最低限の情報は記述しておくべきです。
 尚、二次配布や改変が作者により禁じられているModもあります。 その場合は個人で楽しむ場合を除き、配布を遠慮した方が無難と思われます(「こっそり」等であっても)。 また、二次配布や改変に制限が加えられているにもかかわらず『日本語化ファイルは二次配布とか自由です』という風にしてしまう事も宜しい事ではないと思います。
配布方法:『日本語化したデータをオリジナル作者に提供』
 作者側でリリース状況を完全にコントロールできるのはメリット。 利用者側でも(恐らく)日本語版を作者側から入手できるので楽。 唯一のデメリットはオリジナル作者への連絡。 多分、面倒だって思う人は多いはず。
配布方法:『esm/espファイルだけ日本語化したものに差し替えて全ファイルを配布』
 利用者にとってはAll in Oneなので利用しやすい。 しかし、オリジナルMod製作者の同意を得られるかは微妙な所。 また例えば二次配布されているものにバグが有った場合、オリジナル作者側の行動が多少煩雑になります。 そして、大抵のModは結構サイズが大きいものです。
配布方法:『オリジナルのesm/espを日本語化し、それだけ配布』
 日本語化手法としては基本的方法02イレギュラーな方法01がこれに該当します。
 利用者にとってはちょっと不便。 とはいえ、オリジナルを入れて上書きすれば良いだけなのでそんなに悪くも無いでしょう。 しかし、オリジナル作者側の印象的には微妙なところかもしれません。 最大のデメリットは利用者がバージョンが異なるオリジナルModに 日本語化したファイルを上書きしてしまう可能性がある事です。 バージョンが近ければ大抵は問題は無いでしょうが、 データファイルのディレクトリ構造を一新したりしていた場合は結構大変な目にあうだろう事は想像出来ます。 また、ドキュメントを読まないタイプの人がesp/esmだけ導入して 『まともに動かない』と誤解したりする可能性も有ります。
配布方法:『日本語化したespファイルだけ配布』
 日本語化手法としては基本的方法01'イレギュラーな方法02がこれに該当します。 何が上と違うのかと言うと、 『Modオリジナルなesm/espは弄らずにそれらを参照するespファイルの形で提供する』 事です。
 利用者にとってはちょっと不便。 対象がesmファイルの場合はそう難しくありませんが(JPWikiMod.espが良い例)、 espファイルのModに対しては幾らか困難になります。 それはCSではespファイルをマスターとしたespファイルを作成できないからです (つまり、確実性を保障されている方法ではない)。 Wrye Bash等を用いればespに対するespファイルの作成は出来ます。 しかし、そのようなespファイルをCSで編集するとマスター情報が抜け落ちてしまうので 再度設定する必要が出てきます。
 この手法のデメリットは、利用者がespファイル単体で事足りると誤解する可能性があること、 espファイルへの日本語化espファイルはイレギュラーな方法である事に加え利用者にロードオーダーに対する注意を要求する事 (Masterにしたespより日本語化espファイルは後にすべき)が挙げられます(omodのScriptを使えば提供側でロードオーダーを指定する事は可能。使用者側ではWrye Bashが使える)。 また、重度のMod中毒User(多分褒め言葉)は導入済みesp/esmファイルがかなり多い事が予想され、 仕様上限の255個に近くなっている可能性があります。 そのような場合はこの手法は余り好まれないでしょう。
配布方法:『esp/esmファイルへの差分パッチ形式』
 日本語化手法としては基本的方法02イレギュラーな方法01がこれに該当しますがそれ以外の手法でも使用は可能です。
 利用者にとっては幾らか不便。 特にバージョンが異なると利用できなくなるという部分が嫌われます。 一番のメリットは日本語化espファイルの配布という形式で発生するデメリットの殆どを回避できる事です。 また、『必ずオリジナルのModを作者の公開場所からDLしてくる必要がある』状況にする事で 利用者と作者の接触の機会を設けるという効果も有ります (esm/esp単体のModの場合はこうしないと実現できない)。 付随効果として、ファイルサイズも節約できるので公開側にも優しいです。
デメリットは複数のesm/espを含むModやウィザードが親切で様々な導入形態を 許しているものの場合、パッチ作成労力が増大する事です (例えば5つのespで構成されている場合、5つのパッチが必要になる。 更に『どれか一つ』では無く『要る物だけ入れる』という形で、 ウィザードが親切でマージ化されたespも提供されていたら更に泥沼。 組み合わせの数は 2^5 = 32。流石にこれはオリジナル作者側も厄介だから 無いとは思うが)。
配布方法:『import用テキストでの配布』
 利用者にとっては不便。 利用にはある程度の知識が要求されるのも問題です。 ですが、訓練されたベトコン…じゃなくてOblivionプレイヤーならそれを元にバージョン違いのModにも適用させる事が出来たりするので通には喜ばれる形態

補足:差分ファイル作成アプリ

 差分ファイル(パッチファイル)として公開する場合、以下の必要/便利なソフトで紹介するアプリを使う事になると思います。 ここではその2つのアプリを使用する際の押えておいた方が良い知識に触れます。
WDiff
 WDiffは古くから存在する差分ファイル作成アプリです。 この差分ファイルのアイコンを目にした方も多いのではないでしょうか。 現行版は1998年に作成されたWindows95用の物です。 古い上に現行Windows向けに作成されているものではないとはいえ、そのような不安要因を全く感じさせません。
 このアプリのメリットは、差分ファイル作成やその適用が容易である点です。 差分ファイル作成は最初は迷うかもしれませんが、理解してしまえばほぼワンパターン化できます。 差分適用も差分ファイルを対象のファイルがある場所に放り込んでダブルクリックで完了する明快なものです。 但しメリットばかりではありません。 差分を当てるファイルが大きい場合、『メモリが不足している』というエラーが出てパッチを当てられなくなる事例が報告されています。 これは各個のPC環境に大きく依存するもののようなので根本的な解決は不能と思われます。WDiffは全てをメモリ上で処理するらしいです。 よって旧ファイルと新ファイルのサイズを足した分以上の空きメモリが最低でも必要になるのが理由のようです。 メモリ開放系のアプリで対処してダメなら物理メモリを増やすかしかない気がします。
udm差分ファイル作成ツール
 udm差分ファイル作成ツールは比較的新しい差分ファイル作成アプリです。 これはシェアウエアですが、個人的且つ非営利な利用であれば自由に使えます。
このアプリのメリットはプロファイルを作れる事があげられます。 日本語化パッチは何度も作り直す事が多いものです。 その作業毎にファイルを指定して、設定して…という手間をするのは非常に面倒くさいです。 ところがこのアプリでは差分を作る設定をプロファイルとして保存できる為、そのような作業が極めて容易になります。 また、複数ファイルへのパッチ作成も可能など機能は極めて豊富です。 添付文書に目を通して検討する必要は十分にあります。 デメリットはWDiffの様な操作性(対象ファイルがあるディレクトリに差分ファイルを置いてダブルクリックで完了)は実現できない事です。 基本的にはパッチを使用する人が対象ファイルのあるディレクトリを指定してあげる必要があります。 これはユーザにとってのデメリットになりますが差分を当てる時だけにしか要求されないのでそう忌避するほどの物でも無い気がします。
 WDiffで発生するメモリ問題もこちらに起こるかは未検証です(少なくとも発生するという報告を見た事は無い)。
 尚、このアプリには差分データを圧縮する機能がありますが、それを行わずに配布アーカイブの方で圧縮した方が最終的なサイズが小さくなる事例が多いです(差分ファイル内の圧縮はzlibを使用しているらしいが、7-zip等と比べると劣る面が多い)。

各種メモ

○○のススメ

オリジナル作者への連絡のススメ

 可能な限りした方が良いでしょう。 ドキュメントに『許可は要らないよ』と有っても
『ヘイ、ユーのワンダホーなModをじゃぱにーずに翻訳してるぜ、喜んでくれ!せんきゅー!』
位は知らせてもばちは当たらないと思います。
『りありぃ?せんきゅー!実は私、18のメリケンのハイスクールガールなんだけど貴殿にふぉーりんらぶ!でござる!ハラキリ、ゴクモン、カリフォルニアロールさいこー!』
と翻訳から始まる故意…じゃなくて恋が産まれるかもしれません(効果は人によって異なる事を当社はお知らせいたします)。
 冗談さておき。 大抵の方は翻訳を喜んでくれます。 場合によっては便宜を図ってくれます。 オリジナルの配布所で宣伝してくれる事もあります。
 確かに面倒です。 でも日本語字幕を再度英訳して出来をチェックして駄目出しをした某映画監督みたいな 事を要求するModderは居ないと思うので怖がらなくても良いです。 多分居ないと思う。居ないんじゃないかな。まちょっとは覚悟しておけ。
 作者への敬意という意味で連絡を取る方が望ましいのは確かでしょう。 ただ、それ以上に同じ趣味を持つ人との交流とそれによって得られる物は お互いの貴重な財産になるのではないかと私は思います。

Readmeのススメ

『〜が分からないんだけど?…え?添付文書読め?めんどくさい…』
『添付文書?Mod作るのに集中したいからめどいです』

 いや分かります、その気持ちは。 私だって基本ものぐさですから。 しかし、例えそうであっても最低限の添付文書は書くべきかと思います。
 ライセンスがどうだとかうざったいとか、許可を得ないでやったものだから こっそりしたいとかいう主張も有るでしょう。 でもそれ以後に誰かがその産物を利用したいと考えた場合にその様な言及が無い場合は (普通に判断する場合は)躊躇せざるを得ません。 世の中にはいろんな人が居ます。 意思は言葉にしないと表現できないのです。 そして現実に書かなかったことで起こるツマラナイごたごたが如何に多かった事か。 当事者達が問題にしていないのに外野がもめる事程無駄な事はありません。 それをあなたが故意に起こしたいと思っているのなら別ですが、そうではないでしょう? ちょっとした作業で未来のごたごたの芽を刈り取る事が出来るならめっけものじゃないですか?
 え? それでもめんどくさい? 宜しい、では次に例を挙げましょう。この程度でも多分十分ですよ (行ごとにPOPUPで説明でます)。
■ つくったひと:Adoring Fan ■ ばーじょん :v0.01 ■ リリース  :2011-01-01 ■ らいせんす :作者に断ってないので二次配布とか無しね。shyから流れたらおしまいで ■ れんらくさき:スレで声掛けたら召喚されるかも? ■ びこう   :作者から許可貰ってないの。誰かかわりに交渉してくれたら嬉しいな ■ くれじっと :****(〜さん作)、****(〜さん作)、ありがとー
 自信の有る出来で無いとか事情が有って、とかで再利用とかして欲しくなければ その旨を正直に書いて良いと思います。 口うるさい外野も多いでしょうが、それが不当な理由で無ければ大体の方は 分かってくれます。
 また、文書を書く際は重要な部分に関しては出来るだけ平易な文章にすべきです。 仮に海外の方が利用する可能性が出てきた場合、砕けすぎた日本語では 機械翻訳が効かず、意味が通じなくなってしまいます (例えば『れあdめ』は日本人はすぐわかるでしょうが、海外の人には理解しがたいでしょう)。 伝わらなきゃ意味なんて無いに等しいのです。
 全く別の観点ですが、添付文書を書いているとそれがフィードバックを起こして本来の 生成物に良い影響を与える事もあります (仕様を頭の中から文書という形に変換する過程で仕様の粗が見えてきて 生成物の改善に繋がるというのは良く有る事)。
 世の中にはReadme作成支援ソフトなるものも有るみたいです。 探してみると良いかもしれません(当方は使ってないので詳しい事は不明)。
さあ、皆さんも添付文書道を極めてみませんか?!

Oblivion Mod 翻訳所のススメ

 Oblivion Mod 翻訳所というサイトがあります。 これは当方が管理しているWikiなのですが、コンセプトは『くらえ!じんかいせんじゅつ!!』です。
 最近のModderはかなり精力的な方が多く、翻訳側としてもその膨大なテキスト量を喜びつつも絶望する事があります。 その様な場合、一人でやるよりも皆でやってしまえば良いのです!
 勿論集団作業である関係上或る程度のルールはあります。 しかし、それは翻訳自体を制限するものではなく、集団作業を円滑にするだけの為に存在するものばかりです。
 翻訳の隅々にまで自分の意思を統一させたいというような凝り性の方には向いていないかもしれません。 しかし、自分では紡ぎ出せなかったすばらしい言の葉に見える事が出来るかもしれません。

 Oblivion Mod 翻訳所では有志の参加をお待ちしております。

私的翻訳方針

 既に訳した公式Mod等に適用した方針です。

必要/便利なソフト

 本解説で紹介したプログラム及びその他の有用と思われる物の入手先です。全て無料で利用できます。

Oblivion関連

一般アプリケーション

関連ファイル

関連記事

有用Link

更新履歴