Culture in URL required? about xlocalizer HOT 5 CLOSED

Yes, I stumbled across that issue, too. I like the tag helper approach as it should allow me to just remove the tag helper if/when the official solution is released.

I think, by far, the RouteSegmentCultureProvider is the best solution, so I'll stick with that. I like the ability to send someone a URL with the page already localized. I have a requirement for the localization to be based off the TLD, for example, mywebsite.wales (to be localized in English) or mywebsite.cymru (to be localized in Welsh). I haven't had the chance to look into that yet with XLocalizer, but I'm hoping I'll be able to follow your advice given here for this project. That can wait until next year though. :)

Cheers
Morgan

from xlocalizer.

Hi Morgan,

The culture fallback behaviour works for the main route that ends with {culture} param even if there is no culture parameter detected in the request, basically the home page route.

But for all other routes like /en/Dashboard/ there must be a culture param in the request, otherwise the route will not match the pattern in the route table and it will break. There could be some work around for such cases like adding a second route pattern without {culture} but this will over complicate the routing table.

So if you want to use route value based localization the best solution is to guarantee the presence of {culture} param in the url to match the relevant route.

Notice:

If the application is using razor pages and controllers the route convention for both must be configured in startup:

.AddMvcOptions((ops) => {
        ...
        ops.Conventions.Insert(0, new RouteTemplateModelConventionMvc());
    })
    .AddRazorPagesOptions((ops) => {
        ops.Conventions.Insert(0, new RouteTemplateModelConventionRazorPages());
    })
    ....

Best regards,
Ziya

from xlocalizer.

Hi Ziya,

Sorry for the delay getting back to you.

Ok that makes sense, thank you. So my understanding is that XLocalizer will only fallback to my default culture if / is the route. It doesn't work for any other route. And because of this, all URLs must start with /{culture}/ in order for the localization to work as expected when using RouteTemplateModelConventionRazorPages and/or RouteTemplateModelConventionMvc. For example /en/Dashboard will work, but /Dashboard will not (as designed).

I think in previous projects I had a route of something like {culture=en}/{controller=Home}/{action=Index}/{id?}, which was causing the behaviour I expected. I'm going to leave it out this time and see how I get on.

Thankfully, I found a nice AnchorTagHelper that, when modified slightly, automatically adds the current culture to the URL. The thought of adding asp-route-culture="@Context.Request.RouteValues["culture"]" to all of my anchor tags was depressing!

Kind regards,
Morgan

from xlocalizer.

I know that taghelper, and I've used a similar approach for a while, but for now I prefer to manually add the asp-route-culture="@CultureInfo.CurrentCulture.Name till dotnet team solves this open issue Hopefully we will see the official solution before retiring :)

Kind regards,
Ziya

from xlocalizer.

Meanwhile, if you don't use RouteSegmentCultureProvider and QueryStringRequestCultureProvider you will have urls free of {culture} param, and the localization will work with CookieRequestCultureProvider depending on culture cookie value.

The downside of this appoarch that it depends on cookies, so if the user has not allowed cookies it will not work properly, additionally you can't share localized URLs.

from xlocalizer.