【问题标题】:MVC 5 content globalizationMVC 5 内容全球化
【发布时间】:2017-12-20 03:10:33
【问题描述】:

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

我需要本地化的内容:

  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 }
    );
  1. 动态页面 - 用户在其个人资料中输入的内容(例如:“全名”、“关于”...)

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

基本上,我需要允许用户输入他们个人资料的许多翻译,并为访问个人资料的用户选择正确的翻译。 此外,如果用户访问的个人资料没有提供其语言的翻译,我需要向他显示“默认”翻译,但网站界面仍将使用他的语言。

所以,我的方法是:

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

例如:

"domain.com/user/username" - 用于默认内容本地化(用户将设置为默认语言)。

"domain.com/user/username/en-us" - 用于英文内容本地化。

"domain.com/user/username/es-es" - 用于西班牙语内容本地化。

我得出以下结论:

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

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

这种方法可以接受吗?

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

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

谢谢!

【问题讨论】:

    标签: asp.net asp.net-mvc asp.net-mvc-5 asp.net-mvc-routing


    【解决方案1】:
    • 对于匿名用户 = 对于静态页面,本地化由 URL 中的 {culture} 路由参数确定,但对于动态页面,去除了 {culture} 参数,站点界面由 cookie 和 {content} URL 末尾的参数代表内容本地化。

    由于您关心 SEO,因此 cookie 禁止在匿名页面上使用。这些页面上的所有内容都应通过 URL 控制。

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

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

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

    当没有 cookie 时,站点界面本地化将由 cookie 或浏览器(用户语言)确定。

    这很好(假设您使用 URL 而不是 cookie 作为我上面提到的可选值)。这为用户提供了一种通过 URL 覆盖浏览器(用户语言)的简单方法。由于 (user-languages) 是一个可以被防火墙更改的标头,因此这可能不是用户的真正偏好,如果您不提供覆盖它的方法,那将是一个可怕的 UX。我还建议采用一种方法来覆盖 UI 上可见的用户语言(通过指向带有文化的 URL 的链接),而不仅仅是通过 URL 提供。

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

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

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

    就我个人而言,我的目标是与网站的其余部分保持一致,而不是针对经过身份验证的页面使用“漂亮的短 URL”,因为通常只有匿名页面才会将“漂亮的短 URL”计入 SEO 和共享目的。但是,如果您希望有很多高级用户在浏览器中编辑 URL,则可能值得考虑。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-08-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多