Fix spellings and add words to accept.txt configuration

Author: stevepiercy

docs/backend/content-types/fti.md

@@ -139,7 +139,7 @@ The XML sets a number of FTI properties that are used globally, in both Classic
 :   Defines additional {doc}`actions </backend/portal-actions>` which are available for this content type.
 
 `add_permission`
-:   ID of the permission controling whether the current user has permission to add this content type.
+:   ID of the permission controlling whether the current user has permission to add this content type.
 
 `allow_discussion`
 :   Boolean.
@@ -197,7 +197,7 @@ The XML sets a number of FTI properties that are used globally, in both Classic
 The following FTI properties are used only in Classic UI:
 
 `add_view_expr`
-:   {term}`TALES` expression returning the URL for the form to add a new item of this content type.
+:   {term}`TALES` expression returning the URL of the form to add a new item of this content type.
 
 `alias` elements
 :   Controls a mapping from URL to views.

docs/backend/content-types/index.md

@@ -25,8 +25,8 @@ For example, each content type has:
 
 -   a {doc}`schema </backend/schemas>` specifying the fields which can be edited for the content type
 -   a list of {doc}`behaviors </backend/behaviors>` which supply additional functionality that can be attached to the content types for which the behavior is enabled
--   a {doc}`workflow </backend/workflows>` controling transitions between publishing states and associated permissions
--   a version policy controling whether to store a revision history
+-   a {doc}`workflow </backend/workflows>` controlling transitions between publishing states and associated permissions
+-   a version policy controlling whether to store a revision history
 
 It is common in developing a website that you'll need customized versions of common content types, or perhaps even entirely new types.
 
@@ -39,7 +39,7 @@ The ZODB is well suited to heterogeneous, loosely structured content such as web
 Types in Plone are either `containers` or `items` (this distinction is sometimes called folderish versus non-folderish).
 A one-to-many type relationship is typically modeled as a container (the "one") containing many items (the "many"), although it is also possible to use references across the content hierarchy.
 
-Each type has a {doc}`schema </backend/schemas>`, which is a set of {doc}`/backend/fields` with related properties, such as a title, default value, constraints, and so on.
+Each type has a {doc}`schema </backend/schemas>`, which is a set of {doc}`/backend/fields` with related properties, such as a title, default value, constraints, and other properties.
 The schema is used to generate forms and describe instances of the type.
 In addition to schema-driven forms, a type typically comes with one or more {doc}`/classic-ui/views` as well as {doc}`/classic-ui/viewlets` and is subject to security—for example, add permissions, or per-field read and write permissions—and workflow.
 
@@ -72,7 +72,7 @@ fti
 ```{toctree}
 :maxdepth: 2
 ```
-% Uncomment each of the following and move into the toctree above when migrated from Plone 5 documentation
+% Uncomment each of the following and move into the `toctree` above when migrated from Plone 5 documentation
 % prerequisite
 % schema-driven-types
 % model-driven-types

styles/Vocab/Plone/accept.txt

@@ -5,10 +5,11 @@
 `plone.restapi`
 `plone.volto`
 accessor
+APIs
 [Aa]sync
 [Bb]ackend
 Barceloneta
-boolean
+[Bb]oolean
 buildout
 doctest
 folderish
@@ -32,6 +33,7 @@ subfolder
 transpile[dr]{0,1}
 unregister
 UUID
+[Uu]ncomment
 validator
 viewlet
 Volto