動態數據的本地化

我正在尋找關於本地化存儲在數據庫中的數據的最佳做法的建議。我正在研究一個Web應用程序，其中所有靜態文本都使用文件進行本地化。我們有幾種管理員可以使用存儲在數據庫中的UI進行配置的選項，並需要對這些值進行本地化。動態數據的本地化

我們想出了幾個可能的想法。你對這些解決方案有什麼想法？是否有更好的選擇，甚至是標準的最佳做法？

每領域的專業本地化

這是提出了best practices for multilanguage database design解決方案。我們將爲每個本地化字段創建一個單獨的表。例如，假設我們有表colors與color_id，color_name和color_description列，我們可能爆發出來到color表與非本地化數據和color_translations表color_id，locale，color_name和color_description領域。

但是，我們的客戶經常會將本地化文件發送給第三方來進行翻譯，這變得棘手。

單桌本地化

另一種選擇是建立一個單一的表來表示所有的數據庫本地化：

CREATE TABLE localized_text 
(
    key   VARCHAR(256) NOT NULL, 
    locale  CHAR(5) NOT NULL, 
    value  VARCHAR(256), 
    PRIMARY KEY (key, locale) 
);

這會更容易場外定位出口，但增加了間接的程度。

來源

2010-06-28 Ross

是否有這些「幾個選項」不僅存儲爲數據庫中的代碼並在應用程序展示級別進行翻譯的原因？無論如何，我認爲選項一是更清潔，因爲一個巨大的桌子有很多不同的翻譯許多差異。模型可以很快地變得很糟糕 – 2010-06-29 13:32:10

我認爲只是將代碼存儲在數據庫中的主要反對意見是用戶必須去兩個不同的地方進行設置。對於那些將本地化文件發送給翻譯公司的較大客戶而言，這並不理想，但對於小客戶來說並不理想。即使是大公司也必須將用戶界面中的密鑰複製到文件中進行翻譯。一個可能的解決方案可能是更新UI以根據需要修改本地化文件。有沒有人有任何想法呢？ – Ross 2010-06-29 16:15:33

做選項＃1並實現一個簡單的導入/導出工具，供客戶用來翻譯應用程序之外的自定義內容。 – 2011-08-18 03:21:08

我們將爲每個本地化字段創建一個單獨的表。例如，假設我們有桌子的顏色與color_id，color_name和color_description列....

假設你colors表只有靜態文本，顯而易見的選擇是一列添加到它，或許命名locale併爲您關心的每個語言環境添加行。然後加入客戶的區域設置以生成您想要的單一描述。

爲此，您必須將靜態描述與區域獨立數據分開，因爲本地化描述引入了多對一關係。作爲一種權宜之計，您可以將英文描述留在主表中，並在所有對它們的引用都消失後放下。

來源

2013-03-14 04:43:19

動態數據的本地化

回答

相關問題