服務器端國際化與客戶端？
[英]Server-side internationalization vs client-side?
問題描述
我非常清楚如何組織服務器端國際化——檢測語言首選項並在處理請求頁面的 HTML 中打印相應的翻譯字符串。
但是在客戶端做不是更合適嗎？ 應該如何組織？ 我在想
- 檢測 JavaScript 中的語言偏好
- 請求語言文件
- 在頁面上打印字符串
我在弄清楚最后一部分時遇到問題：在頁面上打印字符串。 我們使用Handlebars ，我們的頁面結構如下：
<body>
<h1>TEXT_1</h1>
<script type="text/template">
Some {{copy}} goes here
</script>
<p>TEXT_2</p>
<script type="text/template">
Some other {{othercopy}} goes here
</script>
... and so on
現在，對於 TEXT_1 和 TEXT_2，我必須創建一個單獨的模板嗎？ 我將如何翻譯模板中的字符串？ 我無法將Some {{copy}} goes here替換為{{lang.copy_of_template1}}因為{{copy}}不會展開。
那么，做客戶端 i18n 的努力到底有沒有用呢？
3 個解決方案
解決方案1
1 2013-06-05 09:00:31
隨着在Web上實現客戶端應用程序的日趨成熟，客戶端i18n的應用正在增長。
您可能會受到http://i18next.com/docs/的啟發
解決方案2
1 2021-10-03 08:09:45
在我看來，您應該通過服務器端翻譯它，因為它更容易處理搜索引擎優化 (SEO)。
當您在客戶端執行此操作時，慢速連接可能更難看到它。 我見過一些網站在幾秒鍾后翻譯所有內容，更改所有內容，這對觀眾來說太糟糕了！
如果您選擇強制服務器端，那么您應該聽取Accept-Language標頭。 然后你的服務器必須在數據庫中搜索定義的翻譯（我個人確實為此使用了一個 json 文件）並基於它構建文本內容。
有時您被迫在客戶端執行此操作，例如 javascript 生成的沒有特定文本的彈出窗口。 但是，與其重寫您的翻譯，不如在顯示之前對您的服務器端翻譯器進行 REST 調用。
解決方案3
0 2021-10-03 18:29:56
這取決於您使用的框架。 如果您使用服務器端框架（如 ASP.NET 或 PHP），則可以在服務器端進行本地化。 如果您使用 Angular 或 React 等客戶端框架，那么您可以在客戶端執行此操作。
如果您的應用程序使用來自 REST API 的數據，您可能需要在服務器上進行一些本地化。
Web應用程序國際化，服務器端還是客戶端？
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.