Sarmaticus

誰も読まないような趣味の話しかしないほうのブログ

マウントアンドブレード2の言語ファイルの扱いと翻訳方法について



概要

マウントアンドブレード2のmodの翻訳について必要なことを書いておく. 具体的にはこんなトピックを解説する.

  • 公式ドキュメントの間違え探し
  • MB2のmodとモジュールの定義と構成要件
  • MB2のローカライゼーションエンジン, および言語フォルダの挙動
  • MB2のローカライゼーションで使われる特殊記号
  • 言語ファイルとmodule_stringsの違い
  • 私の自作スクリプトについて

この項目を見ると, 翻訳というよりmod作成に関する話のように見えるかもしれない. 実際そうである. modはユーザーがめいめい勝手に作っているため, きれいな実装になっていないmodが多いのが実態である. そのため, いろいろなイレギュラーなmodにも対処できるように, 技術的な話を多く書くことにした.

スクリプト内で使われているテキストの翻訳」は, 重要だが説明しない. これはプログラミング, 特にC#の予備知識が必要なので, ブログでていねいに説明するのは大変であるから, 省略する. 各自で勉強して欲しい.

ここで触れるのは正式版 v1.0.x-v1.1x の範囲の話である. まだベータ版である v1.2 でも特に変更はなさそうなので, 今後も通用するかもしれない. 一方で, アーリーアクセス版の古いバージョンではいくつかの機能がまだサポートされてないことがあるらしいので注意してほしい*1.

こういう情報は, 日本語はもちろん英語でもまとまった資料がない. 今の時点で私以外に日本語翻訳をしている人が皆無なので誰も読まないだろうと思って私も書かないでいた. しかし, 先日ブログに問い合わせがあったので書くことにした. 以降の内容は, 私が実際の翻訳作業やmod作成を通して学習した結論であり, 参考にしている公式ドキュメントのようなものは, ほぼ存在しない.


公式ドキュメントはあてにならない

公式ドキュメントには翻訳に関連する情報は存在しない. かわりに, mod作成者コミュニテイが作成したこのページのみがある. しかし, 重要なことが書いてない上に実態と矛盾している記述もあるため, あまりあてにならない. 2年くらい更新されてないため古くなっている箇所もあるのだろうが, それ抜きにしても本当に書いてあることがおかしい.

https://docs.bannerlordmodding.com/_csharp-api/localization/

とりあえず間違え探しの答えだけ書いておこう. 順番に解説してほしい場合はこのセクションは読み飛ばしてもいい.

Every localizable string should be included in std_module_strings_xml.xml file under ..& Blade II Bannerlord folder.

である. ファイルを配置しただけでは意味がない. languages_data.xml にパスを明記する必要があるが, このページでは全く触れられていない.

Every localizable string should be included in the std_module_strings_xml.xml file under ..\Mount & Blade II Bannerlord\Modules\YourModName\ModuleData\Languages\ Default game language is English and text processor expects every line you define in the code to be English. So creating std_module_strings_xml.xml with <tag language="English" /> will be just for reference

嘘とまでは言わないが, かなり理解が怪しい. 英語以外でも, tag で言語を指定してもほとんど意味がない. 言語ファイルと module_strings を混同しているのではないだろうか?

こんなふうに, 量が少ないだけでなく, 重要なことが書いてなかったり, 完全に実態に反することが書いてあったりするため, 現状はドキュメントとして不十分である.


翻訳作業の流れ

必要な知識を順に解説しながら書く.


modのフォルダ構造

これ以降は実態に即した解説をする. まず, modの基本的な構成要素の話を少しだけする. 通常のMB2のmodは, Modules フォルダーにフォルダとして配置する. そして必ずそのフォルダ直下に, SubModule.xml というファイルが含まれる. SubModule.xml には, mod の名称やバージョン番号など基本情報が書かれている. これがないとMB2のランチャーでmodとして認識されない.

モジュールのフォルダ構造, Agriculture Estateの例

