我應該將桌面應用程序的本地化數據存儲在數據庫中嗎？

在我的辦公室，我們正在討論如何處理桌面應用程序本地化的最佳方式。我應該將桌面應用程序的本地化數據存儲在數據庫中嗎？

在使用資源文件似乎是一個顯而易見的選擇，我們有一個想法，我們可以使用數據庫進行集中屬地化管理。應用程序將在開始時連接到數據庫以下載所有需要的翻譯，或者可以在呈現控件時按需下載翻譯。

應用程序（使用C＃創建的）都與那處理出版物本身以及實時更新工具，幫助內部使用部署在高度控制的環境中。我們有一個文件分發存儲庫和單個數據庫服務器來處理少數衛星站點。

將數據庫是在桌面應用程序處理用戶界面翻譯一個可行的解決方案？

2016-02-12 Sebastian Kliś

聽起來沒問題，但它不是每個人的最佳方式。它可能是你的場景中最好的（首先考慮一切）。問題是爲什麼資源對你不利？爲什麼數據庫爲了能夠快速分享本地化的更新？預計會發生多久？有益處是否有缺點？只有你可以回答這些問題和其他問題。目前的問題要麼過於寬泛（如果我們試圖考慮所有事情）或者基於意見（因爲每個人都可能會考慮他的情況）。 – Sinatr

@Sinatr好吧，煽動者使用數據庫來存儲翻譯的想法是讓我們「集中管理本地化」，重新使用應用程序之間的翻譯。這當然會導致資源文件無法使用的問題 - 它依賴於網絡並且速度較慢。我想知道是否有減少數據庫缺陷的方法，仍然能夠從尖端的優勢中受益。 –

你可以構建自己的本地化。我正在使用在應用程序啓動時加載並用於通過反射來更新靜態類屬性的txt文件。然後，您只需要一個簡單的機制來獲取版本並下載完整的翻譯（如果版本比客戶端更新）。數據庫應該做的。 – Sinatr

有幾個點，你應該考慮

應用預計將增長顯著
應用程序可能需要有特殊情況（客戶特定的翻譯）
同樣translation_key有不同的值不同的屏幕/窗口/在不同的背景下
手動管理本地文件是耗時且不容易/開箱即用

如果從上面的匹配一個或多個點的應用程序（一個或多個）的業務計劃，那麼你應該考慮使用一個數據庫和服務器緩存

讓我們假設你開始增加一個新的屏幕（形式）的應用。在這種形式中，您有3個UI元素（element1，element2和element3）。應該有一個集中的本地化服務（業務對象）來完成以下

閱讀各種形式
閱讀每一個元素的形式（在這裏，你可能會過濾可能包含多語言文本如標籤的相關要素，按鈕等等，不包括面板）
爲用戶模式應用？（假設你的應用程序將在啓動/登錄時爲客戶提供選擇 - 不同的外觀和感覺，不同的文本等）
嘗試獲取翻譯密鑰從服務器構建緩存（基於字典的數據結構包含應用程序代碼（或密鑰），customerKey，translationKey和值）。翻譯密鑰可以是formName。uiElementName
如果在緩存中找不到鑰匙，試圖從數據庫中獲取它
如果在數據庫（新加入的形式，並與它的UI元素）未找到，則嘗試添加在DB（一項新內容applicationKey，customerKey，translationKey，空值）
如果發現數據庫，然後在高速緩存中添加條目
您可能希望有一個管理功能，可以清除高速緩存

現在建立一個集中的應用程序管理本地化數據庫。在這裏管理文本，您可以利用其當前正在運行的應用程序的使用情況，但也可以利用其未來的應用程序。

來源

2016-02-12 10:22:38 mariovalens

你的想法讓我思考。使用客戶端應用程序的緩存確實可以消除數據庫翻譯存儲的大多數問題。我們可以在數據庫上創建觸發器來發布對文件存儲庫的更改，然後使用我們已經擁有的更新工具將新的轉換文件分發到工作站。 –

擁有集中式本地化服務非常重要，但構建集中式應用程序來管理本地化數據庫可能是一項嚴肅的工作（時間和金錢）。如果您正在尋找快速簡單的解決方案，並且不介意商業產品，您可以探索Passport。它提供了您需要的用戶管理功能（如本地化）以及您可能需要的其他功能，但沒有時間編寫。這些通常包括：

登錄跟蹤
報告
單點登錄通過OAuth
和A（活躍用戶，註冊和登錄報道）
通過電子郵件發送用戶
基於角色的權限一堆更多

它安裝簡單，可以成功處理桌面應用程序中的用戶界面翻譯。如果您確實希望顯着增長，客戶特定翻譯Passport可以與您一起擴展。

來源

2016-04-12 16:51:22 kstra

我應該將桌面應用程序的本地化數據存儲在數據庫中嗎？

回答

相關問題