在ASP.NET

我想開發的應用本地化，而不是RESX文件SQL以下，但不知道如果它已經存在在那裏：在ASP.NET

我需要爲分配和管理本地化文本值一個基於SQL的解決方案一個asp.net站點，而不是使用RESX文件。這有助於在網站上保留文本，而無需在需要更新時進行部署。

謝謝。

2010-04-11 Laith

我聽說你關於站點重新啓動時，當你在一個新的resx – 2010-04-11 17:06:03

我想知道你當時的結論，因爲我今天在類似的情況。 – Helbo 2014-03-04 10:28:20

我們實際上走了這條路，最終導致了一個非常緩慢的網站 - 剝去基於SQL的翻譯機制，並使用ASP.NET資源爲我們提供了顯着的性能提升。所以我不能真正推薦你做同樣的事情....（是的 - 我們緩存和優化吞吐量和一切 - 而基於SQL的東西仍然顯着較慢）。

你會得到你所付出的 - 基於SQL的方法在能夠在飛行中「翻譯」並修正錯別字和內容方面更加靈活。但最終，在我們的應用程序（當時的Web 2.0，.NET 2.0）中，使用資源證明是唯一可行的方法。

來源

2010-04-11 17:23:16

在我創建的應用程序中，我們正在考慮將這些資源轉移到數據庫中。我總是想知道這樣做的表現（我知道會有）。 – Thomas 2010-04-11 17:35:39

我完全不同意。翻譯數據非常容易緩存，並且執行良好的解決方案，性能不應該成爲問題！ – Robert 2010-04-11 17:42:53

@Robert：你可以自由不同意 - 我只能談論我們的經驗。而且我們也做了一些非常積極的緩存 - 從來沒有像RESX那樣獲得遠遠超過的性能。這是我們的故事。 – 2010-04-11 18:05:09

我們做了這個（基於SQL的翻譯），我們對結果非常滿意！我們爲翻譯機構開發了一個界面，以在線執行頁面更新。作爲副作用，該解決方案開始用作內容管理系統。如果你緩存你的數據，性能不是問題。缺點是，我們投入了數百個小時到我們的解決方案。（我猜600多個小時，但我可以檢查。）。

來源

2010-04-11 17:41:44 Robert

@羅伯特，這是我想象的。我的網站真的很大，它更難做出像文本，簡單樣式，顯示/隱藏元素，管理網站菜單等最小的更新......等等。我通過構建基於小型SQL的管理系統這最終將添加到整個網站的CMS。我的兩個標題這條道路主要問題是：1 數據庫負載 2-管理本地的發展環境和愛的環境之間的文本和配置你能告訴我更多關於你的項目，範圍，負荷大小。 ..等等？謝謝。 – Laith 2010-04-15 12:28:26

我們每天峯值達20 000人次，峯值200人同時活躍用戶。我們將所有翻譯緩存在ASP.NET緩存中。 SQL-Load沒有這個問題。當有人編輯翻譯時，緩存會失效並從數據庫中重新填充。（我不確定這裏是否有任何細分。）我們將翻譯存儲在3個表格中。「Translaiton」，「TranslationGroup」，「TranslaionValue」。我們目前有24738個TranslationValues（25種左右的語言），用於2427個項目，在230個小組中進行翻譯（單個頁面是組或佔位符按主題連接）。 – Robert 2010-04-16 13:54:58

我們考慮開放我們的解決方案，但沒有找到時間這樣做。 – Robert 2010-04-16 13:56:16

我們結束了一個混合解決方案，用戶可以將內容編輯到數據庫中，但應用程序隨後創建了手動部署的.resx。

您也可以完全繞過服務器轉換，並在客戶端上使用jQuery進行翻譯，這是我成功使用的一種方法。

來源

2010-04-11 18:02:08

我不確定網站重新啓動，但至少使用.NET MVC非常方便，我沒有注意到重新啓動問題，並且如果發生，您需要多久更新一次resx文件？對於較大的項目，我用它來創建多個項目，一個是本地化，像這樣的解決方案：

MyApp.Localization
- 型號
- 頁
- File1.resx
MyApp.Core
MyApp.Web

然後在Web項目我添加到本地化項目的引用，並使用它像

@ MyApp.Localization.Model.Customer.CustomerName

@ MyApp.Localization.Page.About.PageTitle

@ MyApp.Localization.File1.Paragraph1

每次我改變了翻譯的文本，我要麼上傳更新的.dll文件或複製.resx文件。

注：您需要將您的resx文件設置爲PUBLIC，因此可以以強類型訪問。

來源

2012-01-04 01:29:26 Nestor

我創建了一個基於SQL的翻譯方案。但是，我只在請求時爲給定頁面加載所需的翻譯，並且僅爲那個特定頁面的翻譯加載。

當頁面在會話期間重新加載並緩存時，會將這些對象加載到字典對象中。然後就是基於查找的文本替換。

它幾乎全部都是動態生成的，並且包括必須翻譯的用戶定義的內容，所以靈活性是關鍵。

性能相當快，SQL查詢檢索所有數據需要更長的時間（相對來說）。

來源

2013-08-05 18:26:00 Underground

回答

相關問題