以降では, このような, Modules フォルダにある SubModule.xmlが含まれたフォルダを「モジュール」と呼ぶことにする. 私の日本語修正・校正modのように, 複数のモジュールで成り立っているmodも存在するので, 「モジュール」と「mod」は同一の意味ではないことに注意して欲しい.

次に, ほとんどのモジュールでは同じフォルダに ModuleData というフォルダが置いてある. 翻訳をするときは, 基本的にこのフォルダ内のファイルだけを見れば良い……はずだが, 実際には不備があって他のファイルを見なければならないことがある. しかし今はいったん, ローカライゼーションが適切に整備されたmodを翻訳する場合を想定して話す. そして, 以降はこの Languages フォルダを「言語フォルダ」と呼び, 翻訳文を記入したXML形式のファイルを「言語ファイル」と呼ぶことにする. (これは公式の名称ではない. 説明しやすくするために私が命名した.)

ModuleData の更に下に, Languages フォルダがある. 理想的なモジュールでは, このフォルダ内のファイルで翻訳が全て完結する. Languaage 内のフォルダ構造は自由にできるが, 使いやすさのため慣例的にさらに言語別にフォルダが作られている事が多い. 英語は EN フォルダに入っていることも, 直下に入っていいることもある. language_data.xml がない場合もある. 英語の言語ファイルが統一されていないのは, MB2のローカライゼーションエンジンは言語フォルダにある英語のテキストを読み込まないという仕様のためである.

今回は理想的な状況なので, 英語の言語ファイルも言語フォルダのどこかに置いてあると仮定する. 英語の言語ファイルを JP フォルダ内にコピーする. 言語ファイルは JP フォルダに置くべきである. なければここで作ってほしい. コピーしたXMLファイルには language_data.xml というファイルが1つ含まれているはずだ. このファイルを開いて, 言語IDとファイルパスを変更する. こんな感じになっている事が多い.

<?xml version="1.0" encoding="utf-8"?>
<LanguageData id="English">
  <LanguageFile xml_path="std_module_strings.xml" />
</LanguageData>

ものによっては Language_File タグで指定されているファイルパスが違ったり, Language_File タグが複数あったりするだろうから, 適宜読み替えて欲しい.

これは, MB2の各表示言語に対して, どの言語ファイルを読み込むべきかを指定するファイルである. LanguageData タグに id="English" とあるので, これは英語を選択した時に読み込まれる言語ファイルを指定したことになる. 既に書いたように English を指定しても実際には読み込まれないが, 値を書き換えることで日本語用のファイルに使い回すことができる. 属性の値を書き換えて, id="日本語" とし, さらに, LanugageFile タグの xml_path の頭に JP/ をつける. つまりこんなふうに書き換える.

<?xml version="1.0" encoding="utf-8"?>
<LanguageData id="日本語">
  <LanguageFile xml_path="JP/std_module_strings.xml" />
</LanguageData>

ファイル名を変更しても良い. 重要なのは, xml_path に記入するファイルパスは, Languagesフォルダからの相対パスでなければならないということだ. 逆にこれさえ守っていれば, もっと深い階層に配置しても良い*2. 逆に, 試してはいないが, Languages フォルダより上に配置するとたぶん動作しない.

なお, この説明から予想がつく人もいるかもしれないが, language_data.xml のパスの指定さえ正確なら, 日本語の言語ファイルを JP フォルダ以外に置いても動作する. しかし, 言語フォルダにはいろいろな言語のファイルが置かれる可能性があるので, 混乱を避けるために JP フォルダに置くといいだろう.

次に, xml_path で指定しているXMLファイルを開く. だいたいこんな内容になっているはずだ.

<?xml version="1.0" encoding="utf-8"?>
<base xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" type="string">
    <tags>
        <tag language="English" />
    </tags>
    <strings>
        <string id="hogehoge" text="Eigo Eigo" />
        <string id="hoge" text="This is Eigo." />      
    </strings>
