MVC 5 内容全球化

MVC 5 content globalization

当我需要在我正在处理的项目中同时进行静态本地化和动态本地化时,我遇到了一个非常复杂的情况。

我需要本地化的内容:

  1. 静态页面(例如:"About"、"Help"、"Contact"...)

例如:

"domain.com/about" - For English localization.

"domain.com/es-es/about" - For Spanish localization.

这就是我现在所在的位置,它正在运行。

目前文化是在路由机制中提供和指定的(最适合 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 }
    );
  1. 动态页面 - 用户在其个人资料中输入的内容(例如:"Full Name"、"About"...)

现在这是我遇到的问题...

基本上我需要允许用户输入他们个人资料的许多翻译,并为访问个人资料的用户选择正确的翻译。 此外,如果访问个人资料的用户没有提供他的语言的翻译,我需要向他展示 "default" 翻译,但网站界面将保留他的语言。

所以,我的做法是:

对于动态页面,我想我需要一个cookie的帮助,它包含用户的文化,并消除URL中的{culture}路由参数,站点界面本地化将由cookie 或浏览器(用户语言),当没有 cookie 时。并且内容本地化将根据 URL "{content}" 末尾的路由参数确定。

例如:

"domain.com/user/username" - For Default content localization (the language the user will set as default).

"domain.com/user/username/en-us" - For English content localization.

"domain.com/user/username/es-es" - For Spanish content localization.

我得出以下结论:

• 对于匿名用户 = 对于静态页面,本地化由 URL 中的 {culture} 路由参数确定,但对于动态页面,{culture} 参数被删除,站点界面由cookie 和 URL 末尾的 {content} 参数代表内容本地化。

• 对于经过身份验证的用户 = 对于所有页面(静态和动态),本地化仅由 cookie 确定,这使得简短和友好 URL 并且 SEO 不受影响。

这种方法可以接受吗?

我想不出什么是最佳实践解决方案来实现它,同时保留 SEO 和友好/简单 URL?

顺便说一句 - 我专注于 URL 并且 SEO、数据库和其他问题表现良好。

谢谢!

  • For anonymous users = for static pages the localization is determined by the {culture} route parameter in the URL, but for dynamic pages the {culture} parameter is eliminated, the site interface is determined from a cookie and the {content} parameter in the end of the URL stands for the content localization.

由于您关注 SEO,cookie 是 off-limits 在匿名页面上。这些页面上的所有内容都应通过 URL.

进行控制

对于这种情况,我认为最直观的做法是将 {culture}{content} 参数都放入 URL 中,但两端相反。

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

您可以通过精心设计的路由配置使这些参数中的两个 成为可选的逻辑默认值。为了可读性,您可以考虑在最后一个参数之前添加一个静态 /content/ 段,这将需要一个额外的路由来使两个段都可选。

the site interface localization will be determined from the cookie or browser (user-languages) when there's no cookie.

这很好(假设您使用 URL 而不是我上面提到的可选值的 cookie)。这为用户提供了一种通过 URL 覆盖浏览器 (user-languages) 的简单方法。由于 (user-languages) 是一个可以被防火墙更改的 header,这可能不是用户的真正偏好,如果您不提供覆盖它的方法,那将是一个糟糕的用户体验。我还建议在 UI 上覆盖 user-languages 可见(通过 link 到 URL 以及其中的文化),而不仅仅是通过 URL.

请记住,搜索引擎可能不会提供此 header,因此当它不可用时,您还应该有一个后备计划(默认文化)。在提供时始终将 URL 视为文化的首选,而忽略 (user-languages) header.

  • For authenticated users = for all pages (static & dynamic) the localization is determined only by the cookie, this makes a short & friendly URL and SEO is not affected.

对于只有经过身份验证的用户才能访问的 URL,您有更大的灵活性,因此可以在此处使用 cookie。虽然,如果站点的其余部分将文化放在 URL 中,这对于使用 URL 进行导航的高级用户来说可能会觉得有点奇怪。

就个人而言,我的目标是与网站的其余部分保持一致,而不是 "nice short URLs" 用于经过身份验证的页面,因为它通常只是匿名页面,其中 "nice short URLs" 用于 SEO 和共享目的。但是,如果您希望有很多高级用户在浏览器中编辑 URL,则可能值得考虑。