ブログ

「対応すべき言語」に万能の正解はありません。自分の流入データ、ジャンル、文字量から判断するための実務的な枠組みを整理します。

ファン翻訳はプロに依頼するのが現実的でない言語までカバーできますが、品質のばらつき、一貫性のリスク、事前に決めておくべきライセンスの論点があります。

多言語対応は無条件の得ではありません。得られるものとかかるコストを率直に整理し、自分のゲームで判断できるようにします。

多言語対応の費用は翻訳単価だけではありません。レビュー、エンジニアリング、調整コスト、そしてリリース後ずっと続く維持費まで含めた見積もりの組み立て方。

この五つの言葉は同じ意味で使われがちですが、実際には別々の作業を指し、担当する人も違います。用語を区別する意味を整理します。

全訳か無対応かの二択ではありません。ストアページのみ、UIのみ、字幕のみ — プレイヤーが受け入れる部分対応の形と、逆に信頼を損なう境界線を整理します。

ゲームの翻訳を誰に頼むかの4つの選択肢を、コントロール・文脈理解の質・一貫性・拡張性の観点で比較します。どれを選んでも、ファイルの整合性チェックは開発者の仕事として残ります。

多言語対応の意思決定のための考え方の枠組み。コスト側は文字量から把握できる一方、リターン側は本質的に不確実なので、まず安価な需要テストから始める。

同時発売(サイマルシップ)と発売後対応は、解決する課題が違います。それぞれのコスト、判断のサイン、そして小さく始める中間案を整理します。

ストアに並んだ瞬間、ゲームは世界中で「販売」されています。残る障壁は言語だけ。多言語対応で何が得られ、何にコストがかかり、いつやる価値があるのかを整理します。

UTF-8をデフォルトにする理由、BOMとは何でパーサーをどう驚かせるか、文字化けの正体、スプレッドシート書き出しから紛れ込むレガシーエンコーディング、そしてなぜエンコーディングは前提ではなくファイルごとに確認すべきかを整理します。

CSVはスプレッドシート親和性が高い一方でクオート処理に落とし穴があり、JSONは構造化されている一方でマージ衝突が起きやすく生編集に不向きです。フォーマット自体よりも、単一の原本・差分の読みやすさ・往復安全性が重要です。

小数点の記号、桁区切り、日付の要素の並び順、時計の表記、通貨記号の位置は、いずれも地域によって異なります。ハードコードされたフォーマット文字列は、開発者自身の地域の慣習を静かにビルドへ持ち込みます。

ソースコードに埋め込まれたテキストは書き出せず、数えられず、安全に翻訳もできません。キー付きのリソースファイルに移し、文字列連結をやめる方法を解説します。

原文言語への暗黙のフォールバック、生のキー表示、空文字列 — それぞれのトレードオフを開発環境と本番環境で比較し、地域変種から基本言語への連鎖的フォールバックと、なぜ「開発では派手に、本番では穏便に」が定石なのかを整理します。

翻訳が完璧でも、描画するフォントにその言語のグリフがなければ画面には空白の四角しか出ません。グリフカバレッジ、フォールバックチェーン、漢字統合の実務的な意味を整理します。

Godotにおけるローカライズの全体像 — CSVベースの翻訳インポート、表示時に呼ぶ翻訳関数、ロケール選択 — と、エンジンによらず重要な基本事項。

多くの言語は名詞に文法上の性を持ち、格によって語形が変化します。英語では安全に見えるテンプレート文が、変数を埋め込んだ瞬間に非文法的になることがあります。

トークンの削除、余分な追加、大文字小文字の変化、全角括弧化、非対応の並べ替え、括弧内の余分なスペース。プレースホルダーが壊れる具体的なパターンと、なぜすべて機械的に検出できるのかを整理します。

日本語には単語間のスペースがなく、英語向けの単語単位の折り返しは効きません。禁則処理という文字単位のルールと、翻訳後にずれる手動改行の問題を整理します。

