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?

[macco3k]

What about the approach described here? https://www.rfc-editor.org/rfc/rfc9457.html#section-3

Ardalis.Result could either define its own error type or use an existing one. This would, of course, be obvious for validation results. Perhaps not so much so for other types.

For example, a Invalid result could be mapped to the following problem details object

{
  "type": "invalid-request",
  "status": 400,
  "title": "The request is invalid",
  "detail": "One or more validation errors occured. See the `errors` property for more details",
  "errors": [
     {
       "detail": "must be a positive integer",
       "pointer": "#/age"
     },
     {
       "detail": "must be 'green', 'red' or 'blue'",
       "pointer": "#/profile/color"
     }
  ]
}

Optionally, the instance property could be populated with the request/correlation id, if any, as per https://www.rfc-editor.org/rfc/rfc9457.html#section-3.1.5.

The proposed pointer is theoretically capable or pointing to very specific parts of the request JSON, but I doubt whether we should go that far for a first implementation.

Doing the same for other error types could follow a similar pattern.

Now, of course, this would break backwards compatibility, though we may or may not care about it.