English for Strapi CMS

Strapi conversations mix editorial vocabulary (content, drafts, publishing) with developer vocabulary (content types, populate, permissions), and a discussion that doesn’t clearly separate the two often ends up with a content editor and a developer talking past each other about what looks like the same problem.

Key Vocabulary

Content type — a schema defining a kind of content (like “Article” or “Product”) along with its fields, created in Strapi’s admin panel and used to generate both the admin UI and the API. “We added a new Author content type with a relation back to Article, so each article can be linked to a specific author’s bio and profile photo.”

Collection type vs. single type — a collection type holds many entries of the same kind (like many blog posts); a single type holds exactly one entry (like a homepage or global site settings). “Homepage settings are a single type since there’s only ever one homepage, but Article is a collection type because we have hundreds of individual posts.”

Populate — a query parameter on Strapi’s REST or GraphQL API that tells it which related fields (relations, media, components) to include in the response, since related data isn’t returned by default. “The API response was missing the article’s cover image and author because we forgot to add populate for those relations — Strapi doesn’t include related data unless you explicitly ask for it.”

Draft and publish — a workflow setting on a content type that lets editors save unpublished changes separately from the live, published version, so a draft can be edited without affecting what’s currently shown to users. “The typo is already fixed in the draft, but it hasn’t gone live yet because draft-and-publish is enabled on this content type and no one has clicked ‘Publish’ since the edit.”

Role and permission — Strapi’s system for controlling which API endpoints and content-type actions (find, create, update, delete) each user role (like Authenticated or a custom “Editor” role) is allowed to perform. “The API call was returning a 403 not because of a bug, but because the Public role’s permission for that content type’s find action had never been enabled.”

Common Phrases

• “Is this data missing because it’s a relation that wasn’t populated, or does it actually not exist on this entry?”
• “Is this a collection type or a single type — how many entries should this content actually have?”
• “Is the edit visible because it’s published, or is this content still sitting in draft?”
• “Is this a permissions issue on the role, or is the content type itself misconfigured?”
• “Should this new field live on the existing content type, or does it need its own related content type?”

Example Sentences

Debugging a missing-data API issue: “The response was returning articles with no author field at all — not because the relation was broken, but because populate=author was missing from the query.”

Explaining a content modeling decision: “We modeled Testimonial as its own collection type instead of a repeatable component inside Homepage, since we want to reuse the same testimonials across multiple pages.”

Describing a permissions fix in a handover note: “The 403 errors on the public blog API were resolved by enabling the find and findOne permissions for the Public role on the Article content type — they’d never been turned on after the type was created.”

Professional Tips

• Say populate explicitly when a related field is missing from an API response — it’s almost always the actual cause, not a broken relation.
• Distinguish collection type from single type clearly when proposing a new content model — picking the wrong one is a common early mistake that’s awkward to change later.
• Reference draft and publish directly when a content change “isn’t showing up” — this workflow setting, not a caching bug, is the most frequent explanation.
• Name the specific role and permission when debugging an API access error — “permissions are broken” is much less useful than “the Public role is missing the find permission on this content type.”

Practice Exercise

1. Explain the difference between a collection type and a single type.
2. Describe why populate matters when querying Strapi’s API for related data.
3. Write a sentence explaining what draft-and-publish does and why content might not appear live yet.

In Practice: Refining Your Communication with Strapi

Let’s be honest – learning a new technology is one thing; communicating effectively about it within a professional environment is quite another. For non-native English speakers using Strapi CMS, understanding nuanced phrasing isn’t just about knowing the correct word for “collection type”; it’s about conveying your ideas clearly and confidently in code reviews, Slack discussions, and Pull Request descriptions. It’s about demonstrating you understand why something is done, not just how.

One common pitfall is over-translating directly from your native language. Phrases that sound natural in one context might be awkward or even misleading in English technical communication. For example, saying “We need to make the content type more flexible” isn’t immediately clear. What does ‘flexible’ actually mean? Does it require a new field? A different relationship with another collection type? Phrases like “improve data handling” or “enhance content structure” are often better choices because they invite further discussion and clarify your intention. Similarly, avoiding overly literal translations of Strapi terms – “content item” is perfectly acceptable in English; don’t force a translation if it doesn’t roll off the tongue naturally within the team.

Another key area to focus on is expressing disagreement constructively. A simple “That’s wrong” in a code review comment isn’t helpful. Instead, try something like: “I understand your approach, but I’m concerned that this might lead to performance issues with larger datasets. Perhaps we could explore alternative indexing strategies?” This demonstrates you’ve considered the implications and offers a solution-oriented perspective. Similarly, when describing changes in a PR, avoid vague statements. Be specific about why you’re making the change – “Refactored field validation logic to improve data integrity” is much more informative than simply “Fixed field validation.”

Finally, remember that documentation isn’t just for end-users; it’s also critical for internal communication. Clear and concise PR descriptions, well-documented API calls, and even thoughtful Slack messages contribute to a shared understanding of the project.

Here’s an example of how you might use the Strapi CLI to create a new collection type:

strapi plugin generate collectiontype my-new-collectiontype --name="My Collection" --singularName="my-collection" --pluralName="my-collections"

This command, when described in a Pull Request, could be phrased as “Generated a new collection type named ‘My Collection’ with singular and plural names ‘my-collection’ and ‘my-collections’, allowing us to structure our data effectively within Strapi.” It clearly states the action taken and its purpose.