Welcome to the official home of the WordPress Documentation Team.
This team is responsible for coordinating all documentation initiatives around WordPress, including the handbooks and other general wordsmithing across the WordPress project.
Want to get involved?
Start here to find out more about what we do and how to contribute:
Documentation Issue Tracker on GitHub: Submit any Documentation Team-related issues on GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/
Weekly meetings
Join our discussions of documentation issues here on the blog and on Slack.
In general, hyphenate words beginning with e- such as e-learning, e-book, and e-commerce, unless e- is followed by a proper noun or it is absolutely necessary to avoid confusion.
In general, use element for HTML and XML items. HTML 4 elements are known as tags, but the equivalent elements in modern HTML and XML are known as elements.
It’s OK to use emoji to refer to small symbols such as 😃 that represent emoticons, gestures, concepts, objects, and other symbols in documentation with an informal tone.
Use lowercase. Use emoji for both singular and plural forms.
Don’t use emoji in documentation or the UI when there’s a serious problem, failure, or error.
Use regular punctuation with emoji that appear in running text.
Example
Recommended: Look out for new updates 👀!
Ensure that the meaning of your documentation could be conveyed without emoji. Using emoji may prove to be difficult for accessibility, localization, or for translation. People with cognitive impairments, as well as people using assistive technologies such as screen-reading software and might have difficulty interpreting emoji.
It’s OK to use emoticons to represent an emotion or a facial expression in documentation with an informal tone. Generally, emoticons are created with typographic characters or symbols such as :), :P, or XD.
Don’t use emoticons in documentation or the UI when there’s a serious problem, failure, or error.
Use regular punctuation with emoji that appear in running text.
Example
Recommended: The bug was fixed :).
Ensure that the meaning of your documentation could be conveyed without emoticons. Using emoticons may prove to be difficult for accessibility, localization, or for translation. People with cognitive impairments, as well as people using assistive technologies such as screen-reading software and might have difficulty interpreting emoticons.
Use enable to refer to turning on an option or feature or making an action possible.
Example
Recommended: To enable full width, select the Site Width toggle button.
Don’t use enables for things that allow you, or let you, or give you the ability to do something. Instead, rewrite the sentence to emphasize on the task that the user can accomplish. If you have to express ability to do something, use lets you.
Examples
Not recommended: The get request enables you to retrieve the data.
Sometimes okay: The get request lets you retrieve the data.
Recommended: You can retrieve the data using the get request.
Don’t use enabled to mean selected such as while referring to radio buttons or checkboxes.
Examples
Not recommended: Ensure that your choice is enabled.
