Interpolation Support for LocalizeEnumConverter

[livonium]

What problem would this solve?

Interpolation support for the enum Localizer could significantly reduce boilerplate in cases where the resource key itself depends on the state of the arguments being passed in (e.g. if some are set/null, whether some arguments are plural numerals or not, etc.)

For example, one may wish to support the following variations of displaying partitions, whose formats can differ per language (inline codeblocks represent interpolated arguments):

• "Drive 2, Partition 1"
• "F: Drive"
• "My USB"
• "My USB (F:)

Enums can be created on the C#-end whose values depend on the presence of some of the arguments. Currently, since LocalizeEnumConverter does not support arguments, one has to write custom generic or per-case bindings and/or converters which do accept model bindings as input, or rely on the viewmodel, which could potentially bloat it and make it harder to maintain.

Proposed solution

LocalizeEnumConverter.cs could be slightly modified to slice the rest of the values object array (sans 1 for the CurrentCulture binding) in Convert() into an argument array which can be passed to Localizer.Current.Get().

// LocalizeEnumConverter.cs
    public Object Convert(IList<Object?> values, Type targetType, Object? parameter, CultureInfo culture)
    {
        if (values.Count == 0 || values[0] is not Enum enumValue)
        {
            return String.Empty;
        }

        var key = EnumKeyConvention.BuildEnumKey(enumValue, this.KeyPrefix);

        var args = values.Skip(1).Take(values.Count - 2).ToArray();

        return this.ResourceManager is null
            ? (args is {Length: >0} ? Localizer.Current.Get(key, args) : Localizer.Current.Get(key))
            : (args is {Length: >0} ? Localizer.Current.Get(key, this.ResourceManager, args) : Localizer.Current.Get(key, this.ResourceManager));
    }

Alternatives considered

Currently, my project uses a modified version of LocalizeEnumConverter.cs (alongside a copy of the internal class EnumKeyConvention), which implements the modifications shown above. However, this approach feels like a band-aid solution to a feature currently missing in the enum Localizer, which the regular Localizer and extension already have. Furthermore, this approach requires upkeep if/when ResXLocalization updates, in order to implement new features and/or comply with any API changes.

[rent-a-developer]

Sorry for the late reply!

Thank you very much @livonium for this proposal and your interest in this project!
I will work on it as soon as I have some time.
I need to think about whether there is a more broad solution to this issue that would cover even more use cases.

[rent-a-developer]

@livonium
I looked into the broader solution that I mentioned. I would like to know your opinion about it.

Side note:
Your issue description is very good, especially the sample code of your modified converter.
There are a couple of things that would have been even more interesting/helpful:

• The shape of your view model (example code) from which the arguments come from and the concrete
  bindings / an example usage of how you use your modified converter.
• The concrete translations from your ResX file.
• You mentioned you also modified EnumKeyConvention, but you did not mention why.
  I'd like to understand that point too.

1. Arguments for the enum converter

Your request is clear, and the enum lookup should accept arguments like the other lookups.

There is one difference to your patch. I would keep the current culture as the second binding,
and start the arguments after it:

<MultiBinding Converter="{x:Static l:LocalizeEnumConverter.Default}">
  <Binding Path="PartitionKind" />
  <Binding Path="CurrentCulture" Source="{x:Static core:Localizer.Current}" />
  <Binding Path="DriveNumber" />
  <Binding Path="PartitionNumber" />
</MultiBinding>

var args = values.Count > 2 ? values.Skip(2).ToArray() : [];

There are two reasons for this order:

1. The README shows the culture as the second binding. If the culture moves to the last position,
   every MultiBinding that has more than two bindings today gets a different meaning. So a breaking
   change.
2. The arguments are then at the end, and their number is free. Skip(2) is sufficient. If the
   culture is the last binding, the arguments are in the middle, and it is necessary to count from
   both ends.

2. What your solution does, and what stays open

If I understand your patch correctly, you give all possible arguments at all times, and each message
uses the ordinals that it needs:

