errorMessages should be passed as string

[buti1021]

The error messages get translated into the details property of the problem details object. By the RFC standard this property is a string.
Currently a list of errormessages can be passed to the NotFound and Error Method, which then get concatenated.
e.g.,:

Result/src/Ardalis.Result.AspNetCore/ResultStatusMap.cs

Lines 117 to 120 in 1c8a9f5

	var details = new StringBuilder("Next error(s) occured:");
	foreach (var error in result.Errors) details.Append("* ").Append(error).AppendLine();

This breaks internationalization, as the string at the start is english and already happens if only a single string is passed.
I think the best approach would be to allow only strings and make the developer responsible for concatenation.
What do you think?
@ardalis @KyleMcMaster

[ardalis]

Related to #126.

We need a better story for managing strings and internationalization.

[LouisTrinczek]

I think there shouldn't be more than one error, per ProblemDetails instance.
Is there a common approach in dotnet, to returning a list of multiple ProblemDetails?

Because then the developer could work with a list of ProblemDetails, and concatenate the errors himself, and also translate it by himself how he sees fit using only the actual error message, he defined returned from the ProblemDetails.Detail field.

I am facing the internationalization error myself right now working with this package.

[ardalis]

Is there a common approach in dotnet, to returning a list of multiple ProblemDetails?

Not that I'm aware of but I don't claim to be an expert. I could imagine something like a validation problem in which several parts of a POSTed DTO were invalid and you wanted to be able to convert a Result.Invalid with its error list into a ProblemDetails (even though probably a BadRequest makes more sense...) and at that point you'd have several (validation) errors.

Or maybe you have some parallel tasks you fire off, and some fail, and you have an AggregateException and you want to be able to include all of the failures states and their respective error messages in the ProblemDetails (I don't think you'd return more than one ProblemDetails). Probably a rare consideration but perhaps one some need to support?