言語ごとに1ファイルか機能ごとに1ファイルか、言語タグを使った命名規則、原文言語の置き場所、キー順序の安定性、そして構成がマージコンフリクトをどう左右するか。

キーのリネームがダウンストリームでは「削除+追加」に見える理由、翻訳を失わずにキーを廃止する方法、参照されなくなった孤立キーとコードが参照しているのに存在しないキーの検出。

自作エンジンや小規模なフレームワークでは、ローカライズをゼロから構築することになりがちです。キー・バリューストアの設計、フォールバック付きのルックアップ関数、そして自作システムが陥りがちな罠を整理します。

言語ごとのリソースファイル、OSの言語設定がどうロケールを選ぶか、文字数が増えても壊れないレイアウト、そしてストア掲載テキストがアプリ本体とは別の仕事である理由。

printf形式、インデックス形式、名前付き、ICU MessageFormat、エンジン独自タグ。ゲームテキストで見かけるプレースホルダー構文を一覧し、なぜプロジェクトで1方式に統一すべきかを説明します。

英語は単数・複数の2形態、日本語は数による語形変化なし、言語によってはさらに多くのカテゴリを持ちます。CLDRの複数形カテゴリと、それを1つのテンプレートで表現するICU MessageFormatを整理します。

ノベルゲームはプローズ(地の文とセリフ)そのもので成り立つジャンルです。膨大な文章量、キャラクターの口調の一貫性、テキストボックスの制約、そして台本改訂時に差分管理が重要になる理由を扱います。

色タグ、太字、ルビ、アイコン置換 — インラインマークアップは翻訳を経ても無傷で残らなければなりません。よくある壊れ方と、チェックが機械的で低コストである理由。

アラビア語やヘブライ語などの右横書きスクリプトは、文字の向き以上に多くのものを変えます。レイアウトの反転、双方向テキスト、筆記体的な字形結合は、いずれも翻訳だけでは解決できないエンジニアリングの課題です。

Windows製ツールから出てくる「Shift_JIS」のファイルは、実際にはMicrosoft独自拡張のCP932であることがほとんどです。何が違い、どこで壊れ、どう扱えば安全かを整理します。

階層的な名前空間、安定したIDと原文由来のキーの違い、キーに文脈を埋め込む方法、そして1つのキーを2つの意味で使い回すことがなぜ後々一番高くつくのかを整理します。

言語によってテキストの長さは伸びたり縮んだりし、しかも「文字数」という言葉自体が指すものは測り方によって変わります。何を基準にすべきか、どう予算化すべきかを整理します。

Unityでのローカライズ作業の全体像 — ロケール、文字列テーブル、フォント、出荷前に確認すべきこと。エンジンによらず通用する部分を中心に解説します。

Unreal Engineの収集・翻訳・コンパイルという一般的なワークフローと、それがスムーズに進むかどうかを左右するエンジン非依存の下準備について。

lang属性の役割、URLベースのロケール選択が検索エンジンにインデックスされる理由、hreflangによる代替ページの案内、ロケールに応じた日付・数値の書式、テンプレートから翻訳文字列を切り離すこと。

AndroidがUIテキストをXMLリソースとして保持する仕組み、言語と地域を実行時に選ぶ仕組み、そして翻訳者がつまずきやすいエスケープと複数形のルールを解説します。

key-value形式の.strings、複数形と幅バリアントのための.stringsdict、新しいstring catalogの考え方、そしてXLIFFが翻訳の往復にどう組み込まれるかを解説します。

BCP 47 言語タグがサブタグからどう構成されるか、中国語で region よりも script が重要な理由、マッチングとフォールバックの仕組み、よくある間違いを解説します。

GNU gettext の PO/POT 形式を仕様レベルで解説。複数形、msgctxt による曖昧さ回避、コメント、fuzzy エントリまで。オープンソースで今も標準である理由。

ICU MessageFormat の構文を仕様レベルで解説します。引数、CLDR カテゴリに基づく plural、select、selectordinal、ネスト、offset 機能、そして主なリスクまで。

