Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.98%. Comparing base (28bc599) to head (6058f0e).
Report is 578 commits behind head on dev.

@@            Coverage Diff             @@
##              dev    #8581      +/-   ##
==========================================
+ Coverage   89.82%   90.98%   +1.15%     
==========================================
  Files         412      410       -2     
  Lines       11878    12546     +668     
  Branches     2364     2451      +87     
==========================================
+ Hits        10670    11415     +745     
+ Misses        681      578     -103     
- Partials      527      553      +26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

It should probably fallback so you don't need both attributes on the enum, like for example:

    /// <summary>
    /// Returns the best display name for the given type.
    /// </summary>
    /// <param name="shortName">Try to find the shorter version of the name</param>
    public static string GetDisplayName(this Type type, bool shortName = false) =>
        (shortName ? type?.GetCustomAttribute<DisplayAttribute>()?.ShortName : null) ??
            type?.GetCustomAttribute<DisplayAttribute>()?.Name ??
            type?.GetCustomAttribute<DisplayNameAttribute>()?.DisplayName ??
            type?.GetCustomAttribute<DescriptionAttribute>()?.Description ??
            type?.Name;

But Isn't there a source generator for this or something? @ScarletKuro

But Isn't there a source generator for this or something? @ScarletKuro

The source generator is only working with the DisplayNameAttribute attribute, it's not available for user code, and it won't help you if you pass an enum in the runtime which is the case here.

I do not understand why Adornment was annotated with DisplayAttribute when we talk about the Enums in DataGrid that are supplied in the model?
For unit testing the author should create own enum type and test it, and not pick any of the existing ones.
This PR also didn't fix the code quality errors.

I'm also not sure if this is fixing localization issues, what if you want multi-languages for the enum?
Theoretically it would require a method that first reads the value of the attribute, then checks via localizer that such key exist in the localization and returns a translation, if doesn't exist then fallback to the attribute value. Aka something similar what does the aspnetcore with Data Annotation attributes for the validation localization.

I will let @tjscience and maybe @mikes-gh (if he is interested) to review this instead.

Hi.

I appreciate you keep this branch up to date. But as you can see your code is failing to build:

1. EnumFormTraining.cs has a wrong encoding.
2. You modified Adornment for some reason.

@meenzen, wouldn't it be better to do something like injecting the InternalMudLocalizer into the DataGrid and then just do:

-<MudSelectItem T="Enum" Value="@((Enum)item)">@item</MudSelectItem>
+<MudSelectItem T="Enum" Value="@Localizer[item]</MudSelectItem>

It would be more universal. There is one problem that enumeration names can clash like this:

public enum Enum1
{
    Test1
}

public enum Enum2
{
    Test1
}

But maybe we could use a bit of reflection and do something like @Localizer[enumTypeName_enumMemberName], aka Enum1_Test1. This still creates a potential issue that the enums might be more or less the same but live in different namespaces and require different localization. Chances are low, though.

Is there a possibility to add support for DisplayAttribute in the localizer? What are your thoughts on that?

@henon @meenzen I reworked it completely, again.

The main improvement is that it’s now part of InternalMudLocalizer.
In the previous code in DataGrid, you had to inject both InternalMudLocalizer and IEnumLocalizer which bothered me a lot.
Now it also uses the same concept, ILocalizationEnumInterceptor, as the original localizer, in case you want to override the logic for how the enum is localized.
Earlier, the enum localizer looked like an abomination, but now it actually fits into the localization ecosystem.
A lot better tests.
And you can use it in two ways:

[Display(Name = "Enum value is localized")]
ValueWithDisplay,

[Display(Name = LanguageResource.MudDataGrid_IsEmpty)]
ValueWithDisplayLanguageResource,

The first one is a hard-coded string, second if it finds the key in the LanguageResource then it will use that instead.

Should we add some simple docs?

Should we add some simple docs?

we can do it after