</base>

まずは, <tag language="English" /><tag language="日本語" /> に修正する. 本当は意味がないが, 一見して分かるように一応変更する. <strings> タグ内の, <string> タグが並んでおり, これらが, このモジュールで使われるテキストの全てである. 全ての text= の値を日本語に訳し直せば, 翻訳は終わる. ゲームを起動すれば日本語になっているはずだ. なっていないならXMLの構文がおかしい. 言語ファイルは XMLに書き間違えがあっても通常通りゲームが動作することがあるので気づきにくい.

翻訳の際に1つ注意するなら, 訳文を書き込んでいるのがXMLファイルであることを思い出して欲しい. HTMLと同様に, XMLでは &,<, > などの一部の記号を &amp;, &lt;, &gt; に置き換えなければ, ファイルを読み込む際にエラーが発生する. 翻訳後の文にこれらの記号を使う機会はほとんどないと思うが, 注意しておくと良いだろう.


ファイルの共有方法

翻訳に際して, 他にも知っておいた方がいいことは多数あるが, それらの解説は後回しにして, ここでは一旦, 翻訳が完全にできたと想定する.

作成した日本語ファイルを個人で使用するのだけでなく, 共有したい場合, 共有の場は現時点ではほぼNexusMods一択である. ファイルの翻訳ができるのなら英語が読めるはずだから, NexusModsへの投稿のやり方についてここで細かく説明する必要はないだろう. よって, 最低限の補足説明だけにしておく.

まず投稿する前に確認すべきなのは, 作者が許可しているかどうかである. NexuModsのライセンス規約のフォーマットは不明瞭でかなりわかりにくく*3ため, 改変や再配布に許可がいる, あるいは禁止となっているのかどうか, よく確認する必要がある. さらに, NexusModsの規約では, Nexus内での再配布と外部サイトでの再配布を分けて考えるという, 一般的な著作権の考え方にはない謎の風習があるので, その点も注意する必要がある. いずれにせよ, Nexusでダウンロードしたmodの翻訳ファイルを一般公開するならば, 規約への違反しにくさや, ユーザー側からの使いやすさから見ても, NexusModsに投稿するべきだろう.*4

次に, 技術上の注意点について説明する, 言語ファイルだけでなく, フォルダ構造も元のモジュールと同じようにしたほうが, 手動でもmod管理ツールを使った場合であってもインストールが簡単になる. つまり, 以下のようなフォルダ構造にしてからZIP形式等に圧縮して投稿したほうが望ましい.

言語フォルダのみの上書きを想定したフォルダ構造

フォルダ直下にSubModule.xmlを置くのがモジュールの要件だが, NexusModsではこの要件を満たしてなくとも投稿できる. ちなみにSteamワークショップではできない. 元のモジュールのSubModule.xmlをコピーして持ってくるという方法もあるが, 不要な上書きを発生させることが原因の不具合が起こりやすくなるし, モジュール作者がそういった再配布を許可するかの確認も必要になるため, かなり面倒になる. よって, 規約面でも技術面でも, Steamワークショップで日本語ファイルを公開するのはやりづらい.

最後に, 登録する際に Japanese タグを忘れずにつけておこう. これは必須ではないが, 私は自分がNexusに投稿した日本語ファイル全てに Japanese タグをつけているので, 日本語ファイルを登録するときにはこのタグを付けておいたほうがユーザーにとって便利だろう.

以上が, modの日本語ファイルを作って公開するまでの基本的な流れである. しかし, 実際にはほとんどのケースで, これだけの説明ではうまくできないだろう. というわけで以降は, もう少し応用的な話をする.


IDからテキストが使われている場所を探す

アイテム名ばかりなら翻訳もさほど難しくないだろう. だが, アイテム名なのかNPCの名前なのかわからないとか, 台詞がどこで使われているかわからない, ということもありえる. 人によってはXMLファイルにコメントでヒントを書いてくれる場合もあるが, もちろんそうとは限らない. 全部のテキストに一端仮置きの文字列を入力してゲーム内で確認するのも手だが, 非効率である. そこで, IDに注目しよう.

