店舖本地化 playbook
翻譯是本地化裏最小的部分。決定成敗的工作是結構性的——URL、hreflang、按市場的詞彙——和運營性的：目錄每週在變，六個 locale 要一直保持真實。
店舖國際化有條可預測的弧線：機翻一切、上線、看著本地化站表現不佳、然後悄悄停止維護。這份 playbook 跑的是會複利的版本：在數據顯示有需求的市場進入、技術結構一次建對、把能轉化的頁面對著真正當地的詞彙本地化、裝上讓每個 locale 從此保持最新的同步紀律。
階段一：按證據選市場，結構一次建對
你的分析數據早就顯示需求從哪漏進來：按地理的流量、轉化與下單嘗試。進證據存在的市場，不進野心指向的市場。然後是技術層，第一次就做對：子目錄 URL 聚合權重（除非有強法律或品牌理由）、完整對稱的 hreflang 簇、按 locale 的 sitemap。
市場短名單來自現有的地理流量、轉化與支付嘗試數據
子目錄結構（/de/、/fr/），除非有特定理由
hreflang 簇從第一天就完整對稱——事後補救是苦役
上線前按市場摸清貨幣、支付方式與配送預期
階段二：錢易手的地方先本地化
本地化投入跟著收入走：商品頁與分類頁最先、結賬與政策頁其次、博客內容最後（如果做的話）。對著當地搜索詞彙寫——德國買家輸入的不是英國買家輸入的詞典直譯——也對著當地異議寫：尺碼習慣、配送焦慮、支付偏好因市場而異，都該進文案。
階段三：把同步立成常設規則
漂移是殺手：新品只上主語言、調價漏掉一個 locale、模板更新弄掉一半 hreflang 標籤。把主目錄立為唯一事實源，每次變更作為發佈流程的一部分傳播到每個 locale，hreflang 完整性持續驗證。養不起同步的 locale，與其爛著不如退役——買家語言裏的一個過期站，比沒有更糟。
運作方式
選市場、建結構
證據驅動的市場選擇；URL、hreflang 與支付軌道一次建對。
先本地化收入頁面
商品與分類對著當地詞彙與異議來，然後是結賬與政策頁。
立同步規則
每次目錄變更作為發佈的一部分傳播到每個 locale；完整性持續驗證。
你會得到甚麼
按需求證據（而非野心）進入的市場
永遠不用重構的技術結構
用當地詞彙回答當地異議的本地化頁面
隨目錄變化保持真實的各個 locale
由這些 Agent 負責
可配合使用
常見問題
先機翻還是第一天就正經本地化？
收入頁面從一開始就正經做——回報在那裏。機翻可以過渡長尾頁面，但任何顧客關鍵路徑依賴它之前要明確審過。
同語言市場——美英澳需要分開的 locale 嗎？
當貨幣、目錄、拼寫或配送話術真有差異時，分開的地區 locale 才值回維護成本。搜索側由 hreflang 地區定向處理；別把 locale 增殖到你維護不動的數量。
hreflang 最常怎麼壞？
不對稱（A 指向 B、B 忘了 A）、新模板不帶標籤上線、下架頁面留下懸空引用。三樣都無聲發生，持續驗證因此存在。
哪些 Agent 跑這個？
Analyst 供市場證據；Builder 負責結構與傳播；Visibility 負責按市場詞彙與 hreflang 完整性。同步規則在共享工作流裏強制執行，不在任何人的記性裏。