翻譯動態內容的設計模式？

我見過一些應用程序商店單獨記錄在每個區域設置翻譯，但我想通過序列化轉換使記錄所有翻譯存儲，我的意思是

$post_title=serialize(['en_US'=>$enUS['title'], 'fr_FR'=>$frFR['title']]); 
$post_content=serialize(['en_US'=>$enUS['conttent'], 'fr_FR'=>$frFR['conttent']); 


$sql="INSERT INTO `posts` (`title`, `content`) VALUES(:post_title, :post_content)"

它是一個不好的做法？

來源

2014-10-09 MTVS

在每個語言環境中存儲翻譯記錄的原因是隔離。這是有道理的，因爲當用戶請求英語時，您不必訪問法語或西班牙語。是美國的GB或英語的具體英語。 – Surya 2014-10-09 07:17:00

假設（從INSERT查詢），您使用的是關係數據庫，它可以被認爲是不好的做法，因爲：

時間和內存開銷：要加載後的任何語言，您必須查詢$post_title和$post_content這些是所有語言的序列化數據，因此您的數據庫查詢結果會佔用較大的內存空間。然後，您必須反序列化字段以獲得所需語言的內容，這也意味着額外的週期和不必要的開銷，前提是前端設計不需要它;即您不會同時以所有可用的語言顯示帖子。
Concurrency：如果兩個翻譯更新同一職位翻譯成各自的語言正好在同一時間。
打破不透明：由於在評論中提及了，在這種情況下，序列化的另一個問題是打破了你的數據庫接口提供預期的抽象和封裝。在處理本地化數據時，這可能不是一個大問題，但是如果您的DBMS爲您提供了列級權限，那麼序列化一列中的所有內容將阻止您使用該功能。
不一致數據建模：通過在這種情況下使用序列化，概念數據模型（網站，後多語言內容的）最終被不相干的邏輯數據模型（$post_content比其他東西以期望的語言發佈內容）。簡單地說，通過查看數據模型，我們不能說這些表格是由多語種網站使用的。
國際問題：將各種語言混合爲一列中的序列化值限制了對您的內容使用多種編碼的可能性;例如保留日文Shift-JIS，拉丁文德文1，以及其他一切UTF8。此外，它使檢查mojibake或其他編碼問題更加困難，而不會反序列化數據。

它可以被認爲是一個很好的解決方法，如果：

顯示所有語言一起：......你永遠不分開顯示的翻譯，他們總是出現或一起編輯。
保留傳統數據模型：...您希望將數據保留爲傳統模型。人們不需要改變現有的數據模型來爲多語言內容開闢道路。這有助於國際化傳統軟件，而不會過多地處理數據模型和處理數據庫遷移。

來源

2014-10-11 03:16:36 Shervin

翻譯動態內容的設計模式？

回答

相關問題