Hey,
after creating a collection type named “persons” with a respective “person” as a singular item within the collection type, I noticed that strapi in the admin displays “People”, although I have never added this name anywhere.
This behaviour is extremely unexpected and I was wondering, where it comes from. I dont want strapi to automatically change any kind of naming convention.
Thank you for the clarification!
A screenshot for clarification: In the Content type builder it its correctly named Person, in the content editor it is named People
We use the pluralize library to automatically create the plural form of a model (this is used in the admin panel and the backend). As the plural form of person is people it’s handled automatically.
There has been some discussion as to adding a means to disable this, but currently we don’t have the option.
Thank you for the clarification @DMehaffy .
This is indeed a very unexpected behaviour. I suggest adding a disclaimer of some sort when setting up a new collection type - or even giving the option of using a custom plural version.
This is specifically annoying if you’re setting up collection types in an other language than english.
Poking @Aurelsicoko / @sam-pires about this.
Thank you for the suggestion, it has come up before and I certainly agree with you.
I thought it was disabled as it has been reported many times. We could certainly easily remove the behavior. Could we find someone in the community ready to contribute and change the behavior, or do we need to handle it ourselves and add it in the next sprint? @sam-pires
Since I think it’s something we need to save into the model settings and it would require an architectural change (especially if we plan to fix it on the routes also) it may be something we need to discuss with @alexandrebodin as well and maybe implement in v4? It has to do with pluralize directly.
I don’t think it’s related to the Model settings, just remove the use of the pluralize library in the frontend. In the beginning, we thought it was a good idea to pluralize to be able to display “List of users” and at the same time having a CTA button “Add new user”, but the more I thought about it we shouldn’t automate this at all and rely on information entered by the user itself. Like asking for the singular and plural naming of a content-type for example.
But we will need a way to set a default if the user doesn’t enter one, and if we go this route too it will also change the way we generate the routes.json for say /articles. That’s why I mentioned the model settings.
(Short term UI stuff yeah it would be a little easier, but I think it’s better to handle it project wide than to slowly do this in the UI first, then modify the backend and generation)
You’re right but even pluralizing the routes isn’t a good practice. If the user names their collection “article”, the routes should be /article and /article/1 without the “s”.
Hello there,
We have been discussing this behavior as we know it’s not always wanted, and it doesn’t work well for other languages than English.
A PR had been opened by a contributor but didn’t tackle the need entirely. There is currently an RFC (Request For Comments) open to discuss the best solution (let the choice, remove it entirely, etc.)
@Ortimis that would be awesome if you could add your feedback and ideas/suggestions to the RFC.
Here it is: Request — Collection Display names pluralizing problems · Issue #18 · strapi/rfcs · GitHub
Yup exactly what we need, thanks for the link Sam.
Hey there, we have the same problem. You offer Strapi in German, but then Strapi will not work with the German names of the collections.
This is partly a reason not to use Strapi for customer projects. It would be great if we could turn this feature on and off in the settings. I like the idea behind it.
Thank you and strong work
Stay healthy and greet Aus berlin.
Torben
The pluralization is awkward, the pluralized titles are silly and quite unreadable in any other language than English… that is the first thing clients throw us on the head, always.
The API is ok from my point of view as the API has more systematic value it make sense from a programing perspective, therefore acceptable, might be even desired… In that case I do not read words, I read specification.
If you hassitate about the implementation… keep the pluralization all over but make another optional attribute we can use for the admin UI and vast majority of us will be happy.