<MultiBinding Converter="{x:Static l:LocalizeEnumConverter.Default}">
  <Binding Path="PartitionKind" />
  <Binding Path="CurrentCulture" Source="{x:Static core:Localizer.Current}" />
  <Binding Path="DriveNumber" />
  <Binding Path="PartitionNumber" />
  <Binding Path="DriveLetter" />
  <Binding Path="VolumeLabel" />
</MultiBinding>

Key	Value
Enum_PartitionKind_DriveAndPartition	Drive {0}, Partition {1}
Enum_PartitionKind_LetteredDrive	{2}: Drive
Enum_PartitionKind_Label	{3}
Enum_PartitionKind_LabelAndLetter	{3} ({2}:)

This works, and it is much better than a converter for each case. Four points stay open:

1. The translator sees numbers, not names. {2} does not show that this is a drive letter. A
   translator can put the wrong argument in the wrong position, and nobody sees the mistake before
   run time.
2. String.Format has no plural form. For "1 partition" and "2 partitions" you must add more
   enum members, one for each combination of case and number. The number of members then grows
   quickly. This is the second point in your issue.
3. The set of cases is fixed in C#. If one language needs an additional case, or fewer cases, the
   translator cannot do this. It is necessary to change the enum and the code.
4. There is one resource entry for each case, and every language must keep all of them complete.

3. Proposal for a broader solution: add support for the ICU message format

The ICU message format is a standard for messages that change with their data. It has a select
form for cases, and a plural form for numbers. Translation tools like Crowdin, Lokalise and Phrase
support it, and it is the usual format for this problem outside of .NET. I didn't know about ICU message format
before researching a solution for your issue (so thank you again for bringing the issue up!).
This page gives a good overview: https://crowdin.com/blog/icu-guide.

With this format, one resource entry can replace your four keys:

Key	Value
PartitionDisplay	see below

{Kind, select,
  DriveAndPartition {Drive {Drive}, Partition {Partition}}
  LetteredDrive     {{Letter}: Drive}
  Label             {{Label}}
  LabelAndLetter    {{Label} ({Letter}:)}
  other             {{Label}}}

The arguments have names, and you give them as an object:

Localizer.Current.Get(AppStringsKeys.PartitionDisplay, new
{
    Kind      = PartitionKind.LabelAndLetter,
    Label     = "My USB",
    Letter    = "F",
    Drive     = 2,
    Partition = 1,
});
// Result: "My USB (F:)"

In XAML, your view model gives one object with these values (the name of the attached property is not
decided yet):

<TextBlock Text="{l:Localize {x:Static res:AppStringsKeys.PartitionDisplay}}"
           l:LocalizeArgs.Values="{Binding Partition}" />

Your enum stays. It is no longer a part of the key. It becomes the value of the Kind argument,
because Enum.ToString() gives the name of the branch. The MultiBinding and the converter are then
also no longer necessary, because the enum is one of the values in the argument object.

What this changes for the four points above:

1. The translator sees {Letter} and {Drive}, and not {2} and {0}.

2. plural is possible inside a branch, and no additional enum members are necessary:

   DriveAndPartition {Drive {Drive} with {Partition, plural, one {# partition} other {# partitions}}}
   

3. The translator can add a branch or remove a branch for one language. The set of cases is in the
   message, and not in the code.

4. There is one resource entry for all cases.

Questions

1. Is the ICU message format interesting for you, or do you prefer the smaller solution from part 1?
2. Does the ICU message format solution fit your use case? Is there a case that it cannot support?
3. In your application, do the arguments come from one view model property, or from many separate
   properties? Your answer helps me with the design of the XAML part.

[livonium]

Hi! Thanks for sharing this – the solution I proposed was mostly a band-aid solution for getting situations like an enum converter working as soon as possible, but the ICU format seems to be really interesting. I currently don't see much of an issue with implementing it, and I think it would be really nice to implement!

In my app, at the moment, the arguments come from a single viewmodel property (the Partition record), by the way.