二言語の人物名マップ

表記より先に人物IDを固定する

訳名を変えても同じ人物であることは変わりません。人物ごとに固定IDを付け、原文表記、訳名の案、確認状況を分けて入力します。訳名が未入力なら未解決のまま表示します。空欄を埋めるために無関係な名前を作ることも、自動翻訳を行うこともありません。

訳した後に衝突することがある

原文では区別できた名前が、対象言語の短い呼び名や転写で同じになる場合があります。ここでは正規化した訳名の完全一致を警告しますが、文化的な自然さやすべての音の類似まで検証するわけではありません。人物一覧だけでなく、実際の会話の呼び方を読み直してください。

手掛かりの働きを記録する

頭文字、語呂、愛称、文字の形など、名前に依存する仕掛けは別に管理します。手掛かり欄には原文と対象言語で必要な値を明示します。不一致や欠落は再設計の対象です。同じ値が残っていても、周囲の説明が訳文で失われていれば公平な仕掛けとは限りません。

創作例：劇場のプログラム

翻訳した公演パンフレットの芸名が、隠していた本名と偶然同じ形になり、正体が早く分かってしまいます。翻訳者はプログラムの表記を変え、後の認識につながる別の手掛かりを記録します。会話だけを直しても、絵の中にある情報漏れは残ります。

方法ごとの損失を比較する

原表記を残すと人物の連続性を保てますが、意味の仕掛けは伝わらないかもしれません。音に合わせた転写では頭文字が変わります。機能を移し替える訳では小道具の修正が必要になることがあります。どの働きを優先するのかを、作品の条件に沿って決めます。

文字列だけでなく制作判断を渡す

看板、手紙、字幕、収録、人物紹介、クレジットへの影響を確認します。過去の表記と変更理由も残してください。確認状況欄は入力された編集情報であり、ツールが母語話者の承認を認定するものではありません。言語版としての公開は、内容全体の完成と確認を経て判断します。

訳名の制作面を測る

専用設定の制作面表に人物ID、ラベル、内側の幅、文字サイズ、書体を入力します。同じ人物IDの訳名だけを測るため、プルーフを別の人物へ取り違えにくくなります。表が空なら未検証と表示し、合格扱いにはしません。以前の対応表と今回の設定をそれぞれプロジェクトとして保存すれば、人物IDを維持して復元・比較できます。

対応表を制作上の判断として扱う

二言語の人物名マップには、同じ人物を版の間で結ぶことと、名前の変更が物語へ与える影響を残すことの二つの役割があります。文字列の訳表だけでは前者を満たしても、後者を落とすことがあります。頭文字、親しい呼称、署名、音声のキューは、変更した表記に依存しているかもしれません。

表示文字列ではなく固定IDから始めます。訳名を変えても別人にせず、同じ名前の二人も文字列だけで統合しません。正規化した訳名が同じ場合は点検対象として表示しますが、意図した類似か、対象言語で自然かまでは自動判定しません。

難しい名前には、場面での主な働きを書き添えます。普通の参照、語呂、正体の手掛かり、家族の印、クレジットなどです。「意味を保つ」という曖昧な指示へまとめず、何を優先し、何を別の場所で補うかを決めます。

実際の変更依頼を再現する

同じIDの下で、以前の対応と新しい対応を入力します。制作素材には小道具、会話、クレジット、音声をそれぞれ登録します。素材ID、人物ID、種類、現在の訳名を入れ、新しい訳名と違えば修正項目になります。対応表の変更点にも旧表記と新表記を残します。

以前の転写が名札の絵に入っているなら、台本だけ直しても足りません。画像の修正、読みの相談、クレジットの校正が別に必要です。ツールが画像や音声を変更したと主張するわけではなく、担当者が行う作業を可視化します。

知らない人物IDは矛盾です。素材が誰のものかを推測して埋めません。対応表か素材一覧を訂正してください。訳名の欠落は未解決のままです。整った資料の形によって、別人の道具を誤って結ぶことを防ぎます。

創作例：ロビーのプログラム

翻訳者が気付いたのは会話ではなく、公演プログラムだった。芸名の訳が、後の章で明かすはずの本名と同じ形になっていた。

原文では二つの名は区別されていた。観客はまず演者を見て、誰が公演費を出したかを後で知る。訳文の試作では、答えが入場料の横に印刷されていた。

編集者はプログラムを訳さず残す案を出した。デザイナーは折り目を指した。ここは普通に読める紙でなければならない。折り込まれた手紙の仕掛けも、その自然さに依存していた。

「紙そのものを見せないわけにはいきません」と翻訳者は言った。

芸名を残す案、音に近い表記、正体と重ならない公の名を順に試した。一つを直すと別の問題が動いた。頭文字の手掛かりが弱まり、別の案では名義が長くなって手紙の見える折り目を圧迫した。

チームは公の名を決め、後の手掛かりを、先に教えた私的な挨拶へ作り替えた。デザイナーはプログラムを直し、音声担当には読みの変更を渡した。編集者は、観客がつながりへ気付くべき章を確認した。

完成した場面で、人物はプログラムを開いて手紙を見つける。分かったのは物語が意図した情報であり、翻訳の過程で早く印刷してしまった答えではなかった。

これは創作上の制作例です。特定の訳名が実際に推奨されるという例ではありません。名前の変更が、用語集の置換だけでなく、手掛かりと複数の素材の修正を要することを示します。

三つの方針を結果で比較する