Javaのkey=value形式.propertiesと.NETのXML形式.resxは、何十年も同じ問題を別々のやり方で解決してきました。それぞれの落とし穴を整理します。

TMXは翻訳済みの文ペアを、TBXは承認済みの用語を保存します。どちらも、言語資産を特定のツールに閉じ込めないために存在します。

CLDR が実際に提供しているもの(複数形ルール、日付・数値の書式パターン、照合順序、表示名)と、書式化 API がなぜこれを土台にしているのか、なぜロケールデータを静的なものとして扱うべきでないかを解説します。

XLIFF が file/unit/segment でどう翻訳データを構造化し、ワークフローの状態を追跡し、原文ファイルと翻訳ツール間の往復変換を守っているかを解説します。

どちらの形式も同じkey-valueの翻訳を保持できますが、編集・差分・マージのもとでの挙動は異なります。この違いは構文の好み以上に重要です。

キャラクターの「声」は何ヶ月もかけて複数の翻訳者が書く、無数のセリフに分散しています。何が一貫性を保ち、何が機械的にチェックでき、何がなお人の目を必要とするのかを整理します。

プロジェクトや言語ペアを問わずほぼ必ず出会う不具合の実務チェックリストです。それぞれがゲーム内でどう見えるか、どう混入するか、機械的に検出できるのか人の目が要るのかを整理しました。

「訳文が原文と一致している」は未翻訳の基本シグナルですが、正しい誤検知パターンも存在します。空欄のターゲット、フォールバック漏れ、新規原文の扱いまで含めて整理します。

差分は「何が変わったか」を教えてくれるはずのものです。しかしファイルの整形が揺れていると、差分は「全部」を教えてくるだけになります。

UTF-8のバイト列が1バイト系エンコーディングとして誤読され、その誤った文字が再びUTF-8としてエンコードされる二段階の文字化け。仕組みと直し方、繰り返し起きやすい理由を解説します。

キーの重複はほとんどクラッシュしません。それこそが危険な理由です。どう混入し、なぜ「後勝ち」の挙動が問題を覆い隠すのか、そしてどう検出・予防するかを整理します。

絵文字1文字が壊れたグリフになる、消える、あるいは余裕があるはずの文字数制限に引っかかる。原因はほぼ必ず、文字列を誤った単位で数えたり切ったりしていることにあります。

表計算ソフトでは正しく開けるのに、他のツールで読むと文字化けするローカライズ用CSV。原因となるエンコーディングの既定挙動と、往復編集に耐える安全な運用方法を解説します。

サンプリングによるレビューは「品質はファイル内でほぼ均一」という前提の上に成り立っています。この前提は人間の翻訳者には比較的成り立ちましたが、機械翻訳・AI翻訳では崩れます。その理由と、代わりに何をチェックすべきかを整理します。

文字列テーブルは、誰が話しているか、どこに表示されるか、プレースホルダーが何に展開されるかをすべて削ぎ落とします。裸のスプレッドシートの代わりに何を渡すべきかを整理します。

アイテム名やスキル名、UIの動詞は、どの画面でも同じ訳語であるべきです。それを実現する用語集とスタイルガイドは、翻訳が始まる前に作るからこそ機能します。

流暢さは正確さではありません。機械翻訳・AI翻訳がローカライズファイルを壊す具体的なパターンと、スクリプトで機械的に検出できる部分・人の目が必要な部分を整理します。

ゼロ幅スペース、迷子になったBOM、方向制御文字、全角と半角のスペース。画面上は何も見えないのに、完全一致比較・キー検索・diffを壊す文字の正体と対策を解説します。

英語の I は個性を伝えません。日本語の一人称は年齢・性別・フォーマルさ・性格を伝える語彙の集合であり、英日ローカライズではキャラクターごとに一つを選び、保ち続ける必要があります。

英日ローカライズでは、原文に手がかりがほとんどない敬語レベルを、話者と関係性ごとに決めなければなりません。物語上の理由なく途中で崩れると、それはバグとして読まれます。

