我們正在尋求國際化的Web應用程序。最好是輸出翻譯服務器端（它是用.net 4 C＃編寫的）還是客戶端（Javascript）？Web應用程序國際化，做它服務器端還是客戶端？
我們已經開始進行這項工作了，客戶端通過創建一個JS文件，其中包含一個包含英語詞組作爲鍵的對象（因此開發人員理解每個消息在上下文中的含義），值爲字符串向客戶顯示任何警報和提示。我們正在考慮將此延伸到整個前端的所有措辭。
這是一個好主意還是最好進行這種工作的服務器端？
更新： Incase有助於擺脫論點，我們不在web應用程序中大量使用服務器端控件，我們的大多數控件都是基於jQuery/JS的。
更新：這個特殊的應用程序是不公開可見的（除了登錄頁面），所以搜索引擎優化的關注是不適用的。
I18n的第一條規則：遵循標準的方式。不要重新發明輪子。對於Asp.Net來說，這意味着服務器端的國際化。
那麼，有點。如果您碰巧擁有大量動態創建的控件，您仍然需要一些用於客戶端腳本的本地化機制。你可以集中它，即創建一個全局轉換字符串數組和模型+控制器，這樣你就可以通過AJAX調用來填充它（儘管X最好由J替換爲JSON ...）。
無論如何，你的模型應該簡單地從資源文件中檢索適當的字符串，並且控制器應該將JSON提供給客戶端（好主意是實際請求更小的塊，即只是給定視圖/屏幕的翻譯而不是整個應用程序的翻譯）。
正如你所看到的，最好的將是一些混合的方法。出於很多原因，最好爲整個應用程序使用一個本地化模型，即僅使用* .resx文件。
此外，還有much more國際化，而不僅僅是簡單的字符串外部化...
感謝您的支持，我同意最好將所有翻譯以一種格式保存並提供給翻譯人員。我沒有想過從resx文件中檢索單個字符串的AJAX。但是，我認爲我將會有一個腳本，它會將所有需要的翻譯排隊，並在完成加載所有控件時作爲單個請求發送給頁面上所有控件所需的特定翻譯字符串。這意味着只需提取一次所需的翻譯而不單獨收集，因爲請求開銷在控制權重形式上會變得很重。 – killercowuk 2012-07-09 11:52:36
SEO明智的，我會建議做服務器端，並提供應用程序在單獨的網址下。
例如：
www.application/EN/
www.application/ES/ ...
感謝丹尼爾，這個應用程序只在訂閱的基礎上可用，所以它的內容是不公開的。但我讚賞評論。 – killercowuk 2012-07-05 14:02:33
好的不知道。如果你選擇做客戶端，我已經看到一些解決方案將語言鍵/值存儲在json文件中。這種處理方式很容易，而且易於編輯。祝你好運。 – Daniel 2012-07-05 14:10:39
謝謝丹尼爾，對不起，我沒有提前說明。我也看到了一些JS翻譯工具，這使我走上了這條道路。特別是對於所有基於jQuery的控件。 – killercowuk 2012-07-05 14:13:44
如果你是顯示然後通過客戶端的國際化走只爲靜態內容到用戶。 ，如果你顯示的內容/消息是動態的，你應該使用服務器端。 但你如何檢測用戶區域設置？
嗨shreyas，用戶區域設置是Web應用程序中的用戶設置（這意味着如果他們從國外訪問，他們仍然可以在他們的家鄉時區/語言等中看到它）。從服務器端（通過Ajax）與JavaScript中的Key/Value對象進行比較，並向用戶顯示相關值。 – killercowuk 2012-07-05 14:44:20
我會投票服務器端，但有投票的感覺。 – duffymo 2012-07-05 13:57:43
是的，不幸的是，我可以看出這可能會有很大的爭議，但我最好喜歡聽到過去可能不得不做出類似決定的人。 – killercowuk 2012-07-05 13:59:49
客戶端===可訪問性失敗 – Matt 2012-07-05 13:59:50