<string> タグには, かならず id が含まれている. ここに書かれている値を「ローカライゼーションID」と呼ぶ. ローカライゼーションで ModuleData 内を検索すると, そのテキストがどこで使われているかがわかる事が多い. 複数のファイルを検索する時は, Visual Studio Code とか Notepad++ とか高機能なテキストエディタがあると便利だ.

例えばアイテムの場合は, ModuleData フォルダ内の, 言語フォルダ以外のどこかで,

<Item id="sword1" name="{=swordname}Sword 1" mesh="sword_hogehoge_hoge" culture="Culture.hogehoge">
    ...
</Item>

のような記述が見つかる. これはアイテムを定義するXMLである. name="{=swordname}Sword 1" とある. この, {=文字列} の部分がローカライゼーションIDを指定する構文である. MB2のXMLには他にも id= という属性があちこちにあるが, 言語フォルダの外で指定されているIDはローカライゼーションIDとは一切関係ないので混同しないようにしよう. ="{=文字列}なんとかかんとか" のような表記だけに注意すると良い. ここでは, swordname というローカライゼーションIDが, Sword 1 というアイテムの名前に対応するIDということになる. アイテム名ならばあまり迷わないかもしれないが, 勢力名には, 百科事典で表示される正式名称 (title), 通常使われる名称 (name), ログで表示される短縮名称 (short_name), と3種類あるので, こういう確認が必要になるだろう.*5

ローカライゼーションIDが指定される可能性のあるタグと属性は, 以下の通りである.

  • <ItemModifier> タグ (「歪んだ」「錆びた」などのアイテム修飾子): name.
  • <CreftedItem> タグ: name.
  • <CraftingPiece> タグ (クラフトアイテムの部品): name.
  • <Item> タグ: name.
  • <NPCCharacter> タグ: name.
  • <Hero> タグ: text. NPCの百科事典の説明文だけ, Heroタグで独立している.
  • <name> タグ: name. キャラクター作成時や, NPCやクランがランダム生成されたときにランダムで選ばれる名前リストで使われる.
  • <Settlement> タグ: name, text.
  • <Faction> タグ: name, short_name, text. ゲーム内の百科事典では「文化」と表示されるが, 参照されるテキストはFactionタグの内容である.
  • <Culture> タグ: name, text. こちらのtext属性はゲーム開始時の文化選択で使われる. Factionタグと紛らわしいので注意.
  • <Kingdom> タグ: name, short_name, title, text, ruler_title.
  • <string> タグ: text. これは言語ファイルのタグと同じ名前だが, 用途は異なる.「module_stringsについて」で詳細に説明する.

ただし, Europe Campaing Map と Banner Kings, それから Calradia At War (より正確には, CAWだけではなく Custom Spawn API依存のmod全般) は一部のテキストを独自のプログラムで制御しているので, これ以外のタグが使われることがある. これはTextObject というクラスが関わってくる話だ. だが, プログラミングの話は高度なので今回は詳しく話さない.


テキストで使われる特殊な記号

ローカライゼーションIDを指定する構文もそうだが, MB2で翻訳するテキストには特殊な構文がいくつかある. まず, ローカライゼーションIDは, 必ず冒頭に来る. スペースすら挟んではいけない. 文の途中に {=文字列} と書いたり, 言語ファイルに書いたりしても無視される.*6. それ以降でも, {} を使った特殊な構文がいくつか使われる. よく見るのは以下の4つだろう.

  1. {NEWLINE}
  2. {GOLD_ICON}
  3. {INFULUENCE_ICON}
  4. {?...}...{?}....{\?}
  5. {@PLURAL}...{\?}{PLURAL()}