パース可能性、エンコーディング、プレースホルダーの整合性、タグの対応、キーの重複。ソースコードに当たり前に適用している規律を、ゲームのテキストを運ぶファイルにも適用します。

原文の修正、再翻訳やファイルの再書き出し、古いバージョンの再インポート ― どれも承認済みの訳文を静かに壊します。コードと同じ規律で、ベースラインと差分をとる方法を整理します。

全画面・全言語を読み込む本格チェックの代わりに、短く決まった手順で重大な不具合を漏らさず拾う、数分で終わるチェックリストです。

MTPEは翻訳の順序を入れ替えます。機械が下訳を作り、人間がそれを直す。この順序の変化によって、エラーの隠れ場所とQAが見るべきポイントが変わります。

文字化けはデータの破損ではなく、正しいバイト列を間違ったエンコーディングで読んだ結果です。化け方のパターンから原因を特定し、復元する手順を解説します。

本来は名前や数値に置き換わるはずのプレースホルダーが、そのまま文字として表示される。原因は4通りあり、症状だけから切り分けて対処する方法をまとめます。

疑似ローカライズは、原文をアクセント付き・水増し・括弧囲みの「偽の訳文」に機械的に変換する手法です。本物の翻訳が存在しない段階で、パイプラインの不具合を洗い出せます。

ローカライズファイルに触れる人の大半は、そこに並ぶ言語のほとんどを読めません。読めなくても確認できること、逆にネイティブでなければ判断できないことを整理します。

インベントリやランキング、フレンドリストの並び順が、ネイティブの読み手には明らかに変に見える。文字化けでも欠落でもなく、比較のやり方そのものが言語に対応していないのが原因です。

ボタンの文字がはみ出す、2行目が下と重なる — 原文言語では起きないのに翻訳後だけ発生する不具合の切り分け方と、短縮・レイアウト変更・折り返し許可のどれを選ぶべきかを整理します。

テキストが空の四角(いわゆる「豆腐」)や代替グリフになって表示される現象。データはまったく正しいまま起きるフォントの問題を、文字化けと素早く見分ける方法を解説します。

品質を一つの数値にまとめる必要はありません。カテゴリと深刻度ごとの件数を、ビルドをまたいで数え続けるほうが、多くを語り、嘘も少ないです。

誰が何をレビューするかがはっきりしていて、判断が記録され再議論にならず、承認された修正が実際にファイルへ反映されて初めて、レビューは機能します。

LQAという言葉は何でも含む呼び方として使われがちですが、実際には性質の異なる二種類のチェックを指します。言語面の品質と、機能・フォーマット面の品質です。パイプライン上の置き場所も担当者も異なります。

「日本語がなんか変」はバグレポートではなく感想です。翻訳者が一発で直せるバグレポートの構成要素を整理します。

行頭に読点が来る、閉じ括弧だけが行頭に取り残される、単語の途中で改行される — これらは感覚の問題ではなく、名前のついた明確なルールへの違反です。

右から左へのレイアウトとミラーリング、双方向テキスト、筆記体的な文字接合、単数・複数だけではない複数カテゴリ。アラビア語対応の大部分がなぜエンジニアリングの課題なのかを整理します。

ブラジルのポルトガル語とヨーロッパのポルトガル語は、綴り・語彙・呼びかけ方が異なります。言語タグでどちらを指しているかを明示すべき理由を整理します。

日本語ローカライズは単なる文字列の差し替えではありません。1行に混在する3つの文字体系、単語間にスペースがない構造、英語では意識せずに済む表記判断まで整理します。

フランス語は英語より文章が長くなり、文法性が原因で断片から組み立てた文が壊れることがあり、独自の句読点まわりの表記ルールを持ちます。開発者向けの実務ガイド。

複合名詞、名詞の大文字化、格変化による文組み立ての破綻 — この3つが組み合わさることで、ドイツ語はレイアウト設計上もっとも厳しい言語の一つになります。だからこそ設計の基準にする価値があります。

