多語網站內容怎麼同步？管理主文、譯稿與核稿版本
用清楚的主文、譯稿、核稿責任與版本紀錄，讓多語頁面更新時能找出來源、進度和下一步。
多語網站最容易失控的時刻，通常不是第一版上線，而是主文修改後，每個譯稿是否知道自己依據哪一版、誰要核對、尚未完成時讀者會看到什麼。若只靠檔名、聊天訊息或各自的文件記憶，團隊很難分辨一份譯稿是已核稿、沿用舊稿，還是正在等主文回答。本文用一套輕量的版本紀錄方式，從指定主文、翻譯交接、更新同步、未完成標記、術語核對到語系切換，讓每個頁面都能追到來源和下一步。做法可依既有網站與團隊規模調整，不預設某個內容管理系統會提供特定功能。
指定主文與語系版
多語頁面應先把「同一個內容」和「不同語系的版本」分開管理。建立內容紀錄時，先填一個穩定的內容代號、主文語言、主文網址或內部位置、負責人、讀者任務，以及預計涵蓋的語系；每個語系頁面再記自己的網址、譯稿負責人、核稿人和狀態。這樣更新某頁時，團隊能先找到它所屬的主文和其他版本，不必靠相似標題猜測，也不會把同題不同篇誤當成譯稿。
主文原則上是定義事實、結構與內容目的的版本，不代表它永遠只能用某一種語言。若受眾主要在台灣，以繁體中文為主文只是這個專案的選擇；新專案可因實際編輯流程指定英文或其他語言。把決策寫在紀錄裡，並標明主文變更由誰核准；翻譯者可調整語序、例子和說法，但遇到價格、承諾、條件等事實差異時，要回到主文負責人確認，不要自行補完。
可用一列對應一個語系的矩陣，而不是把六份文件的狀態塞進檔名。假設某篇文章要提供繁中、英文、日文三版，矩陣列出同一內容代號下的三個頁面，主文欄標成「來源」，其餘兩列各有翻譯與核稿欄。若再新增一個語系，只增加一列，不改內容代號。當兩個版本內容差異很大、讀者任務不同，或當地資訊必須另寫時，先判定是「在地化版本」還是獨立文章，再決定是否共用代號。
若主文與譯文因法規、例子或受眾需求需要不同資訊，紀錄例外原因、適用地區與核准者，避免下一次更新時機械複製。以內容代號串起關係，並不表示各版必須逐句相同；它表示團隊知道哪些差異經過決定，哪些只是尚未同步。
安排翻譯核稿角色
角色安排要落在交付物上，不只列出職稱。主文作者負責完整表達事實、前提、數字和來源；翻譯者對照最新版主文，保留意思並標記無法直譯或需在地化的句子；核稿者檢查語言自然度、讀者理解、術語一致與版面脈絡；發布前的內容負責人確認此版本與核准稿相同，並處理未決問題。小團隊可由同一人兼任兩個角色，但同一欄仍要寫明最後由誰承擔核准責任。
交接時附上內容代號、主文版次、變更摘要、目標讀者、語氣、不可改動的事實、需保留的連結，以及回覆期限。核稿者應能看到譯稿對應的來源段落，否則容易只改字面而漏掉原文已更新的限制。若主文作者也負責核稿，請安排另一位熟悉目標語言的人讀一次關鍵段落，特別是數字、否定句、條件和行動指示；無合適人選時，將未確認處列為待處理，不要把「讀過」寫成「已核准」。
分工可依內容風險決定：品牌稱呼、付款條件、產品限制或步驟變更，要求作者回覆疑點後再核稿；單純調整標題或段落順序，可由核稿者直接提出建議。每個批註都要能指向一段文字，並標明「問題、建議、待誰決定」，避免模糊的「看起來怪怪的」。假設譯者發現來源同時寫「每月」與「每季」，先暫停該句並請主文負責人選定，再同步修正其他語系，不能讓各譯者自行猜。
角色表也要包含替補與回覆方式，例如主要核稿人休假時由誰接手、意見分歧由誰裁決。這些規則不是為了多一道簽核，而是讓版本卡住時知道下一個動作。
同步版本與日期
版本與日期需要同時回答兩件事：這份文字基於哪一版主文，以及它何時完成核稿。可使用簡單版次，例如主文 1.0、1.1、2.0；先在團隊內定義何種更動要升版。修錯字或格式可記在修訂紀錄，數字、條件、流程、責任等讀者會依循的內容改變，應更新主文版次，並標出受影響的段落。譯稿則記錄來源版次和自己最後修改日期，避免只寫「最新版」卻無法比對。
日期欄也要拆開：文章對外顯示的日期、文字最後更新日期、該語系核稿日期和排定發布日期用途不同。不要因翻譯完成就把主文的更新日期改成今日，也不要以共同日期掩蓋譯稿較早完成的事實。若網站只能呈現一個日期，先依團隊規則選擇並記錄其意義，內部仍保留各語系核稿時間。讀者看到的日期應反映實際內容狀態，而不是排程或文件複製時間。
假設主文從 1.2 更新到 1.3，只改了聯絡方式，三種語言版本都要比對該欄，但不一定整篇重譯；在每列記「已比對 1.3」和核稿人，才能知道同步完成。若改的是資格條件，則標出所有引用條件的段落與頁面，等相應語系確認後才標為最新。可用修訂紀錄寫日期、主文版次、改動摘要、影響語系、處理人和結果。若三個語系分別花 20、30、25 分鐘，核稿工時合計為 75 分鐘，這只是此假設案例的排程數字，不是通用效率基準。
不要用檔案修改時間當唯一證據：複製文件可能刷新時間，手動另存也可能讓舊譯稿看似更新。每次結案前，比對引用的主文版次、已處理的差異和核稿紀錄；若任一欄缺失，狀態維持待確認。
標記未完成譯稿
未完成譯稿要讓讀者和團隊都看得出差異。內部狀態可用「待翻譯、翻譯中、待核稿、待主文確認、核准、已上線、需重查」等簡單詞，先定義每個狀態代表的下一步與負責人。狀態只表示工作進度，不等於語言品質評分；把阻塞原因、提出日期和下一位處理者另外記下，便能區分「尚未開始」和「已送出但等待決定」。
譯稿完成但尚未核稿時，標成待核稿並附上來源版次；核稿後若發現主文仍有疑義，退回「待主文確認」，不要留在含糊的「進行中」。主文一旦更新，找出哪些譯稿引用舊版，將其標成「需重查」，並列出受影響段落。定義狀態時，至少為每個轉換寫一句條件，例如「核准」需要核稿人確認文字，且所有疑點已關閉。
對外頁面如何處理，須依網站現有能力和讀者風險確認，不能假設系統會自動替讀者切回主文。若該語系尚無可讀版本，可暫不顯示不完整內容，或提供清楚標示的替代路徑；要避免把機器直譯或舊版內容呈現得像已核准。若資訊具有時效或會影響讀者行動，先決定是否暫停該語系入口，並在工作紀錄指定恢復條件。
例如假設英文版等待核稿、日文版尚未翻譯，表上分別寫明「核稿人、預計回覆日」與「翻譯負責人、開始日」，並標記目前可使用的版本及其日期；每日檢查只追蹤到期項目與新增變更，不必把所有語系都重開。若預計日期已過，更新責任人和下一步，不要沿用舊日期造成已排定的錯覺。每次狀態改變都留存操作者和時間，確保交接可追溯。
建立術語核對表
術語核對表的用途是讓不同語系用一致概念溝通，不是把每個詞逐字固定翻譯。每筆至少記中文詞、概念定義、適用情境、各語系建議用法、避免的混用詞、範例句和最後確認人。若同一詞在一般文章與產品介面意思不同，拆成兩筆並說明使用範圍；若仍無共識，標成「待決」，讓翻譯者知道暫時不要自行定案。表格也應標出更新日期和適用版本，舊說法才能被辨識。
先從本篇與既有內容抽出反覆出現的名詞、按鈕文字、角色名稱與容易誤解的縮寫，再請熟悉業務的人確認含義。不要直接把市場常用譯法當成品牌決定，也不要為了表格完整而加入從未使用的詞。翻譯者遇到清單外的新概念，可在譯稿批註提議翻法、定義和上下文；核定後再補入表格，並檢查仍在使用舊說法的頁面。這樣詞表隨內容生長，而非成為未維護的大字典。
例如假設團隊在「主文」一詞上常混用「原稿」與「來源版本」，可先定義本篇所稱主文為承載已核准事實與結構的基準內容，再記錄各語系團隊採用的自然說法；不應強迫所有語言沿用同一字形。表內的範例最好放完整句子，讓核稿人看得出詞在句中的功能，而非只看單詞對照。對無法直譯的文化情境，提供意圖與讀者背景，讓譯者選擇等效表達，並回報差異。
核稿時可按詞表搜尋關鍵詞，逐一查看標題、正文、圖說、按鈕和替代文字，檢查概念是否一致；同時允許因語法自然調整詞形或語序。若某語系需採不同慣用語，將例句、原因和確認者補入，不要私下另造一套。詞表由內容負責人定期清理：合併同義項、保留仍有效的別名、註記廢止詞，並提醒使用中的頁面重新比對。
檢查語系切換路徑
語系切換要帶讀者到同一內容的對應版本，不能只把他送到另一語言的首頁。逐篇維護語系對照表，列出內容代號、各語系網址、狀態、主文版次和最後檢查日；遇到新語系尚未完成時，按已定規則隱藏該選項或提供明確替代頁，並確認替代頁不會讓人誤以為內容完全對應。每篇發布前實際逐個點選切換，再用瀏覽器返回，確認語系與內容脈絡仍清楚。
檢查時先從文章中段而不是只從首頁測試，因為讀者可能由搜尋結果或外部連結進站。確認切到另一語言後，標題和頁面內容相符，網址指向對應文章而非錯誤語系；再檢查返回原語言、下一篇/相關文章、圖片替代文字和主要行動連結。手機畫面也要看得到目前語言與可切換選項；不要只憑桌面截圖判定路徑可用。若頁面根本沒有對應版本，先依規則退回明確替代方式，不能直接拼一個看似合理的網址。
技術欄位例如語言標記、canonical 或 hreflang，可列入待工程確認的清單，並以網站現有實作與實際頁面結果為準；本文不假定每個站使用相同設定。編輯檢查聚焦讀者看到的文字、切換目的地與版本狀態，工程檢查再比對網址與標記。發現切錯時，記錄原頁、點選的語言、預期頁面和實際結果，回報負責人並複測同一條路徑，避免只修首頁選單而漏掉文章內連結。
可先挑一篇近期需要更新的文章，建立內容代號與語系列，填入主文版次、譯稿狀態及核稿責任，再由每種語言各走一次切換路徑，當天即可找出缺漏。若要了解 ZhenheAI 的品牌資訊，可前往 ZhenheAI 官網。