Rename entity "bundle" to "subtype" in the UI text and help

Created on 22 December 2011, about 13 years ago
Updated 26 September 2023, over 1 year ago

Problem/Motivation

The term bundle is confusing to users and no longer is descriptive of the way bundles are used. A "bundle"
is a subtype of an entity type, which could be "node", "taxonomy" or "comment". For example, a "node bundle"
would be the equivalent of a Drupal 6 "content type".

Considerations:
A concept called "bundles" is going to be brought in from Symfony, so the Drupal term should be changed.
Effect of renaming Entity Type and Bundle on documentation
- Since a bundle could be a node type, if we rename bundle -> entity type, do we need to rename node type?
Attempting to convey the meaning of Entity subtype without using the word subtype

Proposed resolution

We need to have terms that cover:
a) Entity type (such as Node, Taxonomy, Custom block, Comment, etc.)
b) Bundle (such as content type, taxonomy vocabulary, comment type, block type, etc.)
c) Entity item (individual node, taxonomy term, etc.)

Proposed terms for entity type: Entity type, entity class, entity base type
Proposed terms for bundle: Bundle, entity type, entity sub-type, variant, variety, entity schema
Proposed terms for entity item: Entity item, Entity

Proposed combinations of these terms into a set of terminology:

A:

Entity type -> Entity class
Bundle      -> Entity type
Entity      -> Entity

B:

Entity type -> Entity type
Bundle      -> Entity variant/variety
Entity      -> Entity

C: [We decided on this option]

Entity type -> Entity type
Bundle      -> Entity subtype
Entity      -> Entity

D:

Entity type -> Entity type
Bundle      -> Entity subtype
Entity      -> Entity item

E:

Entity type -> Entity class
Bundle -> Entity family
Entity -> Entity

Notes:
1. Option D is what is currently used in the User Guide and Help Topics, but it may not be the best choice.
2. Within one entity type, we would still use the specific name. E.g., when talking about taxonomy terms, we would use the word "Vocabulary" to refer to a bundle, not the generic "Entity variant" or whatever we choose. This terminology is for the generic text to describe entities in general.
3. MIME types, which are also 2 level, use the terms "type" and "subtype": http://en.wikipedia.org/wiki/Internet_media_type, http://www.iana.org/assignments/media-types/index.html

Remaining tasks

a) [done] Decide on which alternative makes the most sense, hopefully based on usability testing.

==> At ๐Ÿ“Œ Drupal Usability Meeting 2020-08-18 Fixed we decided on option (C):

Entity type -> Entity type
Bundle      -> Entity subtype
Entity      -> Entity

a.2: Decide on whether we should update strings like "Add @bundle" to "Add @subtype". A few points:

  1. There are only 18 strings that have either @bundle or %bundle in them, that don't also have the word "bundle" that would appear in the UI that would need to be updated anyway (based on searching on localize.drupal.org). So, it's not a huge translation burden.
  2. It seems to me that going forward, anything that confuses users in the UI would also potentially confuse translators in a placeholder name. We don't name the placeholders "foo" "bar" and "baz" -- we name them something supposedly understandable.
  3. Not all translators are programmers. So, we should strive to not confuse them with things that don't appear in the UI.

That has not yet been decided. The current patch does include these changes.

b) Change the Drupal Core UI text to use this terminology.
==> Proposed patch on #223.

c) Change the help topics to use this terminology on ๐Ÿ“Œ Fix up minor copy problems in help topics Fixed
==> Help topics are already using this terminology of "entity type" and "entity subtype"; will want to make sure we are using the term "entity" rather than "entity item".

d) Change the User Guide to use this terminology on #3165909: Make sure entity terminology is consistent in User Guide โ†’ .

e) Update Entity API documentation to mention the UI terminology, without changing the field/entity code. Things to update:
- https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
- Some doc blocks in the Content Entity base interfaces and classes probably?
- Some doc blocks in the Field and Field UI API probably?

==> These updates are also in the current patch, unless we need more?

f) [done] Update the UI text standards page with this change
https://www.drupal.org/docs/develop/user-interface-standards/interface-text โ†’
Compare revisions: https://www.drupal.org/node/604342/revisions/view/11472253/12184451 โ†’

User interface changes

Entities will have standardized and better terminology in the UI and in help.

API changes

Probably none.

Original report by webchick

I'd really love to see the word "bundles" done away with. I've yet to meet a human being who can explain this in fewer than 300 words and with a lot of head scratching and glazed-over eyes on behalf of the listener. Witness users trying to figure this out at: http://drupal.org/node/1040330

๐Ÿ“Œ Task
Status

Postponed: needs info

Version

11.0 ๐Ÿ”ฅ

Component
Entityย  โ†’

Last updated 1 day ago

  • Maintained by
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom @catch
  • ๐Ÿ‡จ๐Ÿ‡ญSwitzerland @berdir
  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany @hchonov
Created by

๐Ÿ‡จ๐Ÿ‡ฆCanada webchick Vancouver ๐Ÿ‡จ๐Ÿ‡ฆ

