AIで韓国語ブログを英訳するときの確認事項:意味・画像・翻訳リンク
AIで韓国語のブログ記事を英語に翻訳するときは、自然な文章だけでなく、事実、用語、リンク、画像、言語間の関連付けを確認する必要があります。原文の条件と例外を保ち、英語の読者に必要な説明だけを補うのが基本です。別の下書きとして保存し、原文と並べて確認すると、抜けを見つけやすくなります。
翻訳前に原文と維持する要素を決める
まず原文自体が最新かつ正確かを確認します。誤った説明を自然な英語にしても、問題は残ります。確認が必要な情報がある場合は、翻訳と事実の修正のどちらを先に行うか決め、修正範囲を記録します。
タイトル、本文、抜粋、画像内の文言をまとめて用意します。HTML原稿なら、見出し階層、表の構造、コード、ショートコードも渡してください。本文のテキストだけをコピーすると、表、目次、強調が失われる場合があります。
技術記事では、翻訳してはいけない文字列を別に記録すると便利です。コマンド、ファイル名、設定キー、コード、製品の正式名称などです。説明を英語にしても、実行に使う値は原文と比較できるようにします。
用語集と翻訳の依頼文を作る
同じ概念を段落ごとに違う言葉で訳すと、別の機能と誤解される場合があります。タイトルと本文の主な用語から整理しましょう。製品のメニューは公式の英語表記を確認し、未確認の訳を実際のメニュー名として断定しません。
| 原文の要素 | 翻訳基準 | 確認する点 |
|---|---|---|
| 主な技術用語 | 記事全体で表現を統一 | 同じ概念が別機能に見えないか |
| 製品メニュー | 確認済みの公式英語表記 | バージョンやアカウントで経路が変わらないか |
| 数値と条件 | 意味と適用範囲を維持 | 単位、上限、例外に抜けがないか |
| コードとファイル名 | 文字列を保持 | 引用符、ハイフン、空白が変わっていないか |
以下の韓国語ブログ記事を、英語の読者に向けた自然な説明文に翻訳してください。 事実、数値、条件、例外、段落の論理的な順序を維持してください。 原文にない経験、機能、評価を追加しないでください。 HTMLタグ、クラス、ショートコード、コード、ファイル名は保持してください。 URLを推測して変更しないでください。 公式の英語メニューを確認できない箇所は、別の確認リストに残してください。 翻訳とともに、用語の変更や脱落が懸念される項目を知らせてください。 [用語集] 確定した表現を入力します。 [原文] 現在の韓国語原稿を入力します。
依頼文は出発点であり、品質の保証ではありません。下書きが指示を守ったか確認し、長い記事は節ごとに比較してから全体の流れを読みます。分割して翻訳しても、用語集と読者の設定は共通にしてください。
自然さと意味の保持を別々に確認する
まず原文の各段落に対応する説明があるか調べます。「一部」「現在」「設定によって」といった短い条件が抜けるだけでも意味は変わります。特に「可能」が「必ずできる」に強まったり、推奨が義務に変わったりしていないか確認します。
次に英語だけを読み、直訳調や長すぎる文を整えます。韓国の読者には身近なサービスや背景に短い説明が必要な場合でも、勝手に米国の価格や制度に置き換えません。換算する場合は元の金額と為替レートの基準を確認する必要があるため、単純な翻訳では原文の通貨単位を保つほうが明確な場合があります。
たとえば「国内で登録できる」の「国内」は、英語の読者には曖昧です。韓国を指すなら国名を明記します。これは新たな情報を作る現地化ではなく、原文にある条件を明確に伝える作業です。
英語の読者に合わせてリンクと画像を確認する
関連する内部記事に実在する英語版があれば、そのURLへリンクします。英語版がないのに、URLの言語コードだけを変えてはいけません。韓国語資料を残す場合は、リンク文言から資料の言語が分かるようにする方法もあります。
外部文書も、公式の英語版を実際に開いて確認してください。リンク文言だけ英訳し、到着先が別製品や過去のバージョンになっていないか見ます。URLと引用内容が、今も同じ根拠を提供していることが重要です。
画像に韓国語の説明がある場合は、英語版が必要か検討します。韓国語UIの実画面を無理に英語UIへ加工せず、画面の言語を説明するか実際の英語画面を用意します。文字のないアイキャッチは再利用できますが、本文画像の代替テキストは英語にします。
本文画像の再利用では、英語記事の画像ブロックを選び、ブロック設定で代替テキストを入力します。HTMLなら、その記事の<img>のaltを変更します。画像ブロックの案内によると、ブロック側の変更はその記事に適用され、ライブラリ側の値は別の場所へ挿入するときの既定値になります。共用画像の既定値を英語で上書きするより、記事ごとの値を確認してください。
アイキャッチの代替テキストは、本文ブロックとは別にテーマの出力方法を確認します。同じファイルを再利用しても、言語別の文言が自動で区別されるとは限りません。プレビューの実際の説明を調べ、多言語メディア機能が必要か確認します。
共用画像を別の記事に添付し直すことと、アイキャッチに選択することも別です。ある記事用にアップロードした画像を、別の記事へ移動させるような管理は必要ありません。
WordPressで言語と翻訳関係を設定する
英語原稿は韓国語記事とは別の投稿に保存し、言語とカテゴリーを確認します。多言語プラグインを使う場合は、その翻訳機能で一組にします。英語が登録済みのPolylangサイトなら、次の順で確認できます。
- 韓国語原文の編集画面で言語設定を開きます。ブロックエディターでは言語パネル、クラシックエディターでは言語メタボックスを確認します。
- 英語版がなければ、新しい翻訳を追加するボタンから作成します。保存済みなら新規作成せず、翻訳欄から既存の記事を検索して関連付けます。
- 英語記事の言語がEnglishであり、既存の英語カテゴリーが選ばれているか確認して、下書き保存します。
位置と操作はPolylangの投稿・分類翻訳ガイドで確認できます。サイト全体に言語を追加する設定は、翻訳の保存と分けて行います。
公開後は言語選択が正しい対応記事へ移動するか確認します。ホームや別の記事へ移動する場合は、本文とは別に関連付けを見直します。言語ごとの抜粋とアイキャッチも実際の保存値を調べます。
検索エンジンへ言語別の代替ページを伝えるhreflangも関連します。Googleは、各版が自分と対応版を示し、相互に参照する構成を案内しています。まずプラグインの出力を確認し、言語別ページの公式説明と比較します。同じタグを本文に重複挿入して解決しようとしないでください。
公開前に韓国語版と英語版を並べて確認する
- タイトルと抜粋が同じ主題と範囲を示しているか確認します。
- 段落、リスト、表を比較し、条件や数値の抜けを探します。
- コードやファイル名など、保持する文字列を比較します。
- 内部・外部リンク、画像内の文言、代替テキストを確認します。
- モバイル表示と言語切り替えを確認してから、公開を判断します。
英語を韓国語に戻す逆翻訳は、不自然な意味を見つける補助にはなります。ただし、似た訳に戻っただけで原文と同一だと判断してはいけません。重要な数値と条件は、両方の原稿を直接比較するほうが明確です。




