Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request — Collection Display names pluralizing problems #18

Open
sebqq opened this issue Aug 20, 2020 · 5 comments
Open

Request — Collection Display names pluralizing problems #18

sebqq opened this issue Aug 20, 2020 · 5 comments

Comments

@sebqq
Copy link

sebqq commented Aug 20, 2020

  • Start Date: 2020-08-20
  • RFC PR:

Summary

Current way of Collection name's pluralizing does not work in other languages as different languages has different rules in order to pluralize words.

Example

For example, when I try to use word "Produkt" (in slovak it means product), the content-type-builder makes "Produkts" from it in order to pluralize it, which is wrong, because right form of this word in slovak language is "Produkty".

I will cite another example from #7505 from @bernhardw:

The problem is, the "Display name" as shown in your screenshot is pluralized based on English rules.

In German for example the plural of events is "Veranstaltungen" and Strapi automatically adds an "s" to the end => "Veranstaltungens" - which is not correct.

Motivation

These inconsistencies could be critical (for us, that are not working for English-speaking clients) in order to present our work to our clients, that expects precision and professionalism from our solution.

Detailed design

Most simplified solution would be to let admins decide, whether content-type-builder should use pluralize package (default option) or admin will provide pluralized form of targetted word.

Pluralized form could be potentially added from Main tab area (maybe below display name) or from "Advanced Settings" Tab during collection creation.

I don't know strapi's internals good enough yet, but maybe we can store both forms (singular and plural) inside of json model and use appropriate form when needed.

Tradeoffs

  • Some code is definitelly needed.
  • Users will have one more more thing to do in order to pluralize word by themself.
  • English users & english based projects will most certainly not need to use this feature.

Alternatives

I'm not able to thing of any alternative right now. Maybe, I will add something later

Unresolved questions

I don't see any right now, but I might add them later

@sebqq
Copy link
Author

sebqq commented Aug 31, 2020

The solution could be as simple as giving us an optional env var or argument or flag, which decides, whether we (admins) would like to display to our dashboard users pluralized collection types inside of UI or not.

I believe that this behaviour would not be breaking change and it is simple enough to implement.

@sebqq
Copy link
Author

sebqq commented Aug 31, 2020

Another solution could be a checkbox next to Display name that says "Dont pluralize in dashboard".

@sebqq
Copy link
Author

sebqq commented Sep 2, 2020

So basically, after some testing of that already closed PR of mine I've found out it is not gonna be that easy. Including some points about potential solution, that might be usefull:

The effects of setting 'display name' are currently divided by:

  • Display name set during collection creation:
    1. is responsible for file naming inside of api/ folder.
    2. Represents collection in dashboard (as label).
    3. When a new db relation is created, this display name is used to create relation's column name.
  • Display name changed after collection was created:
    1. api/ files of that collection are not overriden, which is IMHO good, because when developer needs to set Display name (localized) for dashboard, in most scenarios, he still would like to work with english-named endpoints, etc.
    2. Rest are same as in the first case.

As strapi still needs both, a plural and singular form od collection name, I've written some notes about possible solution:

  1. Let Display name represents only labels across the dahsboard.
  2. MakeCollection name to be automatically generated from display name by default, BUT make it writeable to allow changes (this is current behaviour).
  3. Add a new Checkbox with "Pluralize manually" label, that allows developers to decide, whether they would like to provide pluralized form, or it can be automatically generated (by pluralize package, as it is now).
  4. There also should be a new input field, which represents pluralized collection name - This field should be readonly by default and should change to writeable, when user checks mentioned checkbox.
  • Then I highly suggest to generate files inside of api/ folder using Collection name and Pluraziled Collection name meta fields.
  • These meta data could be memorized inside of [collectionName].settings.json, so we can access them in strapi's code without need to use pluralize plugin.
  • All created relations, should be named after Colleciton name (not Display name)

Does it make any sense? I'm still not totally familiar with Strapi's codebase so there probably will be some cases that I did not cover.

cc @alexandrebodin

@derrickmehaffy
Copy link
Member

Linking the forum thread that had some more information: https://forum.strapi.io/t/weird-behaviour-of-display-name-of-a-collection-type-in-admin

To summarize my thoughts:

  • The model settings file somename.settings.json should have an option to define the singular version, and plural version.
  • If a user doesn't define a plural value, one will be created automatically
  • Routes for REST should use the singular for finding 'one' and the plural for finding all (though we could go either way honestly)
  • GraphQL will need both a singular and a plural unless we come up with some alternative naming for the resolvers

Personally I -still- feel our display stuff for the model itself (not the fields) needs to be based off the model settings.

@Ortimis
Copy link

Ortimis commented Dec 13, 2020

I completely agree with @derrickmehaffy .
In this case, pretty much anything is better than the current silently automated process. A small disclaimer would do as a fast, cheap and easy solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants