MVC 5內容全球化

Question

我有一個非常複雜的情況，當我需要在我正在處理的項目中使用靜態本地化和動態本地化時。

我需要的本地化：

1. 靜態的頁面（如： 「關於」， 「幫助」， 「聯繫人」 ...）

例如：

「domain.com/about」 - 用於英文本地化。

「domain.com/es-es/about」 - 用於西班牙語本地化。

這就是我現在的位置，它正在工作。

目前文化是在路由機制（最適合SEO）中提供和指定的，並且不存儲在cookie或會話中。

RouteConfig.cs看起來是這樣的：

// Localized Default: 
    routes.MapRoute(
     name: "LocalizedDefault", 
     url: "{culture}/{controller}/{action}/{id}", 
     defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }, 
     constraints: new { culture = new CultureRouteConstraint() } 
    ); 

    // Default: 
    routes.MapRoute(
     name: "Default", 
     url: "{controller}/{action}/{id}", 
     defaults: new { culture = "en-us", controller = "Home", action = "Index", id = UrlParameter.Optional } 
    ); 

動態頁面 - 內容的用戶在他們的個人資料（如輸入 「姓名」， 「關於」 ... ）

現在，這裏是我有...

基本上我需要讓用戶輸入他們的個人資料的許多翻譯，並且還挑選合適的翻譯用戶訪問個人資料的問題。 此外，如果用戶訪問用戶未提供其語言翻譯的個人資料，則需要向他展示「默認」翻譯，但該網站界面仍將保留其語言。

所以，我對這種做法：

對於動態網頁，我想我需要從一個cookie，它包含了用戶的文化幫助，並消除在URL中的{文化}路由參數，該網站界面當沒有cookie時，本地化將由cookie或瀏覽器（用戶語言）確定。內容本地化將根據URL「{content}」末尾的路由參數確定。

例如：

「domain.com/user/username」 - 對於默認內容定位（用戶將設置爲默認的語言）。

「domain.com/user/username/en-us」 - 用於英文內容本地化。

「domain.com/user/username/es-es」 - 用於西班牙語內容本地化。

我得出了以下結論：

•對於匿名用戶=的定位是通過在URL中的{文化}路線參數確定靜態頁面，但對於動態頁面的{文化}參數被消除，網站界面由cookie確定，URL末尾的{content}參數代表內容本地化。

•對於通過身份驗證的用戶=所有頁面（靜態爲&動態）本地化僅由cookie確定，這會生成一個簡短的&友好的URL，並且SEO不受影響。

這種方法可以接受嗎？

我不能確定什麼是最佳實踐解決方案，以實現這一點，同時保留搜索引擎優化和友好/簡單的網址？

順便說一句 - 我專注於URL和SEO，數據庫和其他問題都表現良好。

謝謝！

Answer 1

• 針對靜態頁面的定位是通過在URL中的{文化}路線參數確定匿名用戶=，但對於{文化}參數消除動態頁面，該網站接口從cookie確定並且URL末尾的{content}參數代表內容本地化。

既然你關心搜索引擎優化，cookie在匿名頁面上是禁止的。這些頁面上的所有內容都應通過URL進行控制。

對於這種情況，我認爲將{culture}和{content}參數放入URL中是最直觀的，但是在相反的兩端。

{culture}/{controller}/{action}/{content} 

您可能使這些參數可選用一個精心製作的路由配置邏輯默認的都。爲了便於閱讀，您可以考慮在最後一個參數之前添加一個靜態的/content/分段，這將需要額外的路線才能使兩個分段可選。

當沒有cookie時，站點界面本地化將由cookie或瀏覽器（用戶語言）確定。

這很好（假設您使用URL而不是cookie作爲上面提到的可選值）。這爲用戶通過URL覆蓋瀏覽器（用戶語言）提供了一種簡單的方法。由於（用戶語言）是一個可以被防火牆改變的標題，這可能不是用戶的真正偏好，如果你沒有提供覆蓋它的方式，那是一個可怕的用戶體驗。我還建議設法重寫用戶界面上可見的用戶語言（通過指向具有文化內容的URL的鏈接），而不僅僅通過URL可用。

請記住，搜索引擎可能不提供此標題，因此，如果不可用，您還應該有一個備用計劃（默認文化）。提供時始終將URL視爲文化的首選，並忽略（用戶語言）標題。

• 驗證的用戶=爲所有頁面（靜態&動態）的定位是僅通過cookie來確定，這使得短&友好的URL和SEO不受影響。

您有隻能通過身份驗證的用戶達到網址更大的靈活性，所以使用Cookie這邊獨好。雖然，如果網站的其他部分將文化置於可能讓使用URL導航的強大用戶感到有點奇怪的URL中，

就我個人而言，我的目標是與網站其他部分保持一致，而不是通過認證頁面的「簡短網址」，因爲它通常只是匿名網頁，其中「漂亮的短網址」同時適用於搜索引擎優化和共享目的。但是，如果您希望有大量的高級用戶在瀏覽器中編輯URL，可能值得考慮。