Display name for attributes
Joeri Bakker
Currently attribute names are also used as the object keys for a component's data. Because of this they cannot contain spaces and capitalization is ignored. Yet by default these names are also displayed to the end user of the CMS. These constraints can make it difficult to communicate the meaning of an attribute to the end user.
Some attribute examples:
*
mobileImage
, which is displayed in the interface as MobileImage
. I would like to display as Image for mobile devices
instead.*
seo
, displayed as Seo
, which I would like to display as Search engine optimization
instead.*
storeLinkListHeader
which I would like to display as Header of store links list
.It looks like I can adjust these names using "Configure this view", but that is seemingly persisted in the database rather than in configuration (like display names of components), which means that naming is not persisted between instances.
theMatrix.dev
I need "display name" for non-English endusers.
v
vitali
any updates on this without using any plugin??
Nick Padovani
I dug into this a little bit (and apologies as I'm very much a beginner with Strapi). It seems like for each field there's a
fieldSchema
which is defined in the JSON for a given collectionType
, and metadatas
where as best I can tell it comes from the DB (description is another one that may be a candidate to have the ability to add to the schema as well). By doing a ternary on the Inputs
component, we can get the desired result, however in my basic example there are some limitations -- just off the top of my head:* This would take displayName in the schema over label in the DB (but this is kind of the intention anyway) every time.
* Does not account for translation (but it doesn't look like it's doing that for the labels currently as far as I can tell anyway).
* Seems some things like components and dynamic zones seem to be handled a bit differently in some of these conditional statements so there's likely a bit more to it than I'm posting here.
All that to say -- I hope this helps spark some discussion on this topic. As silly as it sounds, this has become quite a sticking point with editorial users as we evaluate Strapi as a replacement for our current CMS in our organization as one of the primary reasons for evaluating a change is user friendliness (or "creature comforts") if you will and this has been repeatedly called out by test users.
We'd also much prefer a config / code centric view of this as Joeri mentioned, persisting it in the database is a non-starter since we'd have to find a way to sync that between environments (which we do not migrate DBs as that's seen as somewhat of an anti-pattern in our view).
Adding the attribute option to
/packages/core/content-type-builder/admin/src/components/FormModal/attributes/attributeOptions.js
and allowing that option in /packages/core/content-type-builder/admin/src/components/FormModal/attributes/advancedForm.js
for each type also displays it in the content type builder and allows its use in the UI. Glad to put a PR in for this if there's a core contributor that can validate I'm on the right track here and not going way off into left field.
T
Thibault Cuisy
I would also love if we can have the key and the localised label linked to the languages enabled in the config.
I would like to give access to French user without displaying any English label.