そして, これ以外の {文字列} も多く存在する. 基本的にカーリーブレイスで囲まれた文字列は変数やマクロのようなものと思えば良い. クエスト依頼者の名前とか, 要求するアイテムの数量とか, 報酬の金額とかを代入するのに使われるため, {} 内の文字列は変えたり翻訳したりするべきではない.

(1)は改行コードに置き換えられる. 英文では \n で改行していることが多いが, 翻訳文ではこの {NEWLINE} を使ったほうが無難である.

(2, 3)はそれぞれ金貨アイコンと影響力アイコンである.

(4)は, テキストの内容を条件分岐で変化させたい場合に使われる. 最初の{?…}の部分に条件が入り, この{} から次の {?}までが条件を満たす場合に使用されるテキストで, {?} から {\?} までが条件が偽の時に使用される. バニラのテキストでは, {?IS_FEMALE}She{?}He{\?} のように, 性別で「彼」「彼女」を使い分けるために使われる事が多い. 多くの場合, 条件部分には意味を推理しやすい名称が付けられているが, 厳密にどういう条件なのかを知るにはプログラムを解読する必要がある.

(5)は, アイテム, 特に交易品と馬の名称にのみ使われる, 複数ある場合に名称を変えるための変数である. インベントリ画面では使われないが,「XをY個持ってきてくれ」のようなクエストの台詞でこの記号がよく使われる. 現時点での公式の日本語訳での複数形の扱いは, やはりめちゃくちゃなので, 私は複数形の表記を「頭の馬」「樽のビール」のように統一して訳している. テキスト内で複数形を表示したい時は, {PLURAL(ITEM_NAME)} のように書く. よって, アイテムの数量に言及する台詞を {COUNT}{PLURA(ITEM_NAME)} のような並びにすれば, 「1頭の馬」「10樽のビール」というふうに自然な表現になる.


module_strings について

言語フォルダ外にも, <string id="..." text="..."> というタグが現れることがある. しかしこれは言語フォルダとは異なる. 大抵は std_module_strings.xml のような名前で, かつ言語を指定する <tag> が存在しないことや, text= の冒頭にローカライゼーションIDが書かれていることで判別できる. これは主に, スクリプトが読み込むテキストであり, DLLファイルの入ったモジュールでは, たまにこういうファイルがある.


XSLTファイルについて

XSLTファイルは, XMLを部分的に書き換えるためにMB2がサポートしているファイル形式で, バニラの設定や他のモジュールにの内容を一部だけ変更する時に便利である. 使うべきときに使ってない人が結構いるけど…. ほとんどの場合はアイテムのステータス値を一部だけ変更するために使われており, 翻訳に関係することは稀だが*7, 技術的にはローカライゼーションIDをXSLTで書き換える事もできるので, 完全に翻訳したはずなのに表示がおかしい, という場合は, ModuleDataXSLTファイルが入ってないか確認するとよいだろう. 逆に言えば, ローカライゼーションに問題のあるモジュールのローカライゼーションを修正するのにもXSLTが使えないこともない. ちなみにXSLTが使えるのはModuleData内の, 言語フォルダ以外のXMLに対してのみである. 言語フォルダやGUIフォルダには使えない.

XSLTでできることはかなり多く, XMLとは違い, {=ローカライゼーションID}を探すだけでは完全ではない. しかし, XSLTの構文を全て説明するのは大変なので, 網羅的な解決方法をここで教えるのは難しい. 実態は, そこまで複雑なXSLTを使っているmodを見たことはないので, {=ローカライゼーションID}を検索するだけでなんとかなることが多いだろうと思う.


訳してはいけないもの

