diff --git a/source/en/glossary.asciidoc b/source/en/glossary.asciidoc index c0e08ab..dc2f6cd 100644 --- a/source/en/glossary.asciidoc +++ b/source/en/glossary.asciidoc @@ -35,7 +35,7 @@ breakpoints. See <> for more information. (((Bundle,definition))) [[glossary-bundle]] Bundle:: - Synonym for <>. + Synonym for <>. (((Cache,definition))) [[glossary-cache]] Cache:: The site's internal cache stores the output of time-consuming calculations, @@ -74,7 +74,7 @@ See <> for more information. (((Content type,definition))) [[glossary-content-type]] Content type:: - An <> for the + An <> for the <> <>. Each content type is used for some particular purpose on the site, and each has its own fields. For example, a site for a farmers market might have a @@ -125,18 +125,18 @@ <>; the first three are content entities, and the last is a configuration entity. See also <>, - <>, and + <>, and <>. See <> for more information. -(((Entity sub-type,definition))) -[[glossary-entity-sub-type]] Entity sub-type:: +(((Entity subtype,definition))) +[[glossary-entity-subtype]] Entity subtype:: Within a <> <>, a grouping of entities that share the same <>. For example, within the <> entity type, a - farmers market site might have sub-types (known as + farmers market site might have subtypes (known as <>) for static pages and vendor pages, each with its own group of fields. You may also see the term _bundle_ used - (especially in programmer documentation) as a synonym of entity sub-type. + (especially in programmer documentation) as a synonym of entity subtype. See <> for more information. (((Entity type,definition))) [[glossary-entity-type]] Entity type:: @@ -155,7 +155,7 @@ <> for more information. (((Field bundle,definition))) [[glossary-field-bundle]] Field bundle:: - Synonym for <>. + Synonym for <>. (((Formatter,definition))) (((Field formatter,definition))) [[glossary-field-formatter]] Field formatter:: @@ -338,7 +338,7 @@ <> for all of the <> of a <> <>, some of which may be hidden. Each - <> can have one or more view modes + <> can have one or more view modes defined; for example, <> typically have _Full_ and _Teaser_ view modes, where the _Teaser_ view mode displays fewer or trimmed-down fields. See <> for more information. @@ -348,7 +348,7 @@ classifying <> in a particular way, such as the list of all of the vendor categories on a farmers market site. Technically, vocabularies are the - <> for the taxonomy term + <> for the taxonomy term <>. See <> for more information. (((Widget,definition))) diff --git a/source/en/language-concept.asciidoc b/source/en/language-concept.asciidoc index d264d9a..a1f3b91 100644 --- a/source/en/language-concept.asciidoc +++ b/source/en/language-concept.asciidoc @@ -62,8 +62,8 @@ Content text and files:: If your site is multilingual, you can configure the content fields on your site to be translatable. After creating content in one language, you can translate it into other languages. Fields can contain textual information or - uploaded files, and for each field on each content type, you can configure it - to be translatable or non-translatable. You need to have the core Content + uploaded files, and for each field on each entity subtype, you can configure + it to be translatable or non-translatable. You need to have the core Content Translation module installed in order to translate this text. ==== What information will remain in English on my site? diff --git a/source/en/language-content-config.asciidoc b/source/en/language-content-config.asciidoc index 4acbb0d..5f23594 100644 --- a/source/en/language-content-config.asciidoc +++ b/source/en/language-content-config.asciidoc @@ -11,7 +11,7 @@ How to configure content items to make them translatable. ==== Goal Make _Custom block_, _Custom menu link_, and _Content_ entity types -translatable. Select specific sub-types and set which fields of these can be +translatable. Select specific subtypes and set which fields of these can be translated. ==== Prerequisite knowledge @@ -40,7 +40,7 @@ image:images/language-content-config_custom.png["Custom language settings checkl -- . Configuration options appear for _Content_, _Custom block_ and _Custom menu -link_. Choose the sub-types you want to translate for each entity +link_. Choose the subtypes you want to translate for each entity type. Check _Basic page_ for _Content_, _Basic block_ for _Custom block_ and _Custom menu link_ for _Custom menu link_. @@ -49,7 +49,7 @@ _Custom menu link_ for _Custom menu link_. [width="100%",frame="topbot",options="header"] |================================ |Field name | Explanation | Example value -| Default language | The default language for the entity sub-type | Site's default language (English) +| Default language | The default language for the entity subtype | Site's default language (English) | Show language selector on create and edit pages | Whether or not the language selector should be shown while editing and creating content | Checked |================================ + @@ -77,7 +77,7 @@ table below. If a field is not translation-dependent, leave it unchecked. + -- // Field settings area for Basic page translations. -image:images/language-content-config_basic_page.png["Translatable content entity sub-types' fields checklist"] +image:images/language-content-config_basic_page.png["Translatable content entity subtypes' fields checklist"] -- . Similarly, check the appropriate boxes for translatable fields belonging to diff --git a/source/en/planning-data-types.asciidoc b/source/en/planning-data-types.asciidoc index e560769..30dff90 100644 --- a/source/en/planning-data-types.asciidoc +++ b/source/en/planning-data-types.asciidoc @@ -9,7 +9,7 @@ Overview of content entities and fields. (((Vocabulary,overview))) (((Content,entity type))) (((Entity type,overview))) -(((Entity sub-type,overview))) +(((Entity subtype,overview))) (((Block,entity type))) (((Comment entity type,overview))) (((Contact form entity type,overview))) @@ -47,13 +47,13 @@ defined by the core software or by modules. Content entities are grouped into _entity types_, which have different purposes and are displayed in very different ways on the site. Most entity -types are also divided into _entity sub-types_, which are divisions within an +types are also divided into _entity subtypes_, which are divisions within an entity type to allow for smaller variations in how the entities are used and displayed. Here is a table of some common content entity types: [width="100%",frame="topbot",options="header",grid="rows"] |============================================= -|Entity type |Entity sub-type |Defining Module |Main uses +|Entity type |Entity subtype |Defining Module |Main uses |Content item |Content type |Node module |Content intended to be the main page area for pages on the site @@ -103,8 +103,8 @@ Within entities, the data is stored in individual _fields_, each of which holds one type of data, such as formatted or plain text, images or other files, or dates. Field types can be defined by the core software or by modules. -Fields can be added by an administrator on entity sub-types, so that all -entities of a given entity sub-type have the same collection of fields +Fields can be added by an administrator on entity subtypes, so that all +entities of a given entity subtype have the same collection of fields available. For example, the Vendor content type in the farmers market example might have fields for the vendor name, a logo image, website URL, and description, whereas the _Basic page_ content type might only have fields for diff --git a/source/en/planning-structure.asciidoc b/source/en/planning-structure.asciidoc index f377910..6f22395 100644 --- a/source/en/planning-structure.asciidoc +++ b/source/en/planning-structure.asciidoc @@ -10,7 +10,7 @@ content on the website. ==== Goal -Make a plan for the content structure of the site (which type and sub-type of +Make a plan for the content structure of the site (which type and subtype of entity to use for which content), and which pages will contain listings of content. @@ -46,12 +46,12 @@ account, and it would not be as easy to later change the ownership of a vendor page to a different user account. . Within each content entity type you identified, decide what division into -entity sub-types would make sense. For example, in the farmers market site +entity subtypes would make sense. For example, in the farmers market site example, you would probably decide that under the Content item entity type, there should be one content type for basic pages (Home and About), one for vendor pages, and one for recipe pages. -. For each entity sub-type you decided on, decide what fields are needed. For +. For each entity subtype you decided on, decide what fields are needed. For instance, the Vendor content type might need fields for the vendor name, web page URL, image, and description. @@ -67,7 +67,7 @@ example, needs to have a Recipes listing page that lists content items of type Recipe, with the ability to filter by ingredients, so that means that the Recipe content type needs an Ingredients field. -. For each identified field on each entity sub-type, identify what type of data +. For each identified field on each entity subtype, identify what type of data it should contain (such as plain text, formatted text, a date, an image file, etc.), and how many values should be allowed. Most fields are single-valued, but for example, a Recipe should allow for multiple values in @@ -88,7 +88,7 @@ scenario example site: [width="100%",frame="topbot",options="header"] |============================================= -|Entity type |Entity sub-type |Examples |Fields +|Entity type |Entity subtype |Examples |Fields |Content item |Basic page |Home page, about page |Title, page body @@ -115,7 +115,7 @@ And here are the listings the site needs: [width="100%",frame="topbot",options="header"] |============================================= -|Page or page area |Entity type and sub-type |Filter/sort/pagination | +|Page or page area |Entity type and subtype |Filter/sort/pagination | Fields displayed |Vendors page |Vendor content items |All vendors, alphabetical, paged | diff --git a/source/en/structure-taxonomy.asciidoc b/source/en/structure-taxonomy.asciidoc index 7bafbd3..b547ee5 100644 --- a/source/en/structure-taxonomy.asciidoc +++ b/source/en/structure-taxonomy.asciidoc @@ -25,7 +25,7 @@ Individual taxonomy entities are known as _terms_ (the blog tags or recipe ingredients in these examples); and a set of terms is known as a _vocabulary_ (the set of all blog post tags, or the set of all recipe ingredients in these examples). Technically, taxonomy terms are an entity type and the entity -sub-types are the vocabularies. Like other entities, taxonomy terms can have +subtypes are the vocabularies. Like other entities, taxonomy terms can have fields attached; for instance, you could set up an image field to contain an icon for each term. diff --git a/source/en/structure-widgets.asciidoc b/source/en/structure-widgets.asciidoc index 0c4a4f2..94606d9 100644 --- a/source/en/structure-widgets.asciidoc +++ b/source/en/structure-widgets.asciidoc @@ -19,12 +19,12 @@ Overview of forms and widgets. The content management system software that your site is running allows administrators to edit content and configure settings online, using various web _forms_. In particular, _content editing forms_ are used to edit your site's -content, and they are configurable by administrators; settings configuration -forms are provided by modules and cannot themselves be configured. +content entities, and they are configurable by administrators; settings +configuration forms are provided by modules and cannot themselves be configured. -The data in your site's content is stored in one or more fields that are -attached to the content type and/or sub-type. When you configure the content -editing form for each content sub-type, you can: +The data in your site's content entities is stored in one or more fields that +are attached to the entity type and/or subtype. When you configure the content +editing form for each entity subtype, you can: * Select a _widget_ for each field. A widget defines the method used to enter the data for the field. For example, a taxonomy term can be chosen using @@ -39,7 +39,7 @@ plain-text entry field. * Reorder the fields. In principle, you can also have multiple content editing forms available for -each content sub-type. This feature is rarely used, however; the only exception +each entity subtype. This feature is rarely used, however; the only exception in common use is for the user profile fields: you can use different forms for user registration and user editing. For example, you might have a limited set of fields shown when users first register on the site, and more fields shown later diff --git a/source/en/understanding-data.asciidoc b/source/en/understanding-data.asciidoc index 6ffe61f..10dd47b 100644 --- a/source/en/understanding-data.asciidoc +++ b/source/en/understanding-data.asciidoc @@ -38,7 +38,7 @@ State:: Session:: Information about individual site visitors' interactions with the site, such as whether they are logged in and their cookies. This is technically a - sub-type of State information, since it is also temporary. + subtype of State information, since it is also temporary. ==== Related topics