named-parameters in resource-values

[earloc]

As a translator, I want to re-use parameter-names from a ressource´s key in the translation provided, to prevent mismatches in the used order within my translations, to not accidently break a translation.

[earloc]

e.g.

key: hello, {name}
value: hello {name} (instead of hello {0})

the processed translation would be needed to interpolate / replace these named values somehow, prior passing it down to the internal string.Format()-call

[earloc]

Most significant problem to solve is, that the invocation of string.Format() is done below in the default-implemenation of IStringLocalizer-> RessourceManagerLocalizer:

    public virtual LocalizedString this[string name, params object[] arguments]
    {
        get
        {
            if (name == null)
            {
                throw new ArgumentNullException(nameof(name));
            }

            var format = GetStringSafely(name, null);
            var value = string.Format(CultureInfo.CurrentCulture, format ?? name, arguments); // <--this little fella here

            return new LocalizedString(name, value, resourceNotFound: format == null, searchedLocation: _resourceBaseName);
        }
    }

[earloc]

might be best to implement this as custom IStringLocalizerFactory (and possibly custom IStringLocalizer) implementations, which might let callers specify how to string.Format() in the first place, or let consumers decide to choose

• https://github.com/axuno/SmartFormat
• https://github.com/dotliquid/dotliquid
• https://github.com/crozone/FormatWith
• https://www.nuget.org/packages/StringTemplate4

or whatever templating solution might be suitable / performant / fancy enough

This way, this feature would not be bound to TypealizR at all, but could be as easy to achieve as by switching
services.AddLocalization() with something like services.AddSmartFormatLocalization or services.AddDotLiquidLocalization or just a generic version of services.AddLocalization( (s, args) => ...). Even in other solutions that might need such a (templating-)feature.

[earloc]

maybe TypealizR could provide a hooking-mechanism to let consumers provider their own replacement for the string.Format()-call

[earloc]

something like this:

//class generated by TypealizR as current
internal static partial class SomeExtensionClassGeneratedByTypealizR
{
	public static string Foo(this IStringLocalizer that, string bar) 
		=> that["foo"].Format(bar);
	//instead of that["foo", bar];
}

//always auto-generated
internal static partial class SomeExtensionClassNameToBeDefined
{
	public static partial string Format(this LocalizedString s, params object[] args);
}

//auto-generated, if no such type exists in the current compilation.
//TypealizR-consumers would just need to provide this partial type in order to provide custom implementations
internal static partial class SomeExtensionClassNameToBeDefined
{
	public static partial string Format(this LocalizedString s, params object[] args)
	{
		return string.Format(CultureInfo.CurrentCulture, s.Value, args);
		//or s.Value.FormatWith()
		// or Smart.Format(s.Value, args)
		// or or or
	}
}

[earloc]

Lightweight solution to let developers provide custom logic has been implemented in #42 without the need to implement a rather heavy-weight custom StringLocalizerFactory per templating-library.

Could still be an interesting concept, though. But way out-of-scope for TypealizR.