MVC 5 content globalization

Question

I have a really complex situation when I need both static localization with dynamic localization in a project I'm working on.

What I need to localize:

Static pages (like: "About", "Help", "Contact"...)

For example:

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

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

This is where I'm now, and it's working.

Currently the culture is provided and specified in the routing mechanism (best for SEO), and not stored in a cookie or session.

RouteConfig.cs looks like this:

    // 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 }
    );

Dynamic pages - content users enter in their profile (like: "Full Name", "About"...)

Now here is what I have problem with...

Basically I need to allow users to enter many translations of their profile, and also pick the right translation for the user visiting the profile. In addition, if a user visiting a profile that the user didn't provide a translation for his language, I need to show him a "default" translation, but the site interface will remain in his language.

So, my approach for this:

For dynamic pages, I think I need a help from a cookie, that contains the user's culture, and eliminate the {culture} route parameter in the URL, the site interface localization will be determined from the cookie or browser (user-languages) when there's no cookie. And the content localization will be determined from a route parameter in the end of the URL "{content}".

For Example:

"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.

I reached the following conclusions:

• 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.

• 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.

Is this approach acceptable?

I can't figure what is the best practice solution in order to implement that, while preserving SEO, and friendly / easy URL?

BTW - I'm focusing on URL and SEO, database and other concerns are well performed.

Thank you!

NightOwl888 NightOwl888 · Accepted Answer · 2017-07-15T17:59:49

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.

Since you are concerned with SEO, cookies are off-limits on anonymous pages. All content on these pages should be controlled via URL.

For this scenario, I think it would be most intuitive to put both the {culture} and {content} parameter into the URL, but at opposite ends.

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

You could potentially make both of these parameters optional with a logical default with a carefully crafted routing configuration. For readability, you might consider adding a static /content/ segment before the last parameter, which will require an additional route to make both segments optional.

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

This is fine (assuming you use the URL not a cookie for the optional value as I mentioned above). This provides an easy way user to override the browser (user-languages) via URL. Since (user-languages) is a header that can be altered by firewalls, this may not be the user's true preference and if you don't provide a way to override it is a horrible UX. I also suggest making the way to override user-languages visible on the UI (via a link to the URL with the culture in it), not just available via URL.

Keep in mind search engines may not provide this header, so you should also have a fallback plan (default culture) when it is not available. Always consider the URL to be the first choice for culture when provided and ignore the (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.

You have more flexibility for URLs that can only reached by authenticated users, so using a cookie here is fine. Although, if the rest of the site puts the culture in the URL that might feel a bit odd to power users who use the URL to navigate.

Personally, I would aim for consistency with the rest of the site rather than "nice short URLs" for authenticated pages, since it is usually only anonymous pages where "nice short URLs" count for both SEO and sharing purposes. But, if you are expecting to have a lot of power users that edit the URL in the browser it may be worth considering.

MVC 5 content globalization

1 Answers