Aspnetcore: Localize the default UI

[DamianEdwards]

Now that we have Identity UI in a library, we should consider having it use IViewLocalizer and IStringLocalizer to support localization of the various strings. I think it might be possible to just wrap all strings with calls to these interfaces, but not provide any resources, but rather have them picked up via the app if they're provided and configured correctly (we added features in 2.0 if I recall to enable this scenario).

[blowdart]

@DamianEdwards is this blocking, or can it move to 2.2?

[DamianEdwards]

Not blocking

[damienbod]

I created a localization of the Identity lib released in 2.1.

https://github.com/damienbod/AspNetCorePagesWebpack/tree/master/AspNetCorePagesIdentity

I was wondering if you could use this, or how you plan to support localization. When doing this I noticed a few problems, had a few questions.

Will you create 1 localization resource for the whole Identity package, or one per page ~30 pages?
which would mean ~30 resource files per language.

Will you use English as the default and localize from this, or use capital letter english texts and add english as the first resource. If english is in it's own resource, the first example can be part of the future package and if the localization is missing from the other languages, it can be found quickly. I assume english as the default is the answer, because the rest of MVC is done this way.

I had problems localizing the code in the Pages (resource was not found) and had to switch to IStringLocalizerFactory. Maybe a default service with an interface could be used for all the Pages, views and code, which can be implemented by the hosted application if required. This would make it easier to use the identity localization, something like this:

https://github.com/damienbod/AspNetCorePagesWebpack/blob/master/AspNetCorePagesIdentity/Resources/IdentityLocalizationService.cs

I removed the model display attributes, and localized this in the views. Then the view localization is only implemented in the view.

Only Cookie localization worked, the query string localization had problems with some of the Pages, for example Register.

I think the page model should be moved separate classes.

I could help with a PR, if you want.

Greetings Damien

[santiagoIT]

I have created a simple web app targeted at spanish speaking users using asp.net core 2.1. I have now come to realize that there is no straightforward way to localize the identity pages/error messages.

For my needs the out of the box identity UI is fine. However I just need the default Identity views to display in Spanish.
What is the most efficient way to accomplish this in 2.1?

Will the Identity UI views be updated for the 2,2 release, if so when will 2.2 be released?

Thanks!

[ssenapat]

I created a localization of the Identity lib released in 2.1.

https://github.com/damienbod/AspNetCorePagesWebpack/tree/master/AspNetCorePagesIdentity

I was wondering if you could use this, or how you plan to support localization. When doing this I noticed a few problems, had a few questions.

Will you create 1 localization resource for the whole Identity package, or one per page ~30 pages?
which would mean ~30 resource files per language.

Will you use English as the default and localize from this, or use capital letter english texts and add english as the first resource. If english is in it's own resource, the first example can be part of the future package and if the localization is missing from the other languages, it can be found quickly. I assume english as the default is the answer, because the rest of MVC is done this way.

I had problems localizing the code in the Pages (resource was not found) and had to switch to IStringLocalizerFactory. Maybe a default service with an interface could be used for all the Pages, views and code, which can be implemented by the hosted application if required. This would make it easier to use the identity localization, something like this:

https://github.com/damienbod/AspNetCorePagesWebpack/blob/master/AspNetCorePagesIdentity/Resources/IdentityLocalizationService.cs

I removed the model display attributes, and localized this in the views. Then the view localization is only implemented in the view.

Only Cookie localization worked, the query string localization had problems with some of the Pages, for example Register.

I think the page model should be moved separate classes.

I could help with a PR, if you want.

Greetings Damien

I am facing query string localization issue. I cannot navigate to the Identity pages using the lang or culture keyword in the URL.
example:
The below url's are working fine
testproject:4465/en
testproject:4465/en/Home/About
...

But Identity pages does not have language or culture in the url
testproject:4465/Identity/Pages/Account/Login
testproject:4465/Identity/Pages/Account/Register
...

If I try to navigate with language in the url it fails
i.e testproject:4465/en/Identity/Pages/Account/Login fails and navigates back to home page.

Is this resolved or did you find any workaround for this issue.

[hishamco]

I'm not sure what's prevent us from using IViewLocalizer in views and IStringLocalizer else where to make the resources localizable, then when the app register those services and resources are added the localized resources will show up

[hishamco]

@HaoK is my previous thought make sense or is there anything blocking?

[AlissonRS]

I'd like to know if there is a straightforward way of localizing DefaultUI. If not, is my only option scaffolding the entire identity pages and doing it manually?

Thanks!

[hishamco]

@AlissonRS https://github.com/aspnet/AspNetCore/issues/5778#issuecomment-498967509

[AlissonRS]

@hishamco I'm not sure how your comment answers my question. What you suggest is exactly what I wanted to avoid, thus my question remains: is there an easier alternative for localizing the DefaultUI?

[hishamco]

Got it.. but I am not sure if there's alternative solution

[AlissonRS]

@hishamco thanks for replying. I decided to scaffold everything.

[hishamco]

BTW my earlier suggestion to localize everything out of the box, and let the users localize the resources into their cultures, because I don't think there's an easy way to achieve this unless you are using sort of translation technique

Please have a look to my repo https://github.com/hishamco/LocalizationResourceGenerator, that may simplify the process for you, if you have the default culture resources

[Rick-Anderson]

@DamianEdwards @vijayrkn @mkArtakMSFT @ryanbrandenburg can we get this scheduled for 3.1?

[abremora]

Any news here? I'd appreciate a solution for localization by Microsoft directly. Otherwise I cannot use it for my projects.

[fjallemark]

Same here. I write web apps in Blazor that support seven different languages.

Having only American English on the account pages is a show stopper because there is no other way than clone the repo and implement the localisation yourself. Which is waste of time, because there must be several others that need this and want updates as well.

Besides implementing IViewLocaliser and IStringLocalizer, you also need to make every property in models using the DisplayAttribute point to a resource type that we can add translations to. Also all ValidationAttributes need to be localisable. Then validation errors will show both message and field name in local language.

This is how I localize models used in Blazor and AspNet:

    [Display(Name = nameof(AdministratorPassword), ResourceType = typeof(Strings))]
    [Required(ErrorMessageResourceName = "Required", ErrorMessageResourceType = typeof(Strings))]
    [StringLength(10, ErrorMessageResourceName = "InvalidString", ErrorMessageResourceType = typeof(Strings))]
    public string AdministratorPassword { get; set; } = DemoClockPassword;