テキスト冒頭のローカライゼーションIDが {=!}{=*} と書かれていることがある. これはローカライゼーションIDを割り当てない, という意思表示であり, 訳しても意味がないことになるが, 作者が普通に間違えている場合もある. 私は使ったことがないが, XMLにローカライゼーションIDを自動で割り当てるスクリプトを使っているmod作成者がいくらかおり, そのスクリプトがIDが必要な箇所と判定するために, このような表記が必要になっている場合もある. しかし, そもそも自動割当スクリプトを使うのを忘れてこのような状態のままリリースする作成者もとても多いため, 翻訳が必要な箇所なのかどうかを確実に見分けるのは難しい. 例えば闘技場や酒場で使い回されるNPCは, ローカライゼーションエンジンとは別のプログラムによって, スポーンするたびに名前が与えられるので, 言語ファイルで名前を与えると表示がおかしくなることがある. そういったNPCの名前はたいてい 「dummy なんとかかんとか」のような, 明らかに名前として不自然なものになっていることが多いので, それで区別する. 逆にそういうNPCの名前にローカライゼーションIDと訳文が与えられているなら, 消したほうが良いだろう. 少なくとも, 対応するIDを言語ファイルから消した方が良い.


ローカライゼーションIDが重複したときの挙動

MB2のモジュール読み込みルールはかなり変である. MB2では, XMLファイルの記述は基本的に後から読み込んだもので上書きされるが, 言語フォルダ内のみ, 既に読み込んだローカライゼーションIDに対応するテキストを上書きできない.*8. そして, 言語ファイルのデータはモジュールごとに分離されてるわけではないので, モジュール間でローカライゼーションIDが重複することがありえる. ほとんどの場合でバニラのモジュールが他のモジュールより先に読み込まれるので, バニラのモジュールとローカライゼーションIDが被っていると, modでいくら言語ファイルを作っても反映されない. つまり, バニラのアイテムやNPCの名称を変えるmodを作る場合は, 使用するローカライゼーションIDも変える必要がある. しかし, 英語の場合は言語ファイルを使わずそのまま書けば反映されるので, この事実を知らないmod作者も多い. もしくは知ってて手抜きでそういうことをしている.

こういう場合は, 言語ファイルを作るだけでなく, ModuleData 内で指定されているローカライゼーションIDも修正しなければ正常に翻訳されない.

そして残念ながら, 人気のある大規模なmodほど, ローカライゼーションIDが整備されてない. 具体的には Improved Garrison (IG), Realistic Battle Mod (RBM), Europe Campaign Map (ECM), Banner Kings (BK), Calradia at War (CAW), Europe 1100, AD 1259など多数ある.


それでも英語の箇所が残っている場合

ローカライゼーションIDの重複や欠落や, XSLTにも確認し, それでもなお英語の表示が残っている場合, 考えられる原因は2つある.

前者はプログラミングの知識がないと対処するのが難しいので, 今回は解説しない. 後者も結局スクリプト修正しないと解消しない場合が多いが, いちおうテキストファイルの修正だけでなんとかなることもある.

Prefab とは, モジュールフォルダ直下の GUI フォルダ内にあるフォルダで, 中にあるXMLファイルがゲーム中のUIを定義している. 「閉じる」とかUIでよく使われる文言がこのファイルに直接書かれていることがたまにあるので, 直接書き換えることで対処できることもある. Prefab内では, ローカライゼーションIDを書いても動作しない. また, UI上のテキストはスクリプトで制御されている事が多い. スクリプトで制御されている場合, 文字列の先頭に @ がつく.


言語ファイルのタグの挙動について

この話は知っていてもあまり役に立たない. 既に書いたように, language_data.xml には <tags><tag language="..." /> という記述があるが, <tag> を複数書くとゲームがクラッシュする (タグとはいったい……). 結局, language_data.xml 1つにつき, 言語1つの情報しか書けないことになる.


バニラの言語ファイルについて

ローカライゼーションIDの重複欠落でぐちゃぐちゃになってるので生半可な気持ちで手を出さない方がいい. v1.2βでだいぶ整理されたけど.


