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 #5778 (comment)