Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.

De-jargoning Drupal – working with the community to open up Drupal’s terminology

Drupal is the Content Management System behind EdWeb 2 (and also EdWeb). As a Drupal contributor I’ve been working with others in the community to help improve the clarity of the language used within Drupal, to make it more accessible and inclusive. 

If you’re familiar with Drupal, you will have learned its language. You will be familiar with words like Views, Blocks and Paragraphs and you’ll appreciate their respective features and functions. But for those new to Drupal, getting to grips with what words mean can mean a steep learning curve. 

Why I wanted to help clarify Drupal’s vocabulary

My background in Content Design means I’m interested in words and particularly how people use and interpret them in the context of tasks they want to complete. In my role heading up the User Experience Service at the University I’m always looking for ways to make our staff and student experiences of our digital products and services better, and to this end I have worked on making our language more user-centred in several contexts: 

  • Collaborating with others as part of the Editorial Working Group to manage the Editorial Style Guide (including the Inclusive Language Guide) 
  • Developing content for component pages as part of the Design System project
  • Starting an initiative to look at how we use technical language  

Read more about these pieces of work in these blog posts:

Since Drupal is an open source system and therefore can be shaped by the community for the community, working towards a better Drupal vocabulary was an exciting prospect as it meant having a hand in shaping Drupal for the future. I was struck by the parallel between Drupal and its language which will both need to shift and evolve over time, influenced by all those who contribute to it and maintain it.

Language is humanity’s most spectacular open source project  – Gretchen McCulloch, from ‘Because Internet: Understanding how language is changing’

The start of the Drupalisms issue

User research to improve the Drupal administration User Interface (UI) raised an interesting finding. When the Drupal community was asked to complete an exercise where they grouped terms from the UI into categories that made sense to them, the results showed people were unable to place some of the terms. Further investigation indicated that people weren’t sure what these outlier terms meant (and therefore they had struggled to sort them).

How we speak Drupal matters

Myself and my fellow Drupal contribuotrs wanted to address this finding from the research because we recognised the importance of people understanding Drupal terminology to enable and empower them to use Drupal confidently and competently. We strongly felt that Drupal language shouldn’t be a barrier to people new to the community learning and we wanted to take the opportunity to address this. It felt like the most logical place to start was to identify Drupal terms that caused confusion – ‘Drupalisms’. With a core team of community volunteers behind it, issue 3381734 was begun.

Issue 3381734 on

First endeavours to identify Drupalisms

With the issue live, we set to work, picking out terms that matched the ‘Drupalisms’ brief – in other words, terms which we felt were confusing to new Drupal users. Our initial list included words like: ‘Node’, ‘Blocks’, ‘Structure’, ‘Entity’, ‘Paragraphs’. As the issue queue gained momentum, more words flooded in, and people expressed opinions on aspects of Drupal terminology – for example, questioning Drupal’s use of ‘Site Builders’, ‘Developers’ and ‘Themers’ to describe the roles and functions of the Drupal community.

Drupalisms BoF at DrupalCon Lille

Attending DrupalCon Lille presented the chance to run a Drupalisms BoF with Aaron McHale to encourage people from the community to come together and collaborate on this issue. We spent the time looking at our initial list of terms, thinking of more, and thinking about how we would describe them to people new to Drupal. This exercise helped us appreciate the importance of preventing language being a blocker to new Drupal users and therefore affirm the importance of the issue.

Read more about DrupalCon Lille in my related blog post:

DrupalCon Lille 2023 – A UXer’s perspective

Establishing regular meetings to work together

Coming together after the BoF, we reflected on possible ways forward. We established that our original goal to identify Drupalisms was part of something bigger, an impetus to make sure our language opens up Drupal to everyone, to ensure we are being as accessible and inclusive as possible. We all agreed this was not something fixable quickly, and we committed to a regular pattern of fortnightly meetings to work on the issue.

Acknowledging challenges and opportunities

Our initial meetings were spent discussing the issue in more depth. We thought about the varied mental models, expectations, native languages and levels of understanding people bring to Drupal, and how their prior experiences (sometimes with other Content Management Systems) shapes their language perceptions. We considered the roles that glossaries tooltips and micro-copy can play in helping people make sense of our terminology in different contexts. We thought about the past – and how historic events had led to the language we use in Drupal today, and then ahead to the future, thinking about the impact of changing terminology and the possible consequences. We also established that language is an emotive subject, and therefore that making decisions about language should be based on evidence over opinions.

Adopting a methodical approach towards a controlled vocabulary

Ralf Koller from our group suggested an objective, multi-step approach to working on the issue inspired by various sources including Abby Covert’s book ‘How to make sense of any mess’,  Sophia Prater’s Object-Oriented-User-Experience (OOUX) methodology and the writings of other content design specialists like Erica Jorgensen. The stages we are working through are as follows:

  1. Noun foraging – making a full list of all the Drupal terms
  2. Evaluating/prioritising the most confusing terms based on responses from the community and also how easy it is to define them
  3. Deciding which terms to include in a controlled vocabulary
  4. Producing translations of these terms
  5. Developing a ‘words we don’t say’ list
  6. Establishing a process to maintain the vocabulary going forwards

Collaborating with other open-source Content Management Systems

Addressing issues of Content Management Systems (CMS) language more broadly, and acknowledging that Drupal is not alone in wanting our vocabulary to be intuitive and easy-to-understand, I’ve reached out to others in the wider open-source CMS community to think of ways we can use our collective force to develop a more consistent approach to CMS terminology. It’s early days but there is interest, and we’re looking to establish a date for an initial meeting.

Where we are now and next steps

We’re working together on the first stage of the process the noun foraging part of the process, gathering terms from many sources. Our current list stands at around 400 terms and we know there will be more. If you work with Drupal and you would like to join in helping us with this piece of work or you are interested to know more, please comment in the issue queue, join the #drupalisms-working-group on Slack or email me directly at

You can also find the ongoing meeting notes linked from the issue queue:

Issue 3381734 on

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


Report this page

To report inappropriate content on this page, please use the form below. Upon receiving your report, we will be in touch as per the Take Down Policy of the service.

Please note that personal data collected through this form is used and stored for the purposes of processing this report and communication with you.

If you are unable to report a concern about content via this form please contact the Service Owner.

Please enter an email address you wish to be contacted on. Please describe the unacceptable content in sufficient detail to allow us to locate it, and why you consider it to be unacceptable.
By submitting this report, you accept that it is accurate and that fraudulent or nuisance complaints may result in action by the University.