摘要
Magnolia CMS 多語言開發的核心，不只是增加語言選項，而是釐清網站、語言、市場與內容之間的關係。本文從網站樹、國際化欄位、內容重用、模組拆分及發布驗收五方面，說明如何建立可擴展的多語言架構，並降低拓展新市場時的重複開發與維護風險。
1. 前言：多語言專案為何容易在拓展第二個市場時失控
不少 Magnolia CMS 開發專案在首個英文網站上線時看似順利，但隨著德語、法語、日語或區域網站陸續加入，頁面複製、元件分歧、配置覆蓋及發布衝突等問題便會集中浮現。問題通常並非平台功能不足，而是專案初期沒有明確界定「哪些內容由全球共用，哪些內容可因應當地需要調整」。
對於採用 Magnolia CMS 建設的全球化企業網站，開發團隊應先釐定內容變更的界線，再決定網站樹、網站定義、範本與模組的拆分方式。Magnolia 既支援多語言內容樹，也可透過 Multisite 管理多個單語言或多語言網站；具體架構應按域名、資訊架構、權限、發布節奏及本地化差異作出選擇，而非一律採用單一樹狀模式。
本文所指的「多語言網站架構」，是指在同一個 Magnolia 執行個體內，統一規劃網站定義、語言配置、內容模型、權限、域名及發布流程，讓全球共用內容得以重用，同時容許不同區域市場在受控範圍內進行本地化。
2. 問題一：網站樹應按語言還是市場拆分
在 Magnolia CMS 開發初期，首要工作不應是建立不同語言的頁面，而是判斷業務究竟屬於「同一網站的語言版本」，還是「不同市場的獨立網站」。
若各市場的資訊架構、產品組合、案例、法規說明及 CTA 大致相同，可採用一個主網站配合多語言內容的方式；若不同區域在品牌、域名、頁面結構、發布節奏或內容權限方面存在明顯差異，則較適合拆分為多個網站定義。
Magnolia 的 Multisite 模組可在同一個執行個體內管理多個網站，並為不同網站配置獨立的範本、主題、域名、語言環境及繼承關係。
建議先回答以下三個問題：
內容差異是否顯著
可在專案中設定差異比例，作為內部判斷準則；若大部分頁面均需重寫、重組，或採用不同的產品及合規內容，便應優先評估按市場拆分網站。
區域團隊是否擁有獨立發布權限
若地區團隊需要自行發布活動及頁面，便應分隔權限和網站根目錄。
域名與 SEO 策略是否不同
不同國家的域名、目錄結構或 URL 策略，應在網站定義階段確定下來。
3. 問題二：語言欄位、區域差異與內容回退應如何設計
第二類常見的 Magnolia CMS 開發難題，是把「介面語言」、「內容語言」和「市場內容」混合在同一個欄位模型內。這會令編輯人員無法分辨哪些欄位需要翻譯，開發人員亦難以判斷本地內容缺失時應顯示甚麼。
較穩健的做法，是將內容分為三個層次：
全球共用資料層
產品型號、技術參數、品牌名稱及認證編號等資料，不應因語言不同而重複維護。
可翻譯內容層
標題、正文、按鈕、SEO 欄位、圖片說明及下載資料。
區域營運層
案例、聯絡人、活動、服務承諾、法律說明及市場專屬 CTA。
Magnolia 的內容國際化資料通常儲存在帶有語言後綴的屬性中。使用 Delivery API 時，應按所採用的端點類型配置國際化處理方式，並明確訂定語言選擇及回退規則；預設的節點與屬性端點不會自動按用戶端語言傳回本地化值，因此不能只依賴前端作臨時判斷。
4. 問題三：元件重用與結構化內容應如何分工
優質的 Magnolia CMS 開發，不應將所有內容直接寫入頁面元件。頁面元件適合控制版面與互動；產品、案例、活動、專家、門市及下載資料等可高度重用的資訊，則應集中存放於結構化內容庫內統一維護。
Magnolia 官方文件指出，編輯人員可透過 Content App 維護內容項目，再由元件在多個頁面中引用，避免重複輸入相同資訊。
實務上可採用以下分工方式：
元件負責展示
例如 Hero、產品卡片、案例列表、下載入口及 CTA。
內容庫負責資料
例如產品屬性、客戶案例、區域聯絡人及資源檔案。
頁面負責組合
按市場需要選擇元件與內容項目，而非複製整個頁面的內容。
這種方式尤其適合採用 Magnolia CMS 建設的全球化企業網站：總部更新一項產品資料後，多個語言頁面可同步引用；區域團隊只需維護本地案例及符合市場需要的表達方式。
5. 問題四：模組與配置如何避免複製貼上
如果將 Magnolia CMS 開發的所有配置都集中在單一模組內，短期看似較容易部署，長遠卻會令範本、對話框、網站定義、權限配置及環境參數互相影響。更合適的做法，是按照「核心能力、網站能力、業務能力」拆分模組。
建議採用以下拆分方式：
Core 模組
通用元件、基礎欄位、共用樣式及公用工具類別。
Site 模組
網站定義、主題、頁面範本、語言及域名映射。
Feature 模組
產品中心、案例庫、資源下載、表單或推廣活動。
Integration 模組
CRM、PIM、DAM、搜尋或第三方 API。
Magnolia 建議使用 YAML 定義範本、對話框、應用程式及其他可配置項目。實施團隊可透過定義繼承、裝飾或按模組拆分配置，重用核心能力，並只覆蓋必要的市場差異；如涉及自訂 Java 程式碼，則需採用 Maven Module。
6. 問題五：發布、API 與驗收應如何設計
當 Magnolia CMS 開發進入交付階段，最容易被忽略的是「內容能否安全地發布至正確的市場」。多語言專案不應只測試頁面的視覺效果，還應涵蓋網站映射、語言切換、內容回退、快取、API 欄位及權限邊界。
建議將以下項目納入驗收清單：
域名與語言映射
域名、網站根路徑與語言環境是否正確映射；
區域編輯權限
區域編輯人員是否只能修改獲授權的網站及內容；
跨市場影響
更新頁面、元件及內容庫後，會否影響其他市場；
API 語言回退
API 是否按指定語言傳回內容，並正確處理缺少資料的欄位；
發布範圍
發布工作是否可按網站或內容路徑控制範圍。
Magnolia 的模組描述檔用於識別模組及其相依性：Light Module 在模組根目錄使用 module.yaml，Maven Module 則在 META-INF/magnolia 路徑下使用 XML 描述檔。部署與版本管理應將配置、程式碼及相依關係一併納入版本控制，避免只在正式環境的後台手動修改。
7. 常見問題（FAQ）
Magnolia 多語言內容與多個獨立網站有何分別？
多語言內容適用於同一網站下資訊架構和業務規則大致相同、主要差異在於語言的情況；多個獨立網站則適用於域名、內容結構、權限、產品組合或發布流程具有明顯市場差異的情況。
Magnolia Delivery API 會自動傳回與用戶語言相符的內容嗎？
不一定。預設的節點與屬性端點不會自動按用戶端語言選擇本地化值。專案需根據端點配置、屬性命名及國際化處理方式明確傳入語言，並訂定翻譯缺失時的回退規則。
頁面元件與 Content App 內容應如何分工？
頁面元件負責版面、互動及內容組合；需要跨頁面或跨網站重用的產品、案例、聯絡人和下載資料，則較適合採用結構化內容類型，並透過 Content App 統一維護。
Light Module 與 Maven Module 應如何選擇？
若只需透過 YAML 配置範本、對話框、應用程式、內容類型及前端資源，可優先採用 Light Module；若需要自訂 Java 類別、複雜的後端邏輯或編譯相依性，則應採用 Maven Module。
8. 結語
真正可擴展的多語言專案，並非「複製更多頁面」，而是建立清晰的網站邊界、內容邊界與模組邊界。Magnolia CMS 開發的長期價值，取決於全球內容能否重用、區域差異能否受控，以及拓展新市場時是否毋須重新建構核心架構。
企業在選擇 Magnolia CMS 實施夥伴時，應重點評估對方是否具備內容建模、網站架構、模組治理、API 整合及多環境發布經驗，而不只是能否完成頁面製作。
對於持續拓展多個市場的企業而言，Magnolia CMS 開發應被視為內容營運基礎設施，而非一次性的企業網站專案。歡迎了解凝新科技 (LeadsTech) 的企業級網站與 CMS 服務，或前往 Contact Us，與我們討論多語言架構、模組拆分及實施方案。
延伸閱讀
- 面向全球品牌的 Magnolia CMS：企業級內容管理與模組化架構
了解 Magnolia 如何支援企業級內容建模、模組擴展及多網站管理。 - 多語言企業網站建設的五大本地化策略與 CMS 技術選型指南
了解多語言內容、區域營運與 CMS 治理之間的協作關係。
