線畫錯了地方
這個網站本身曾經是這樣：內容（服務、案例、FAQ）進資料庫，而導覽列文字、hero 標語、表單標籤、錯誤訊息寫死在前端。那條線看起來很自然 —— 這是程式，那是資料。但它是從工程師的角度畫的。
從「誰要改它」的角度看
實際上，會想改 hero 那句標語的人，跟會想改服務說明的是同一個人。而且改標語的頻率還更高，因為它是整個網站最多人看到的一句話。把它留在程式碼裡，等於規定「改一句文案要發一次版」，而那個規定的執行者不是產品經理，是工程師的行事曆。
代價是一張很扁的表
做法沒有第二套機制：介面文字跟內容一樣是 (locale, key) 的一列，一樣由後台編輯，一樣走同一條快取。差別只在它是扁的，而且 key 是我們定的。不做巢狀結構 —— 巢狀會讓後台沒辦法用一個搜尋框找到「那句話在哪」，而那正是編輯唯一需要的功能。
找不到的 key 要顯示 key 本身
一個細節，但它決定這套機制會不會爛掉：查不到的 key 渲染成 key 的字串本身，不是空字串。空白在頁面上看起來像一個設計決定，可以活好幾個月；而 nav.pricing 出現在導覽列正中間，當天下午就會被修掉。
一個沒預料到的好處
三個語系的文案從此可以不同步地改。日文版想把某句話改短，不需要等中英文一起想好 —— 因為它們是三列，不是一列的三個欄位。這件事在採用翻譯表的架構裡做不到，而內容本來就會分岔。
什麼不該進去
不是所有字串都該搬。錯誤代碼、日誌訊息、給機器讀的東西留在程式裡，因為改它們的人本來就是工程師，而且改動要跟程式碼一起被 review。判斷標準始終是同一個：誰會想改它，以及他改的時候希望發生什麼。