Fix inconsistent references to Settings Sidebar (#16138)

* Switch out instances of Inspector and Block Settings with Settings Sidebar; fixes #14988. * Results for npm run docs:build (whitespace)
WordPress · Jul 5, 2019 · 707336c · 707336c
1 parent 011fa75
commit 707336c
Show file tree

Hide file tree

Showing 7 changed files with 23 additions and 23 deletions.
diff --git a/docs/contributors/principles/the-block.md b/docs/contributors/principles/the-block.md
@@ -23,5 +23,5 @@ The placeholder content in the content area of the block can be thought of as a
 ### The block toolbar is the place for critical options that can’t be incorporated into placeholder UI.
 Basic block settings won’t always make sense in the context of the placeholder / content UI. As a secondary option, options that are critical to the functionality of a block can live in the block toolbar. The block toolbar is one step removed from direct manipulation, but is still highly contextual and visible on all screen sizes, so it is a great secondary option.
 
-### The block sidebar should only be used for advanced, tertiary controls.
-The sidebar is not visible by default on a small / mobile screen, and may also be collapsed even in a desktop view. Therefore, it should not be relied on for anything that is necessary for the basic operation of the block. Pick good defaults, make important actions available in the block toolbar, and think of the sidebar as something that only power users may discover.
+### The Settings Sidebar should only be used for advanced, tertiary controls.
+The Settings Sidebar is not visible by default on a small / mobile screen, and may also be collapsed even in a desktop view. Therefore, it should not be relied on for anything that is necessary for the basic operation of the block. Pick good defaults, make important actions available in the block toolbar, and think of the sidebar as something that only power users may discover.
diff --git a/docs/designers-developers/designers/block-design.md b/docs/designers-developers/designers/block-design.md
@@ -11,17 +11,17 @@ Since the block itself represents what will actually appear on the site, interac
 1. The placeholder content in the content area of the block can be thought of as a guide or interface for users to follow a set of instructions or “fill in the blanks”. For example, a block that embeds content from a 3rd-party service might contain controls for signing in to that service in the placeholder.
 2. After the user has added content, selecting the block can reveal additional controls to adjust or edit that content. For example, a signup block might reveal a control for hiding/showing subscriber count. However, this should be done in minimal ways, so as to avoid dramatically changing the size and display of a block when a user selects it (this could be disorienting or annoying).
 
-### The block toolbar is a secondary place for required options & controls
+### The Block Toolbar is a secondary place for required options & controls
 
-Basic block settings won’t always make sense in the context of the placeholder/content UI. As a secondary option, options that are critical to the functionality of a block can live in the block toolbar. The block toolbar is still highly contextual and visible on all screen sizes. One notable constraint with the block toolbar is that it is icon-based UI, so any controls that live in the block toolbar need to be ones that can effectively be communicated via an icon or icon group.
+Basic block settings won’t always make sense in the context of the placeholder/content UI. As a secondary option, options that are critical to the functionality of a block can live in the block toolbar. The Block Toolbar is still highly contextual and visible on all screen sizes. One notable constraint with the Block Toolbar is that it is icon-based UI, so any controls that live in the Block Toolbar need to be ones that can effectively be communicated via an icon or icon group.
 
-### The block sidebar should only be used for advanced, tertiary controls
+### The Settings Sidebar should only be used for advanced, tertiary controls
 
-The sidebar is not visible by default on a small / mobile screen, and may also be collapsed in a desktop view. Therefore, it should not be relied on for anything that is necessary for the basic operation of the block. Pick good defaults, make important actions available in the block toolbar, and think of the sidebar as something that most users should not need to open.
+The Settings Sidebar is not visible by default on a small / mobile screen, and may also be collapsed in a desktop view. Therefore, it should not be relied on for anything that is necessary for the basic operation of the block. Pick good defaults, make important actions available in the block toolbar, and think of the Settings Sidebar as something that most users should not need to open.
 
-In addition, use sections and headers in the block sidebar if there are more than a handful of options, in order to allow users to easily scan and understand the options available. 
+In addition, use sections and headers in the Settings Sidebar if there are more than a handful of options, in order to allow users to easily scan and understand the options available.
 
-Each block sidebar comes with an "Advanced" section by default. This area houses an "Additional CSS Class" field, and should be used to house other power user controls. 
+Each Settings Sidebar comes with an "Advanced" section by default. This area houses an "Additional CSS Class" field, and should be used to house other power user controls.
 
 ## Setup state vs. live preview state
 

diff --git a/.../block-controls-toolbars-and-inspector.md → ...ial/block-controls-toolbar-and-sidebar.md b/.../block-controls-toolbars-and-inspector.md → ...ial/block-controls-toolbar-and-sidebar.md
@@ -1,8 +1,8 @@
-# Block Controls: Toolbars and Inspector
+# Block Controls: Block Toolbar and Settings Sidebar
 
 To simplify block customization and ensure a consistent experience for users, there are a number of built-in UI patterns to help generate the editor preview. Like with the `RichText` component covered in the previous chapter, the `wp.editor` global includes a few other common components to render editing interfaces. In this chapter, we'll explore toolbars and the block inspector.
 
-## Toolbar
+## Block Toolbar
 
 ![Screenshot of the rich text toolbar applied to a paragraph block inside the block editor](https://raw.githubusercontent.com/WordPress/gutenberg/master/docs/designers-developers/assets/toolbar-text.png)
 
@@ -169,10 +169,10 @@ Note that `BlockControls` is only visible when the block is currently selected a
 
 ![Screenshot of the inspector panel focused on the settings for a paragraph block](https://raw.githubusercontent.com/WordPress/gutenberg/master/docs/designers-developers/assets/inspector.png)
 
-The inspector is used to display less-often-used settings or settings that require more screen space. The inspector should be used for **block-level settings only**.
+The Settings Sidebar is used to display less-often-used settings or settings that require more screen space. The Settings Sidebar should be used for **block-level settings only**.
 
-If you have settings that affects only selected content inside a block (example: the "bold" setting for selected text inside a paragraph): **do not place it inside the inspector**. The inspector is displayed even when editing a block in HTML mode, so it should only contain block-level settings.
+If you have settings that affects only selected content inside a block (example: the "bold" setting for selected text inside a paragraph): **do not place it inside the Settings Sidebar**. The Settings Sidebar is displayed even when editing a block in HTML mode, so it should only contain block-level settings.
 
-The inspector region is shown in place of the post settings sidebar when a block is selected.
+The Block Tab is shown in place of the Document Tab when a block is selected.
 
-Similar to rendering a toolbar, if you include an `InspectorControls` element in the return value of your block type's `edit` function, those controls will be shown in the inspector region.
+Similar to rendering a toolbar, if you include an `InspectorControls` element in the return value of your block type's `edit` function, those controls will be shown in the Settings Sidebar region.
diff --git a/docs/manifest-devhub.json b/docs/manifest-devhub.json
@@ -426,9 +426,9 @@
 		"parent": "block-tutorial"
 	},
 	{
-		"title": "Block Controls: Toolbars and Inspector",
-		"slug": "block-controls-toolbars-and-inspector",
-		"markdown_source": "../docs/designers-developers/developers/tutorials/block-tutorial/block-controls-toolbars-and-inspector.md",
+		"title": "Block Controls: Block Toolbar and Settings Sidebar",
+		"slug": "block-controls-toolbar-and-sidebar",
+		"markdown_source": "../docs/designers-developers/developers/tutorials/block-tutorial/block-controls-toolbar-and-sidebar.md",
 		"parent": "block-tutorial"
 	},
 	{

diff --git a/docs/manifest.json b/docs/manifest.json
@@ -1056,9 +1056,9 @@
 		"parent": "block-tutorial"
 	},
 	{
-		"title": "Block Controls: Toolbars and Inspector",
-		"slug": "block-controls-toolbars-and-inspector",
-		"markdown_source": "https://raw.githubusercontent.com/WordPress/gutenberg/master/docs/designers-developers/developers/tutorials/block-tutorial/block-controls-toolbars-and-inspector.md",
+		"title": "Block Controls: Block Toolbar and Settings Sidebar",
+		"slug": "block-controls-toolbar-and-sidebar",
+		"markdown_source": "https://raw.githubusercontent.com/WordPress/gutenberg/master/docs/designers-developers/developers/tutorials/block-tutorial/block-controls-toolbar-and-sidebar.md",
 		"parent": "block-tutorial"
 	},
 	{

diff --git a/docs/toc.json b/docs/toc.json
@@ -82,7 +82,7 @@
 			{ "docs/designers-developers/developers/tutorials/block-tutorial/writing-your-first-block-type.md": [] },
 			{ "docs/designers-developers/developers/tutorials/block-tutorial/applying-styles-with-stylesheets.md": [] },
 			{ "docs/designers-developers/developers/tutorials/block-tutorial/introducing-attributes-and-editable-fields.md": [] },
-			{ "docs/designers-developers/developers/tutorials/block-tutorial/block-controls-toolbars-and-inspector.md": [] },
+			{ "docs/designers-developers/developers/tutorials/block-tutorial/block-controls-toolbar-and-sidebar.md": [] },
 			{ "docs/designers-developers/developers/tutorials/block-tutorial/creating-dynamic-blocks.md": [] },
 			{ "docs/designers-developers/developers/tutorials/block-tutorial/generate-blocks-with-wp-cli.md": [] }
 		] },

diff --git a/packages/edit-post/src/components/sidebar/settings-header/index.js b/packages/edit-post/src/components/sidebar/settings-header/index.js
@@ -18,9 +18,9 @@ const SettingsHeader = ( { openDocumentSettings, openBlockSettings, sidebarName
 		[ __( 'Document' ), '' ];
 
 	const [ blockAriaLabel, blockActiveClass ] = sidebarName === 'edit-post/block' ?
-		// translators: ARIA label for the Block sidebar tab, selected.
+		// translators: ARIA label for the Settings Sidebar tab, selected.
 		[ __( 'Block (selected)' ), 'is-active' ] :
-		// translators: ARIA label for the Block sidebar tab, not selected.
+		// translators: ARIA label for the Settings Sidebar tab, not selected.
 		[ __( 'Block' ), '' ];
 
 	return (