Live updates comments and jobs are added and updated live.
  • DrupalWTF

    Worse Than Failure. Approximates the unpleasant remark made by Drupal developers when they first encounter a particular (mis)feature.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

  • Needs product manager review

    It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

  • Needs change record

    A change record needs to be drafted before an issue is committed. Note: Change records used to be called change notifications.

  • Needs subsystem maintainer review

    It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see the governance policy draft for more information). Also, if you use this tag, make sure the issue component is set to the correct subsystem. If an issue significantly impacts more than one subsystem, use needs framework manager review instead.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

  • Field UX

    Usability improvements related to the Field UI

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • The Needs Review Queue Bot โ†’ tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide โ†’ to find step-by-step guides for working with issues.

  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland
  • Status changed to Postponed: needs info over 1 year ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bnjmnm Ann Arbor, MI

    I think this was a really good suggestion in 2011 when Drupal was less mature. This kind of improvement could happen on a major release and it would be a natural part of the upgrade adjustment process.

    Given that Drupal has switched to Semver and there's been 12 additional years of "bundles" since this issue was filed, I think this needs to be postponed to and do a >= 2023 feasibility + pros/cons assessment before any additional efforts take place. I suspect there would be no shortage of justification as to why such a change would be nice to have, but there are other things to consider :

    • there are ~250 core methods that have "bundle" in their name - is it worth either introducing dissonance between the function names and human-label-names (or would it be worth renaming all of those which would require deprecation paths?)
    • Does anyone have the stamina to review modifications the ~10000 other uses of "bundle" in core?
    • How much documentation and contrib use will now be inaccurate due to the change?
    • It is worth the disconnect as existing sites will have "bundle" DB columns for every field ?

    Any issue that's been open for this long should probably get a can-we/should-we assessment every 5 years or so.

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin

    One aspect here is that we actually try to avoid bundle or subtype whenever possible. Just like the word "entity". Whenever possible, we want to talk about the specific case of subtypes/bundles. Node types, vocabularies, content block types, ... Only in very generic cases we use the word bundle in the UI. And many of the ones that still are using bundle are actually bugs and the code should be improved to display a better label.

    I would like to make a suggestion that might be more linguistically appropriate and ultimately understood. Also in the rest of the world. What about:

    Entity type variant (instead of bundle)

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin

    Which of course does not want to undermine the well lay out and very reasonable thoughts @bnjmnm added to such a big change (I didn't know that this term is spread so much already) and which I fully agree with. It came just from a newer discussion where it popped up again that bundle seem to be chosen very unfortunate.

  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom catch

    On top of #247 I can't think of any places where we use 'bundle' in the UI. Generally when you're dealing with 'bundles', you're dealing with something on the entity type itself, so node 'types', taxonomy 'vocabularies' and in those contexts there's no need to say 'bundle'. If there are places we use it in core interfaces or help text, a separate ticket to remove/replace those usages would be good.

    That would then make this a DX issue only, not a UX/product one.

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin

    Yeah, as I sad in #250 in other words: To change something spread like this and which is so opinionated somewhere else than in UI could become a true worm whole. As long as it is on a level where you know what you do like dealing with custom entities etc there is no need to know about that term before. Like your examples has shown very well @catch.

    For reference - The docs solved it in this way. https://www.drupal.org/docs/drupal-apis/entity-api/bundles โ†’

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin

    One problem in the whole discussion seems to be (and turned out on Slack again) that one concern seem to be: unless you know Drupal, you canโ€™t hope to know which one comes first. I think this is why sub-type (like in the link above) has been introduced in descriptions and help texts.

    Problem is that we mix sometimes the way we use it in short and on which level. Even in the discussion on Slack while thinking about it. It is not like Entity type & Entity variant. Then I would agree regarding a level issue. It is Entity type and Entity type variant what I have suggested. Or in short: An Entity and its variants. Same in Page manager. A variant of a page. It is not Page type and Page variant. It is Page and Page variant in short. Or Page type and Page type variant in long. Type is just an additional word to Page saying that there other types too. But Page would be actually enough. Same with Entity.

    That's why it is actually wrong to say Node bundle type. My fault in the other thread. ;-) It rather should be Entity type bundle or Node bundle since Node already refers to (replaces) Entity type.

  • ๐Ÿ‡ซ๐Ÿ‡ทFrance dqd London | N.Y.C | Paris | Hamburg | Berlin

    Again, sorry for the noise and coming from the bottom up with my thoughts in 249/253, which 70% cover what has been already discussed. But it has some useful additions in it worth reading and I would like to explicitly go with the well layout thoughts in #247 and #251 forward and would REALLY like to see any final tendency here. Could we try to finally give this issue a direction and a go? 1.) If we keep on scratching the surface and create 2 terms for the same thing or 2.) if we change it drastically under the hood.

    And I can't repeat enough how much I agree with the list of worries pointed in #247. But again, I am not sure if the massive work described in there not also would go for the confusion and issues created by having 2 terms for the same thing? From a developers perspective it would surely be the previous work mentioned. But from people's perspective who help on the docs and for users and contributors who try to understand Drupal and humble over things like ::bundle(type) or ->getBundleInfo() and need explicit code comments declaring that this refers to what we call sub-type in UI, can become a massive work too - to get all this "bridged", commented and explained.

    But as I sad before in previous comments: On the other hand we have Entity type Node and call it "Content type" and over the years it became a known Drupalizm, which has not caused that much confusion as maybe someone would expect. So my worries are maybe a little bit "over-do".

    Another option would be to leave bundle as it is :-) like Node. And revert all docs to bundle? NO. That would be also massive work. There a surely good reasons for why this issue kept being open for so long... But I think we should make a shot one day. In one or the other direction.

    Maybe we should go with #251 and break the back'nforth loop here. And there is a way how it can be "mixed" (to prevent all the massive work options discussed): What we do in our offices in all our docs and help texts is that we started to use both over the time and so it was not a big issue of work in one shot but a sliding change with bridging info to both terms. The way we do it is to put always the one in Parentheses which is not in focus. So on code level we say node (Content type) and on UI we say Content type (node). This way Drupalizms get repeatably remembered. So it could be Entity sub-type (bundle) in docs and bundle (entity sub-type) in code. And this could be a soft introducing change and not a time limited task since such changes are no release blockers.

Production build 0.71.5 2024