Ability to customize and/or opt-out of pluralization

[bjornharrtell]

It seems pluralization is applied unconditionally in FormatResourceName and it cannot be controlled because it's not a concern of JsonNamingPolicy.

I see pluralization is done with Humanizer but trying to customize it seems ineffective, i.e:

CultureInfo.CurrentCulture = new CultureInfo("da-DK");
CultureInfo.DefaultThreadCurrentCulture = CultureInfo.CurrentCulture;

But I would rather just like to be able to disable pluralization.

Would it make sense to introduce an option for this at JsonApiOptions level fx. PluralizeTypeNames with default true?

[bkoelman]

To use an alternate culture for pluralization, you need to add the full Humanizr package to your project (see here), which includes satellite assemblies for all the cultures.

Pluralization happens because the JSON:API spec uses that in all examples, although it's not mandated according to https://jsonapi.org/format/#document-resource-object-identification:

Note: This spec is agnostic about inflection rules, so the value of type can be either plural or singular. However, the same value should be used consistently throughout an implementation.

I think EF Core does something silimar to determine database table names. Pluralization is unrelated to the casing convention, which can be set in serializer options. The naming of resources can be customized on a case-by-case basis as described here.

The controllers source generator also applies pluralization. But because it runs at compile time, it can't read options that are set at startup.

Why would you want to disable pluralization?

[bjornharrtell]

In my opinion pluralization, in this context, is of little benefit (if any?) especially in relation to the cognitive and technical complexity that it adds and I also think is a risk of mistakes or misunderstandings if maintained manually.

Differences in pluralization implementations at server and client side can cause problems.

And finally, some type names aren't necessarily real things/names and as such doesn't go well with pluralization at all. It's a bikeshedding cause to have decide when a name is reasonable to pluralize or not and IMHO it should be a presentation issue not a protocol issue.

[bjornharrtell]

I realize now that I'm not sure about my own argumentation, because as for the controller url path segments I do feel plural is the natural name.

[bjornharrtell]

I think I have to concede my logic was flawed and will drop the opt out idea. However I am as of yet unable to make use of humanizer locales. Adding the full package or specific language doesn't seem to affect anything with the CultureInfo attempt above.

[bkoelman]

Oh well, this explains it: Humanizr/Humanizer#1002 (comment). Pluralization for non-English is not implemented in Humanizr.

The following works, though:

using Humanizer.Inflections;

Vocabularies.Default.AddPlural("Huis", "Huizen"); // Dutch form of house/houses

And at the same time, this enables a global opt-out of pluralization, ie:

Vocabularies.Default.AddPlural("Huis", "Huis");

[bjornharrtell]

Thanks @bkoelman and with that I think this is ready to be closed. 🙂