stable ID・slug・翻訳記事がそれぞれ担う役割

英語版と繁体字中国語版ではタイトルが異なりますが、URLには同じ英語の名前を使っています。タイトルやURLだけを比べても、二つの記事が翻訳の関係にあることは説明できません。

このサイトでは、三つの問いに三種類のデータで答えています。collection entry IDは読み込んだファイルを識別し、stableIdは同じ記事の各言語版を結び付け、localeとslugは読者が開くURLを決めます。現在の値は似ているかもしれませんが、同じフィールドとして扱うことはできません。

すでに3言語版がある記事から確認します

「AIと一緒にサイトを改修する」には、繁体字中国語、英語、日本語の各版があります。三つのファイルでは、それぞれの言語に自然なタイトルを使っています。次の表は、実在する3言語版の識別情報と公開ルートです。

言語	collection entry ID	stableId	公開ルート
繁体字中国語	zh-TW/ai-collaboration-and-acceptance	ai-collaboration-and-acceptance	/notes/ai-collaboration-and-acceptance
英語	en/ai-collaboration-and-acceptance	ai-collaboration-and-acceptance	/en/notes/ai-collaboration-and-acceptance
日本語	ja/ai-collaboration-and-acceptance	ai-collaboration-and-acceptance	/ja/notes/ai-collaboration-and-acceptance

ここでは、三つの版すべてのslugがai-collaboration-and-acceptanceです。表の値が繰り返しに見えるのは、現在の命名がたまたま一致しているためです。コードでは、「どの項目か」「どの記事か」「どのURLか」を分けて扱っています。

タイトルで対応付けると、翻訳版のタイトルを言い換えただけで原文を見つけられなくなる可能性があります。同じslugで対応付けると、URLの命名が翻訳関係を成立させる必須条件になります。stableIdを使えば、この二つを結び付ける必要はありません。

entry IDは三つのファイルを読み込めるようにします

Astroのglob() loaderは、コンテンツ項目ごとに一意のIDを生成し、その生成方法をカスタマイズすることもできます。[1] このサイトでは、言語とファイル名の組み合わせを保ち、.md拡張子を取り除いたものをentry IDにしています。

そのため、繁体字中国語版と英語版はファイル名が同じでも、zh-TW/ai-collaboration-and-acceptanceとen/ai-collaboration-and-acceptanceという別々の項目として読み込めます。

この層が扱うのは、読み込み時の識別です。どの版が原文かを決めるものではなく、記事が公開可能な状態にあることも意味しません。草稿にも、校正時に見つけられるよう一意のIDが必要です。

stableIdは、このサイトが独自に定義したフィールドです。Astroがすべての多言語サイトに自動で用意する翻訳システムではありません。同じ方法を使うには、スキーマ、一意性のルール、対応する版を探すクエリを自分で定義する必要があります。

stableIdは各版を結び付け、slugはURLを担当します

記事ページでは、正式な公開対象の集合を取得した後、同じstableIdを持つ版を探します。そのうえで、各版のlocaleとslugを使い、言語リンクとhreflangを生成します。

識別情報の検証は、言語ごとの範囲で行います。同じ言語では、二つの記事が同じslugを使うことも、二つの版が同じstableIdを使うこともできません。異なる言語では、同じ記事のstableIdを共有できます。これで識別情報の重複は防げますが、二つの本文が本当に互いの翻訳であることまでは証明できません。内容の校正は別途必要です。

URLのルールは、もう少し単純です。繁体字中国語版には/notes/{slug}を使い、英語版と日本語版には言語の接頭辞を付けます。タイトルとカテゴリはURLの計算に使いません。概要を書き直したりタイトルを調整したりしても、それだけで新しい記事URLになることはありません。

現在の3言語版では、同じslugを使っています。これは命名上の選択であり、対応付ける関数の必須条件ではありません。将来、ある言語で別のslugが必要になっても、元のstableIdを使って対応付けられます。ただし、新しいURLと既存のリンクをどう扱うかは、明確に決める必要がある別の作業になります。

名前を変える前に、どの識別情報を変えるのかを確認します

私は、次の変更を分けて考えます。

• タイトルの変更では、読者に見える名前を変えます。通常はstableIdとslugを維持します。
• 翻訳の追加では、異なるlocaleのコンテンツを作り、同じ記事のstableIdを共有します。その言語版自身の完成時刻と公開時刻も記録します。
• slugの変更では、公開URLを変えます。サイト内リンク、canonical、既存の外部リンクへの影響を確認する必要があります。
• stableIdの変更では、各版を対応付ける根拠を変えます。一つの言語版だけを変更してはいけません。

これは、自動移行の仕組みではありません。このサイトには、任意のslug変更、旧URLからのリダイレクト、識別情報の移行を行う汎用ツールはありません。stableIdを維持しても、旧URLを指すリンクが自動で修復されるわけではありません。

記事を書き直した結果、中心となる問いがまったく別のものになる場合もあります。それでも同じ記事と見なせるかは、編集上の判断が必要です。同じファイルを使い続けているだけで、既存の翻訳がすべて有効だと判断することはできません。

共通の識別情報があっても、各版が公開条件を満たす必要があります

繁体字中国語版が公開済みで、英語版がまだ草稿の場合、両者は同じstableIdを使えます。ただし、正式な記事ページで対応付けるのは、公開条件を満たす版だけです。繁体字中国語の原文が見つかるという理由だけで、英語の草稿がクリック可能な言語リンクになることはありません。

そのため、翻訳を進めるうえで、3言語の記事数を完全にそろえる必要もありません。識別情報は「同じ記事の各版であること」を記録し、公開情報は「この版を今、公開コンテンツとして読めるかどうか」に答えます。

この契約を確認するには、実在する3言語の記事を一つ選び、各版のentry ID、stableId、locale、slugを照合します。その後、生成された記事ページを開き、言語リンクを確認します。ファイル名が同じというだけで、対応付けが成立していると判断してはいけません。

この記録の範囲

この記事は、このサイトにすでに存在する3言語の記事、コンテンツloader、識別情報の検証、記事ルートをもとに整理したものです。言語ごとに異なるslugを使う状況は、ルールを説明するためのものであり、URL変更を完了した事例ではありません。自動リダイレクト、コンテンツの版間差分の検出、翻訳品質の採点は扱っていません。

参考記事：翻訳がなければ、翻訳を装う言語ページは作らない。

出典

[1] https://docs.astro.build/en/guides/content-collections — Astro — Content collections