RouterTabs: Adds localization

[tesar-tech]

Description

Closes #5945

The feature is complete, but the documentation still needs to be updated. I’d like to discuss the approach first.

Implementation Overview

1. Adding Options to AddBlazoriseRouterTabs
   The implementation introduces an option to AddBlazoriseRouterTabs that accepts a Func NamesLocalizer:

   builder.Services
       .AddBlazorise()
       .AddBlazoriseRouterTabs(
           opt => opt.NamesLocalizer = nameLocalizationKey =>
               applicationLocalizerDictionary[nameLocalizationKey]
       );

   This approach works similarly to how global localization is applied to validation messages.

2. Using a Key Instead of a Name in the Attribute
   A key can now be provided inside the attribute, enabling localized naming:

   @attribute [RouterTabsPage(NameLocalizationKey: "myKeyForThisPage", Closeable: true)]

[stsrki]

The global API seems good to me. But I would also like to have a localizer API on RouterTabs. Look at DataGrid for example:

[Parameter] public DataGridLocalizers Localizers { get; set; }

---

Also, for undefined NameLocalizationKey I would pass Name as a key.

[tesar-tech]

The global API seems good to me. But I would also like to have a localizer API on RouterTabs. Look at DataGrid for example:

[Parameter] public DataGridLocalizers Localizers { get; set; }

From what I understood about the DataGridLocalizer, these are used for translating build-in parts of the DataGrid, like text on "new" button, "cancel" button, etc. There is nothing like that on RouterTabs, all the text is custom - there is no default value from Blazorise...

Also, for undefined NameLocalizationKey I would pass Name as a key.

What would be the use-case here?

The current solution is designed to support either the Name parameter or the NameLocalizationKey parameter, which are handled through two different constructors.

• If the Name parameter is specified, the NameLocalizationKey will remain undefined, and Name will be used as is.
• If users want localization, they need to specify the NameLocalizationKey and leave the Name parameter empty.

[stsrki]

The global API seems good to me. But I would also like to have a localizer API on RouterTabs. Look at DataGrid for example:
[Parameter] public DataGridLocalizers Localizers { get; set; }

From what I understood about the DataGridLocalizer, these are used for translating build-in parts of the DataGrid, like text on "new" button, "cancel" button, etc. There is nothing like that on RouterTabs, all the text is custom - there is no default value from Blazorise...

Also, for undefined NameLocalizationKey I would pass Name as a key.

What would be the use-case here?

The current solution is designed to support either the Name parameter or the NameLocalizationKey parameter, which are handled through two different constructors.

• If the Name parameter is specified, the NameLocalizationKey will remain undefined, and Name will be used as is.
• If users want localization, they need to specify the NameLocalizationKey and leave the Name parameter empty.

For other components, we use the Name as a key for localization. And if localization doesn't exist or is not found than that Name is displayed in the UI. We never used a specialized LocalizationKey in any other component. That's why I would like to go the same route for RouterTabs.