逆方向にも固有の落とし穴があります。文字数が増える、主語を補わなければならない、そしてUIがそもそも日本語向けに設計されている、という問題です。

ハングルはラテン文字と同じ意味での「アルファベット」ではありません。音節ブロック、分かち書きのルール、敬語レベル、フォントの網羅性、それぞれに個別の注意が必要です。

ロシア語は英語より多くの複数カテゴリを持ち、名詞は文中での役割に応じて格変化します。単数・複数の二形式テンプレートがなぜ通用しないのか、ICU MessageFormatの複数形構文がなぜ唯一の持続可能な解なのかを整理します。

両者は互換ではありません。1つの「中国語」ファイルとして扱うのは、チームが陥りやすい典型的なローカライズの失敗です。

スペインのスペイン語とラテンアメリカのスペイン語は語彙も二人称の呼びかけ方も異なります。BCP 47のタグの意味と、一つの中立変種にするか二つに分けるかの判断基準を整理します。

文字の折り返し、スクリーンリーダーの発音、言語ごとの字幕、ハードコードされたレイアウト。アクセシビリティと多言語対応は同じ根本原因にぶつかることが多く、片方をきちんと直すともう片方も直ることが多いです。

一般的な翻訳スキルとゲーム翻訳のスキルは別物です。日本語が読めない開発者でも翻訳者を正しく評価し、うまく依頼するための方法を解説します。

ローカライズ費用に万能の答えはありません。自分のゲームの文字量・コンテンツの内訳・範囲の判断から、自力で見積もりを組み立てる手順を解説します。

不安定な原文を丸ごと翻訳すると、行が変わるたびに作業が無駄になります。アーリーアクセスのゲームを「差分」として多言語対応する方法を解説します。

ライブサービス型のゲームは一度きり多言語対応するのではなく、繰り返されるコンテンツ配信のたびに、決まったイベント締切に向けて多言語対応を行う。それがプロセスに何を要求し、イベントを言語混在のまま出さないためにどうすればよいかを整理する。

ローカライズには独自のスケジュールと依存関係があり、見落とすと発売直前の駆け込み翻訳とミスの多発を招きます。

スプレッドシートと実際に動くゲームでは、テキストの見え方がまったく違う。両者の間で何が壊れるのか、テスターが素早く言語を切り替えられる仕組みをどう作るか、時間が限られているときに何を優先すべきかを整理する。

ローカライズキットがあるかないかで、翻訳者が裸の文字列リストだけで作業するのか、最初から正しく訳すために必要なものが揃った状態で作業できるのかが決まります。

日本市場では、テキストの質がそのまま製品全体への信頼として受け取られます。敬語・キャラクターボイス・タイポグラフィという観点から、日本語読者の視点でのクラフト論をまとめます。

出荷直前の最終確認リスト。最後の1週間で見落とされがちなローカライズ項目と、それぞれが重要な理由、そして避けられない発売後の修正に備えて用意しておくべきことを整理します。

ストアページは多くのプレイヤーにとって最初の接点であり、多言語対応する対象としては最も文字数が少ない。だからこそ、雑な翻訳は「未対応」より悪い結果を招くことがある。

小さなチームでは誰もその肩書きを持っていないが、仕事自体は誰かがやっている。ファイル準備、翻訳者へのブリーフィング、質問対応、レビューの調整 — 仕事に名前を付けることで、抜け漏れが見えるようになる。

翻訳メモリ(TM)が実際に何を保存し、あいまい一致(ファジーマッチ)がどう働くのか。過去の翻訳の再利用が最大の時短にも、誤訳拡散の最速ルートにもなる理由を整理します。

小規模・中規模スタジオの多言語対応は、多くの場合フリーランス翻訳者との関係で成り立っている。その関係をうまく回すには何が要るのか、そして「一番安い人」を案件ごとに変える運用が静かに何を失わせるのかを整理する。