2009-03-04 27 views
9

本網站上有許多與ASP.NET MVC應用程序中的how to access RESX文件相關的問題,以及使用它們的best practices爲ASP.NET MVC應用程序使用.resx本地化有什麼好處?

但是在閱讀(第一次我可能會添加)MSDN article on resources我還想知道是否還有使用RESX文件的優點,因爲我不打算使用服務器控件。 Theres所有關於'隱式'和'明確'本地化的討論,但我不會從MVC中受益。

最終,我的應用程序將需要按鈕和菜單項的字符串資源,並且還需要更長的HTML項目以獲得更長的雜項內容。我想使用CMS作爲更長的項目,因爲我非常確定我不想將它們粘貼到RESX文件中。

新的應用程序中是否有任何令人信服的理由使用或不使用ASP.NET資源。我將假設任何未來的MVC增強功能或RESX增強功能都能夠協調一致地工作,但就目前而言,我只能看到一個令人欣慰的IDictionary。

我應該繼續使用RESX還是看看其他地方?我是否應該考慮針對RESX設計的各種資源的CMS?

任何經驗教訓將不勝感激。

回答

9

有幾個優勢,以基礎設施RESX:

  • 你不必加載正確的每個語言的資源。線程的語言環境建立後,CLr會負責找到合適的程序集並加載資源。
  • 很容易將針對本地化的語言環境特定資源交給第三方。
  • 存在非本地化資源的默認回退機制。

還有一個特別不利的RESX方法:

  • 很難支持翻譯模型,其中用戶爲您翻譯的資源。

我想詳細介紹一下最後一點。以Facebook翻譯模型爲例。 Facebook有相當簡單的方式讓人們提供並投票翻譯各種資源。如果這些數據存儲在數據庫中,則可以在正確的編輯過程之後使用它們,而無需重新構建和重新部署應用程序。使用RESX模型時,資源程序集將不得不重建和重新部署,根據部署過程,成本可能會很高。因此,在決定使用什麼本地化流程之前,我會考慮誰將進行本地化以及在已部署主應用程序之後本地化資源的部署過程是什麼的決定。

編輯:我忘了提及這些考慮正交於ASP.NET框架選擇(MVC或WebForms)。

4

我會說「是」,resx文件仍然是新應用程序的一個很好的選擇。我不認爲ASP.NET MVC特別改變了有關存儲字符串的任何內容。

怎麼樣使用資源的偉大是

  • 他們很容易管理
  • 本地化您的網站是不是沒有資源,更容易的任務(我強調容易)
  • 你可以隨時替換資源存儲,因爲資源使用提供者模型。您可以切換出數據庫條目的resx文件,而無需更改網站的實施。

我推薦「站點字符串」的資源文件,這些文件與您可能頻繁編輯的大塊數據不同。因此,對於一個完整的建議,我會說使用資源文件(resx開始)的按鈕,標籤等,和一個內容豐富的內容的CMS。

+0

謝謝伊恩。這就是我傾向於的方向。我只是沒有必須本地化任何事情。事實上我不需要本地化任何東西,但我想要做好準備。我只是發現自己跳過了大部分內容,因爲不相關,這讓我很好奇我應該怎麼做 – 2009-03-04 05:31:10

+0

我們正在經歷現在本地化網站的痛苦。對於我們來說,這是一組一起工作並應用了幾年的應用程序。這不是一個小任務:)。至少在承諾如何處理事情之前至少要考慮這一點。我希望這可以幫助你,並節省你的工作:) – 2009-03-04 05:33:30

+0

我想知道如果有任何抽象層的資源,例如,所以我可以在每個字符串的開頭添加*,然後知道我有什麼,沒有本地化。顯然,使用HtmlHelper,我可以很輕鬆地做到這一點 - 但也許還有一些其他的東西需要學習 – 2009-03-04 05:38:36

3

如果您打算使用Resx而不是像使用MVC那樣使用服務器控件,爲什麼不擴展MVC Helper方法以便您可以創建本地化的標籤和文本?然後只需在輔助方法中調用資源中的文本。

例如 '<%= Html.CultureLabel( 「ResouceId」)%>'

或 '<%= Html.CultureButton( 「姓名」, 「ResouceId」,HtmlButtonType.Button)%>'

剛一個想法。

對於文本來說,管理站點的全球化更容易。

相關問題