Add SharedLocalizationDataProvider

[hishamco]

Sample usage:

public class MySharedLocalizationDataProvider1 : ISharedLocalizationDataProvider
{
    public Task<IEnumerable<string>> GetDescriptorsAsync()
    {
        return Task.FromResult<IEnumerable<string>>(new[]
        {
            "Admin Menu",
            "Menus",
        });
    }
}

public class MySharedLocalizationDataProvider2 : ISharedLocalizationDataProvider
{
    public Task<IEnumerable<string>> GetDescriptorsAsync()
    {
        return Task.FromResult<IEnumerable<string>>(new[]
        {
            "Contents",
            "Menus",
        });
    }
}

services.AddSharedDataLocalizationProvider<MySharedLocalizationDataProvider1>();
services.AddSharedDataLocalizationProvider<MySharedLocalizationDataProvider2>();

[hishamco]

[gvkries]

As all of the providers are singletons, the final list can be cached.

[hishamco]

You are right, after the building the services the could be cached for better PERF

[Piedone]

Why is this better than to have a separate ILocalizationDataProvider implementation and context for each feature? I think a separate context is still needed, so if the goal is making it easier to add simple strings for that, then it'd be better to have a provider that you can configure from Startups instead, like:

public static IServiceCollection AddSharedDataLocalizedString(this IServiceCollection services, DataLocalizedString dataLocalizedString)
{
    //...
    return services;
}

// Or even:
public static IServiceCollection AddSharedDataLocalizedString(this IServiceCollection services, string context, string name, string value, bool resourceNotFound = false)
{
    //...
    return services;
}

[hishamco]

FYI, if you look at the first commit, you can configure those strings from Startup, but while these are dynamic data, we can't guarantee that it's easier for devs to provide the values from there, that's why I changed the implementation to have a shared context for all to make it easier to manage from UI

[Piedone]

If it's dynamic data then one should just implement a provider.

Then again I don't see why we'd put multiple independent features' localized strings into the same context.

[hishamco]

Shared context could be good static localization IMHO, so let me propose another PR, then we could choose which is better to cover almost all the cases

[hishamco]

@Piedone, regarding your proposal in #18999 (comment), I did a similar thing at the beginning, then I realized that such a thing is easier for static resources

Assume the case of your PR #18981. How will you provide the data if there's no provider?

[Piedone]

Shared context could be good static localization IMHO, so let me propose another PR, then we could choose which is better to cover almost all the cases

Why is shared context better? The ones in the sample in this PR are independent features, why would we bundle them together?

@Piedone, regarding your proposal in #18999 (comment), I did a similar thing at the beginning, then I realized that such a thing is easier for static resources

Assume the case of your PR #18981. How will you provide the data if there's no provider?

There need to be a provider. I'm just saying that if you want to make adding DataLocalizedStrings easier for static strings, like in the sample in this PR, then I'd suggest a simplified API like I've shown.

[hishamco]

There need to be a provider. I'm just saying that if you want to make adding DataLocalizedStrings easier for static strings, like in the sample in this PR, then I'd suggest a simplified API like I've shown.

I don't think it's a better idea, coz the static strings come from PO files

So, let's stay with what we have, but we could create a localization provider that sets the context to OC.Module.XYZ instead of letting the developer do it; this might reduce the errors

Do you think it's a better idea?

[Piedone]

An automatic (default) context looks like a good idea, yes. For the existing providers too.

[hishamco]

For non-default, it could be useful, but the question that might arise is how the developer will know the context that will be used in the markup?!!

[Piedone]

Well, then back to not having a shared context, and perhaps do #18999 (comment) (but I don't think this is a high priority).