Components Localization

[hishamco]

• Localize Label Component Support label localization #796
• Localize Alert Component
• Localize Action Dialog Component Localize ActionDialog #841
• Localize Action Link Component Action link localization #828 Fix issue with ActionLink localization #839
• Localize Section Component Localize section component #849
• Localize Tab Panel Component Localize TabPanel component #848
• Localize Audit Info Component

@sbwalker feel free to update the list to support more localization components

[hishamco]

I think I will start to create a LocalizableComponent to abstract the localization stuff into this component instead of do it every time in the supported components

[sbwalker]

• Section
• TabPanel
• AuditInfo

[hishamco]

@sbwalker some component it's not easy to localize using ResourceKey pattern, for example: ActionDialog, AuditInfo, coz the messages may have arguments passed in, the way that works with localization is you should provide those arguments to the localizer

I have an idea perhaps it's crazy little bit ;) it to introduce ResourceParams, so in this way the localizer will not complain anymore and everything should work as expected, I will try to demo it in the ActionDialog component if this looks good to you, otherwise we should have a way to make this happen

[sbwalker]

Perhaps I am confused, but I was envisioning the same pattern as what was used for the Label control. The Label control has a couple of parameters for ChildContent and HelpText. The developer provides a ResourceKey which by convention is used in conjunction with the parameter name to create a unique key for locating resources. For example if ResourceKey = "Address" then the key in the RESX file would be Address.Text to get the ChildContent and Address.HelpText to get the help text. This is the way it worked in DNN and it was a very simple approach. For a control like ActionDialog where there are multiple parameters that need to be localized, it would work the same way. If the ResourceKey was "Delete" then Delete.Text would be a key in the REX, as would Delete.Header, Delete.Message., etc.. ( any property that needs to be localized ).

[hishamco]

The Label control has a couple of parameters for ChildContent and HelpText

I didn't mean the properties, to give more context let us say I have an ActionDialog with Message= "Delete the tenant" + tenant + "?", so the localizer need the value of the variable 'tenant`

Resx will contains Delete the tenant {0}? so the missing piece is the localized key param

[sbwalker]

Ok, now I understand what you are referring to. Thank you for the explanation.

[hishamco]

Seems ResourceParams will fix the issue, but again there's a limitation, what if two properties have a params?

[sbwalker]

The other option is to keep this solution simple for now and ignore the dynamic string tokenization aspects. This would mean that the default (English) Message would be "Delete the 'master' tenant?" but the other localizations would just use static text and would be a translation for "Delete the tenant?"

[hishamco]

OK, so now change required in LocalizableComponent

[hishamco]

Regarding AuditInfo or ModuleMessage why we need to provide a ResourceKey nothing special here, in case of alter the messages are dynamic, so we could localize them where they supplied, of course I can localize the message inside the component, but there's no use for ResourceKey, same thing for AuditInfo. Correct me if I'm wrong

[sbwalker]

Yes, you are correct - I was not thinking about those controls in the right way for localization.

[hishamco]

I will go though the available components and give you my suggestions, last but not least what's is there's anything else shall we include or this is enough, coz I need to write some unit and functional test before the release

[hishamco]

@sbwalker is there anything we should add here for V2 or shall we move to do some testing?

[sbwalker]

At this point all of the supporting infrastructure for localization is complete, and you have proven that it works for the core framework as well as external modules ( both on Blazor Server and WebAssembly ). The remaining tasks are to implement it throughout the framework. At a minimum, all of the razor components in the Client project which display user interface elements ( ie. /Modules subfolders ) need to be localized. In most cases this simply involves adding the ResourceKey attribute to labels, actionlink, actiondialog, section, tabpanel controls. I feel like the framework could benefit from a simple Button component as well which inherits from LocalizableComponent and allows for the specification of a ResourceKey attribute. This would reduce the need to use IStringLocalizer directly in markup and would make development more consistent with the other controls. Obviously there are still messages which would need to be localized using IStringLocalizer - but that would generally occur in the @code block. Once these changes are made it would be possible for someone to create a completely localized user interface for Oqtane. If we were going to tackle these changes it would be best to do them in batches - ie. submit a separate PR for each logical module so that the changes can be more easily reviewed, merged, tested. What are your thoughts?

[sbwalker]

One other question... based on the bug I fixed yesterday related to WebAssembly on .NET5, I am not sure how you would have been able to test the localization capabilities for external modules on .NET 5 running on WebAssembly?

[hishamco]

What are your thoughts?

Submitting a small PRs is good at this stage to avoid unexpected results, but still there's a need to use IStringLocalizer in some places, I will try to create a task list to work with

I am not sure how you would have been able to test the localization capabilities for external modules on .NET 5 running on WebAssembly?

I tested an Oqtane.Blogs before we moved to .NET RC, everthing works great, that's why I pushed a PR on Oqtane.Blogs repo, so everyone can try the localization. One last thing before I forget is Module Creator, I think I tried to avoid touching it, but as I remember these is a strange naming in Oqtane.Blogs module, that's why I asked to make the change in the module creator, so any new module could be localized without any issues. Naming is a problematics in localization ;)

We could add a functional tests to test localization functionality, also we could write a blog post or video cast to show how the localization works on Oqtane, let me know your thoughts about this one

[sbwalker]

I don't mind that developers have to use IStringLocalizer in some cases - that is the standard way of doing localization so it is expected. We have tried to make a lot of the common cases simpler by providing localized components - which should make it easier.

So should we go through the code and implement ResourceKey= and IStringLocalizer in all of the admin modules for 2.0?

In regards to Module Creator, there are some changes required for .NET5 which I was planning on making today. Once those changes are done then we may want to consider implementing localization so it is easy for developers to scaffold fully localizable modules.

Blog posts and videos are also essential for teaching people how to use the features. If you are able to create them, it would be much appreciated.

[hishamco]

This will be a part of 2.1.0

[sbwalker]

What willl be part of 2.1? I mentioned Localization Support as a feature for 2.0 in my presentation that I had to submit for .NET Conf this week. Are you saying localization does not work at all? Or it works on Server but not WebAssembly? Or just LocalizedComponent doesn’t work. Any additional information would help others jump in to get this resolved. Do we need to reach out to pranav?

[hishamco]

What willl be part of 2.1?

I suggest to complete the localization for everything in the admin panel into 2.1.0 if you planned to push 2.0.0 today at my time

Are you saying localization does not work at all?

No, everything work fine, I just figure out I have a naming issue with my resources

Or it works on Server but not WebAssembly?

It works for both, you can verify from the PR that I created

[sbwalker]

Ok, thank you for clarifying. I agree that we should wait until 2.1 for the Admin UI.

[hishamco]

No worry about my earlier comment into the old PR, it was my fault with resource naming ;) BTW if you need to me to help you what is supported and what the limitations I can do that, or email me with localization part that you wanna mention and I can help if you don't mind