未解決/要注意の問題

  • 言語ファイルのみ, 先にロードした内容が優先されると書いたが, Native より先にロードさせると逆に一部の表示が英語になってしまうことがある. (この問題は私の修正mod v0.9.3 で見つかった.) English に対応する language_data.xml を追加するとなぜか直る. 中身は空でもいい. この現象はタイトル画面とオプション項目という, 一番最初にロードが必要そうな箇所で発生する. よってローカライゼーションエンジンの設計ミスではないかと疑っている.
  • 百科事典で表示される文章や一部のNPCの名前は, 新規ゲーム開始時に一度だけ読み込まれて固定される事が多く, 後から修正しても途中のセーブデータでは反映されない事が多い. 途中から変更できるかどうかはけっこう不規則である.
  • プレイ中に選択言語を切り替えた時に, 一部のテキストが切り替えた言語に更新されないバグがある. これはv1.2βで修正されるかもしれない.

私の翻訳環境について

実態として, modは言語ファイルもローカライゼーションも整備されていないものがとても多い. そのため私は, ModuleData フォルダの全部のファイルを探索し, modの翻訳可能な箇所を全て取得し, なおかつIDの欠損や設定ミスを自動で修正するスクリプトを自作して使っている. 類似のプログラムはNexusでも公開されているが, 説明文を見る限りローカライゼーションIDの間違えを修正する機能がないらしいので私は使っていない. 加えて, このスクリプトは取得した翻訳箇所をPOファイルに変換する. POファイルとは, ソフトウェアのローカライゼーションに使われるテキストを編集するためのファイル形式である. GetText という, MB2のローカライゼーションエンジンとは全く異なる規格のプログラミングのためのものなので, 本来意図された使い方ではないが, XMLを直接編集するよりは効率が良いので使っている. POファイルを編集するPOEditというソフトを使えば, 消してはならない箇所を間違えて消したりすることがない. POファイルで翻訳箇所を全て訳したら, POファイルを言語ファイルに再変換するスクリプトを使って完成させている. さらに, mod側で更新があった場合も, 追加・変更箇所がどこかわかるように翻訳作業ファイルを更新する機能もある.

ただし, このスクリプトも万能ではない. DLLファイルまでは修正できないし, ECMのような独自のテキスト制御プログラムにも対処するのが難しい. 既にGitHubで配布されているが, あくまで個人の作業用なので使い方の説明とかは書いてないし, 変なバグも残っている. 最低限の整備をしたら, 改めて解説を書くかもしれない. なお, Pythonスクリプトをターミナルで実行しているのでGUIはない.


*1:私もアーリーアクセス期にはmodを触ってなかったので詳しいことは知らない. だが, たまにアーリーアクセス時の, 今の事情と矛盾する古い情報が書かれているページが見つかるので, 注意を喚起しておく.

*2:私のMB2本体の日本語を修正するmodでもそうしている.

*3:Nexus独自のフォーマットでは何がどこまで制限あるいは許可されているかが極めて不明瞭なので, 私はMITとかCCとか既存のライセンスを使って表明している. 加えて, アップロードしたユーザーも認識がはっきりしていないか, あるいはいい加減に設定している場合があるので, 積極的に聞くべきだろう.

*4:もちろん, 具体的な規約は, 個別のmodに設定されている条項や, 作者に直接確認しなければならない. NexusとSteamワークショップ両方で公開していたり, GitHubでソースを公開している場合もあるし, 外部の翻訳支援サービスを使ってローカライゼーション環境を独自に整備しているmodもある.

*5:というかこの3種類の名称はそもそも使い分けられているのか怪しい.

*6:Europe Campaign Map はなぜかこういう使い方をしている. 指摘しても直してくれない.

*7:私の自作mod以外では, Banner Kings, Calradia Expanded (CE) と CE:K くらいしかXSLT内でローカライゼーションIDを使っている例を見たことがない.

*8:私の日本語修正modの読み込み順の指定が独特なのはこれが原因である. スクリプトを使えば解決できるが, やる手間が半端ないし, 複雑なプログラムほどバグの可能性が増えるので安定性を重視してやらないことにした.