原表記の保持は版をまたぐ連続性に役立ちますが、意味の連想が説明されない場合があります。音を重視した適応は発音を助けても、頭文字や字形を変えます。機能の適応は語呂や推理を残せても、台詞、小道具、音声キューの変更が必要かもしれません。すべての作品に同じ既定解はありません。

場面の事実を固定して比較します。手紙を見つける前に何を知る必要があるか、挨拶を誰が認識できるか、その規則をいつ読者へ教えるかを確認します。語呂を保ちながら正体を漏らすなら、単なる文体上の小さな損失ではありません。筋を支える知識の順序が変わります。

手掛かり欄は限定した比較です。入力した値の欠落や不一致は示しますが、同じ値なら周囲の謎も解けるという証明ではありません。違う値でも良い適応は可能です。表面的に一致させず、再設計の内容を記録し、対象言語の場面を試してください。

確認者へ文脈を渡す

人物マップ、確認した読み、名前の働き、重要な使用箇所をまとめます。却下した案と理由も有用です。文脈なしの名前だけを渡すと、自然さだけを検討して、頭文字が必要な推理の条件を落とすなど、違う課題を解いてしまいます。

創作上の連想と事実も分けます。架空世界の意味付けは実在言語の語源ではありません。一つの読みの根拠があっても、すべての組合せや時代を保証しません。決定的な資料に見せるため、限界を削除しないでください。

確認状況は利用者のメタデータです。reviewed と入力しても確認者が出現したり承認が認証されたりはしません。実際の制作では、誰が、どの文脈を見て、何を残したかを記録します。サイトが裏で母語話者の認定を提供することはありません。

巻をまたぐ表記のずれを防ぐ

採用した対応を会話、人物紹介、クレジット、制作メモへ一貫して渡します。旧版も残せば、途中参加の担当者が古い台本を理解しながら、廃止した表記を誤って復活させずに済みます。原文側の改名でも依存関係を開き直してください。

あらすじや用語集も同様です。マスター表に正体のつながりがあるからといって、序盤の人物紹介へ載せてよいわけではありません。これは制作資料です。読者向けの抜粋には、観察者と章に応じた知識の制御を使います。

英語ページと日本語ページは、同じ課題の言語版であり、別の独立ツールとして二重計上しません。見出しだけ訳した状態も完全なローカライズではありません。経路の数と、内容と操作が成立する状態を分けて記録します。

最後は対象言語だけで読む

改訂後は原文を横へ置かず、対象言語の導入、手掛かり、開示を読みます。同じ人物を識別でき、意図した推論だけが可能かを確認します。道具の画像、字幕、音声の引き渡しも見ます。JSONを書き出せたことは、素材の修正が済んだ証拠ではありません。

失った機能も正直に残します。語呂を保つと正体が早く分かるなら、どちらを優先し、残る情報をどこで扱うかを説明します。何も失っていないと主張するより、選択を評価できる記録の方が共同制作者に役立ちます。

訳名の重複は必ず間違いですか

意図して公の表記が一致する場合もあります。ただし対象言語版でも、その意図を支える必要があります。手掛かり、世界内の慣習、望まない合流のどれかを記録します。ツールはIDを維持して共有する表記を警告し、人物を統合しません。会話の実際の呼称を試してください。用語集だけの区別は、読者が必要とする場面では使えないかもしれません。重複を消すこと自体より、どの推論を可能にするかを確かめます。

つづりだけの変更で音声も一覧へ入れる理由は何ですか

採用する発音も変わったかを担当者が判断するためです。変わらないなら、その理由で確認を閉じられます。収録キュー、字幕、口頭のクレジットに影響する場合もあります。すべて再録が必要とも、一切関係ないとも決めつけず、作業項目として可視化します。表記の変更と演者への指示の変更を分ければ、不要な修正を避けながら必要な伝達を落とさずに済みます。

頭文字が一致すれば翻訳後の謎も成立しますか

一致した値は宣言した条件の一つです。対象言語の本文でルールを教え、証拠へ接触でき、正体を早く漏らしていないかも必要です。意図した機能の再設計なら違う値でも成立します。表面上の同一性を、物語上の代償を無視して守らず、理由と修正素材を対応表へ残します。原文を知る人だけが解ける状態と、対象版の初見読者が推理できる状態も別々に確認してください。

完成した別言語版として扱えるのはいつですか

操作画面、本文、例、確認状況の全体がその状態を支えるときです。見出しだけ訳して原語の未完成文を置いた状態ではありません。開発中に言語の移動を用意しても、公開索引と正式な言語関係のメタデータは保留できます。URLが増えても同じ課題の言語版は別ツールへ数えません。読者が得る作業結果を基準にし、経路や翻訳文字数を完成数の代わりにしないようにします。

翻訳担当へ渡す変更依頼の書き方

変更依頼は「名前を自然にしてください」だけにせず、元の形、候補、主な物語上の働き、固定したい情報を記します。プログラムの例なら、公の芸名を本名と区別し、手紙の所在を示す紙としての自然さを保つことが条件です。読みやすさだけの依頼では、この情報順序を落とすかもしれません。

修正した対象表記がどこへ現れるかを、素材IDで渡します。音声は再録が必要か、同じ発音のまま表記のみ変えるのかを分け、看板や手紙は画像の担当へつなぎます。編集上の判断が済んだ項目と、実ファイルの更新が済んだ項目は別です。

校了前には対象版だけを読んでもらい、同じ人を識別できるか、早すぎる推論がないかを確認します。原文を知る編集者が理解できることだけで終わらないでください。解決できなかった意味や語呂は、失われた機能として残します。その記録があれば、別の版で改善するときも、過去の判断を無理由に覆さず検討できます。