Fixing Typos (#6109)

Co-authored-by: Steve Piercy <[email protected]>
Co-authored-by: ichim-david <[email protected]>

apps/plone/src/addons/volto-volto-project/dockerfiles/docker-compose.yml

@@ -15,7 +15,7 @@ services:
     environment:
       RAZZLE_INTERNAL_API_PATH: http://backend:8080/Plone
       # In case that you want to connect to and outside (non-docker) local instance
-      # coment the above, use the next line
+      # comment the above, use the next line
       # RAZZLE_INTERNAL_API_PATH: http://host.docker.internal:8080/Plone
       RAZZLE_API_PATH: http://127.0.0.1:8080/Plone
       HOST: 0.0.0.0

docs/source/addons/best-practices.md

@@ -84,4 +84,4 @@ Even if you think your add-on is not generic or it's tricky to integrate, please
 consider including your add-on in the
 [`collective/awesome-volto`](https://github.com/collective/awesome-volto) add-ons
 list. This provides visibility to your add-on but also further solidifies
-Volto's possition in our Plone community.
+Volto's position in our Plone community.

docs/source/addons/theme.md

@@ -12,7 +12,7 @@ myst:
 We can create a Volto Add-on that acts as a Volto theme Add-on, so we can detach it from the project files.
 The advantage is that you convert the project Volto theme in a pluggable one, so you can deploy the same theme in different projects.
 You can even have themes depending on conditions that you could inject on build time.
-This is the purpose of `volto.config.js`, the ability of declaring `add-ons` and the active `theme` programatically. See {ref}`volto-config-js` for more information.
+This is the purpose of `volto.config.js`, the ability of declaring `add-ons` and the active `theme` programmatically. See {ref}`volto-config-js` for more information.
 For convenience, it can also be set via a `THEME` environment variable.
 
 1. Add a `theme` key in your `volto.config.js` file in the root of your project:

docs/source/blocks/core/listing.md

@@ -13,7 +13,7 @@ myst:
 
 The listing block is a special block that can be configured to run a catalog query in the backend and show the results of that search.
 
-Apart from the {ref}`standard variation <extensions-block-variations>` and {ref}`schema enchancing extensions <extensions-schema-enhancers>`, the listing block provides a configurable way to handle the "No results" message.
+Apart from the {ref}`standard variation <extensions-block-variations>` and {ref}`schema enhancing extensions <extensions-schema-enhancers>`, the listing block provides a configurable way to handle the "No results" message.
 
 When the listing block configured search returns no results, Volto presents a default "No results found" message.
 But sometimes you want to change such a message to offer more meaningful messages, or do some other fancy stuff in that case.

docs/source/blocks/editcomponent.md

@@ -51,7 +51,7 @@ import { SidebarPopup } from '@plone/volto/components';
 A helper component is available in core in order to simplify the task of defining and rendering the settings for a block: the `BlockDataForm` component.
 
 ```{note}
-`BlockDataForm` is a convenience component around the already available in core `InlineForm` that takes care of some aspects exclusively for Volto Blocks, like Variants and schemaExtenders. You can still use `InlineForm` across Volto, but using `BlockDataForm` is recommeneded for the blocks settings use case.
+`BlockDataForm` is a convenience component around the already available in core `InlineForm` that takes care of some aspects exclusively for Volto Blocks, like Variants and schemaExtenders. You can still use `InlineForm` across Volto, but using `BlockDataForm` is recommended for the blocks settings use case.
 ```
 
 The edit block settings component needs to be described by a schema that matches the format used to serialize the content type definitions. The widgets that will be used in rendering the form follow the same algorithm that is used for the regular metadata fields for the content types. As an example of schema, it could look like this:
@@ -220,7 +220,7 @@ This situation will be fixed in subsequent Volto releases.
 #### PropDataName vs dataName
 
 - `dataName` is the prop inside `data` object, used for `link` and `image` mode.
-- `PropDataName` is the name of field wich value is `data`. It's used for `multiple` mode.
+- `PropDataName` is the name of field which value is `data`. It's used for `multiple` mode.
 
 For example:
 

docs/source/blocks/introduction.md

@@ -75,7 +75,7 @@ You can enable them on any content type by enabling `Blocks` behavior provided b
 3. Select the `Blocks` behavior
 4. Save
 
-You can also add the behavior programatically via GenericSetup:
+You can also add the behavior programmatically via GenericSetup:
 
 ```xml
 <?xml version="1.0"?>

docs/source/client/quick-start.md

@@ -14,7 +14,7 @@ The API request layer allows to build and send arbitrary requests to Plone REST
 It has the potential to also be able to send requests to other APIs (provided the custom Query options factories/functions).
 
 The Javascript Plone client is conceived to work with TanStack Query, the query or mutation functions can be used to call any Plone REST API endpoint without using it.
-These functions can be used in other use cases like command line helpers, scripts or programatic tests.
+These functions can be used in other use cases like command line helpers, scripts or programmatic tests.
 
 ## Installation​
 

docs/source/configuration/component-registry.md

@@ -34,7 +34,7 @@ config.registerComponent({
 
 ## Retrieving a component from the component registry
 
-You can programatically retrieve a component from the registry using `config.getComponent`:
+You can programmatically retrieve a component from the registry using `config.getComponent`:
 
 ```js
 const Toolbar = config.getComponent('Toolbar').component
@@ -89,7 +89,7 @@ config.registerComponent({
   });
 ```
 
-and then retrieve them both, depending on the use case (in the example, given a content type value comming from `content` prop):
+and then retrieve them both, depending on the use case (in the example, given a content type value coming from `content` prop):
 
 ```jsx
 <Component componentName="Toolbar" dependencies={[props.content['@type']]} {...props} />

docs/source/configuration/internalproxy.md

@@ -40,7 +40,7 @@ back json to the frontend.
 You could also use the internal proxy for production setups. For convenience and for
 testing/demoing using the stock build, it is also enabled in production mode since
 Volto 14. But it is bad for performance because the server side running Node.js process
-is also responsable for generating the SSR HTML. With nginx, Apache or another
+is also responsible for generating the SSR HTML. With nginx, Apache or another
 'reverse proxy' you can also create an internal API mount which is more suited for
 that. For more deployment information see {doc}`../deploying/seamless-mode`.
 ```

docs/source/configuration/volto-config-js.md

@@ -9,7 +9,7 @@ myst:
 
 (volto-config-js)=
 
-# Programatically define the active add-ons and theme
+# Programmatically define the active add-ons and theme
 
 Volto allows you to define the active `add-ons` and `theme` via a file in the root of your project called `volto.config.js`.
 

docs/source/configuration/workingcopy.md

@@ -27,5 +27,5 @@ Volto working copy support features include:
 
 - "Checkout" any content (except Plone site object) and create a working copy of that content
 - Work on the working copy
-- "Checkin" the working copy by applying the changes into the original (baseline) object
+- "Check in" the working copy by applying the changes into the original (baseline) object
 - Cancel the working copy if required

docs/source/configuration/zero-config-builds.md

@@ -68,7 +68,7 @@ server {
 
 ## Configuring PORT on runtime
 
-PORT environment variable is also configurable at runtime, whish is specially useful in production since you can inject it in the run command line or in your favorite process manager, per config, without having to rebuild Volto in the process. In PM2 it would be like:
+PORT environment variable is also configurable at runtime, which is specially useful in production since you can inject it in the run command line or in your favorite process manager, per config, without having to rebuild Volto in the process. In PM2 it would be like:
 
 ```js hl_lines="9"
 module.exports = {

docs/source/contributing/developing-core.md

@@ -352,7 +352,7 @@ pnpm --filter plone-vite-ssr dev
 
 ## Support libraries
 
-Volto uses serveral libraries to support development.
+Volto uses several libraries to support development.
 
 ### `volto-coresandbox`
 

docs/source/contributing/documentation.md

@@ -152,7 +152,7 @@ make storybook-build
 
 To hyperlink to Storybook entries from the narrative documentation, you can use one of two syntaxes.
 
-Use HTML syntax to enable hyperlinking in development, within Netlify preview builds, and when the main Plone documenation is updated.
+Use HTML syntax to enable hyperlinking in development, within Netlify preview builds, and when the main Plone documentation is updated.
 Hyperlinking in development requires that you run both `make docs-html` and `make storybook-build` commands once, then whenever you update either the narrative documentation or the Storybook.
 
 % sphinx-examples does not render HTML

docs/source/contributing/language-features.md

@@ -38,7 +38,7 @@ currently targeting.
 
 By doing this, it enables the bundles to be smaller, as the resulting code does not need to
 support old browsers (thus, transform your code to ES5 compatible code) as Babel will
-apply only the required transforms that your target enviroments need. For more
+apply only the required transforms that your target environments need. For more
 information: https://babeljs.io/docs/babel-preset-env#browserslist-integration
 
 Volto project generators use this browserlist by default (you can find it in your local `package.json`):

docs/source/contributing/version-policy.md

@@ -60,7 +60,7 @@ Volto should work on older Plone versions as well, since Plone REST API supports
 We do not support or test Plone versions that were released before Volto existed.
 
 ```{seealso}
-See also [Plone REST API Python and Plone compatability](https://github.com/plone/plone.restapi#python--plone-compatibility).
+See also [Plone REST API Python and Plone compatibility](https://github.com/plone/plone.restapi#python--plone-compatibility).
 ```
 
 

docs/source/deploying/performance.md

@@ -36,7 +36,7 @@ critical-cli -h
 critical-cli https://example.com/ -o critical.css
 ```
 
-You can pass multiple URLs and screen dimmensions and the extracted CSS will be
+You can pass multiple URLs and screen dimensions and the extracted CSS will be
 optimized (duplicate rules will be eliminated, etc). See the [Advanced preset
 of cssnano](https://cssnano.github.io/cssnano/docs/what-are-optimisations/) for details. One last
 optimization applied strips all `@import` declarations from the generated CSS.

docs/source/deploying/pm2.md

@@ -18,7 +18,7 @@ You can use the good old known supervisord as well. However, the supervisord pro
 Create a file `mywebsite.com.pm2.config.js` in your repository or on your server.
 
 ```{important}
-Make sure your PM2 config file sufix ends in `config.js`, otherwise PM2 will ignore it.
+Make sure your PM2 config file suffix ends in `config.js`, otherwise PM2 will ignore it.
 ```
 
 ```js

docs/source/deploying/seamless-mode.md

@@ -129,7 +129,7 @@ server {
   access_log /dev/stdout;
   error_log /dev/stdout;
 
-  # [seamless mode] Recomended as default configuration, using seamless mode new plone.rest traversal
+  # [seamless mode] Recommended as default configuration, using seamless mode new plone.rest traversal
   # yarn build && yarn start:prod
   location ~ /\+\+api\+\+($|/.*) {
       rewrite ^/\+\+api\+\+($|/.*) /VirtualHostBase/http/myservername.org/Plone/++api++/VirtualHostRoot/$1 break;

docs/source/deploying/sentry.md

@@ -13,7 +13,7 @@ Volto can be configured to work with [Sentry.io](https://sentry.io/welcome/).
 Sentry is a monitoring platform that can help identify the cause of errors in your project.
 
 
-## Prerequisities
+## Prerequisites
 
 1.  Install the add-on [`@plone-collective/volto-sentry`](https://www.npmjs.com/package/@plone-collective/volto-sentry).
 2.  In Sentry, create a new organization, and add a project to it.

docs/source/development/customizing-components.md

@@ -109,7 +109,7 @@ Tags.defaultProps = {
 export default Tags;
 ```
 
-The final path of the overrided component will be
+The final path of the overridden component will be
 `customizations/components/theme/Tags/Tags.jsx`.
 
 (advanced-customization-scenarios-label)=

docs/source/development/how-to-restrict-blocks.md

@@ -12,7 +12,7 @@ myst:
 You can restrict blocks from being added to a content type using the `restricted` key in the configuration object.
 This key can be a boolean or a function that returns a boolean.
 If the block is restricted, it won't show in the chooser.
-However, it can still be added either programatically or by directly using the REST API, so this restriction only applies to the user interface.
+However, it can still be added either programmatically or by directly using the REST API, so this restriction only applies to the user interface.
 The function has this signature:
 
 ```ts

docs/source/development/ie11compat.md

@@ -4,7 +4,7 @@ myst:
     "description": "Legacy browser support with polyfills, babel-env, and pre- and post-transpiling"
     "property=og:description": "Legacy browser support with polyfills, babel-env, and pre- and post-transpiling"
     "property=og:title": "Legacy Browser Support (IE11 compatibility)"
-    "keywords": "Volto, Plone, frontend, React, IE11 compatability, polyfills, legacy browser support"
+    "keywords": "Volto, Plone, frontend, React, IE11 compatibility, polyfills, legacy browser support"
 ---
 
 # Legacy Browser Support (IE11 compatibility)

docs/source/development/lazyload.md

@@ -46,8 +46,8 @@ A browser will open with the bundle inspector.
 Lazy-loading libraries is not as straight-forward as with the React components.
 The API offered by `@loadable/component` is not very ergonomic and
 importing a library as lazy library introduces a lot of pain points in your
-code: you have to alway check if the library is loaded, depending on multiple
-lazy libraries further complicates the code, etc. To aleviate this and to
+code: you have to always check if the library is loaded, depending on multiple
+lazy libraries further complicates the code, etc. To alleviate this and to
 promote the use of lazy libraries everywhere, we have the `injectLazyLibs` HOC
 wrapper that can automatically inject lazy-loaded libraries as props to your
 components. To use it:

docs/source/upgrade-guide/index.md

@@ -81,7 +81,7 @@ yarn
 ```
 
 After this, the `volto-update-deps` script will be available in your environment.
-Now you can run the script to syncrhonize dependencies:
+Now you can run the script to synchronize dependencies:
 
 ```shell
 yarn volto-update-deps
@@ -1403,16 +1403,16 @@ Not really a breaking change, but it's worth noting it. By default, Volto 14 com
 ### Blocks chooser now uses the title instead of the id of the block as translation source
 
 The `BlockChooser` component now uses the `title` of the block as source for translating
-the block title. Before, it took the `id` of the block, which is utterly wrong and missleading. There is a chance that this change will trigger untranslated blocks titles in your projects and add-ons.
+the block title. Before, it took the `id` of the block, which is utterly wrong and misleading. There is a chance that this change will trigger untranslated blocks titles in your projects and add-ons.
 
 ### Variation field now uses the title instead of the id of the variation as translation source
 
 Following the same convention as the above change, `Variation` field coming from the block enhancers now uses the `title` of the block as source for translating
-the variation title. Before, it took the `id` of the block, which as stated before, is wrong and missleading. There is a chance that  this change will trigger untranslated variation titles in your projects and add-ons.
+the variation title. Before, it took the `id` of the block, which as stated before, is wrong and misleading. There is a chance that  this change will trigger untranslated variation titles in your projects and add-ons.
 
 ### Listing block no longer retrieve fullobjects by default
 
-The query used by the listing block always used the `fullobjects` flag, which fully serialized (and thus, wake from the db) the resultant response items. This was causing performance issues. From Volto 14, the results will get the normal catalog query metadata results. You'll need to adapt your code to get the appropiate data if required and/or use the metadata counterparts. If your custom code depends on this behavior and you don't have time to adapt now, there's a scape hatch: set an additional `fullobjects` key to `true` per variation in the variation of the listing block config object:
+The query used by the listing block always used the `fullobjects` flag, which fully serialized (and thus, wake from the db) the resultant response items. This was causing performance issues. From Volto 14, the results will get the normal catalog query metadata results. You'll need to adapt your code to get the appropriate data if required and/or use the metadata counterparts. If your custom code depends on this behavior and you don't have time to adapt now, there's a scape hatch: set an additional `fullobjects` key to `true` per variation in the variation of the listing block config object:
 
 ```js
     variations: [
@@ -2026,7 +2026,7 @@ See the documentation of Razzle for more information: https://razzlejs.org/
 #### Changes involved
 
 We need to patch an internal Razzle utility in order to allow the use of non-released
-Razzle plugins. This feature will be in Razzle 4, unfortunatelly at this point the
+Razzle plugins. This feature will be in Razzle 4, unfortunately at this point the
 development of the Razzle 3 branch is freezed already, so we need to amend the original
 using the patch. The patch will be obsolete and no longer required once we move to
 Razzle 4 (see https://github.com/jaredpalmer/razzle/pull/1467).
@@ -2100,7 +2100,7 @@ diff --git a/package.json b/package.json
      "mrs-developer": "1.2.0",
 ```
 
-### Recomended `browserslist` in `package.json`
+### Recommended `browserslist` in `package.json`
 
 Not a breaking change, but you might want to narrow the targets your Volto project is
 targeting. This might improve your build times, as well as your bundle size. This is
@@ -2714,7 +2714,7 @@ create your own as well.
 
 ### Blocks engine - Simplification of the edit blocks wrapper
 
-The edit block wrapper boilerplate was quite big, and for bootstraping an edit block you had to copy it from an existing block. Now all this boilerplate has been transferred to the Blocks Engine, so bootstrapping the edit component of a block is easier and does not require any pre-existing code.
+The edit block wrapper boilerplate was quite big, and for bootstrapping an edit block you had to copy it from an existing block. Now all this boilerplate has been transferred to the Blocks Engine, so bootstrapping the edit component of a block is easier and does not require any pre-existing code.
 
 In order to upgrade your blocks you should simplify the outer `<div>` (took as an example the Title block):
 

packages/registry/README.md

@@ -122,7 +122,7 @@ The configuration registry also stores a components registry in itself.
 The components registry is a mapping of name to component.
 You can look up a name, and receive a component that you can reference in your code.
 This provides an alternative, and more convenient, way to customize components.
-You can override programatically such registrations from your add-on or projects because it's stored in the configuration registry.
+You can override programmatically such registrations from your add-on or projects because it's stored in the configuration registry.
 You can customize a component without using shadowing at all, if the code that uses the component retrieves from the component registry, rather then import it directly.
 You can even have modifiers to the component registrations through dependencies.
 Thus you can adapt the call, given an array of such dependencies.
@@ -142,7 +142,7 @@ config.registerComponent({
 
 ## Retrieve a component from the component registry
 
-You can programatically retrieve a component from the registry using `config.getComponent`:
+You can programmatically retrieve a component from the registry using `config.getComponent`:
 
 ```js
 const Toolbar = config.getComponent('Toolbar').component

packages/registry/news/6109.documentation

@@ -0,0 +1 @@
+Changed a few typos within documentation, README's and comments. @FritzHoing

packages/volto/locales/ca/LC_MESSAGES/volto.po

@@ -1872,7 +1872,7 @@ msgstr "Mida del lot d'articles"
 
 #. Default: "Item successfully moved."
 #: components/manage/Contents/Contents
-msgid "Item succesfully moved."
+msgid "Item successfully moved."
 msgstr "L'element s'ha mogut correctament."
 
 #. Default: "Item(s) copied."

packages/volto/locales/de/LC_MESSAGES/volto.po

@@ -1871,7 +1871,7 @@ msgstr "Batch-Anzahl"
 
 #. Default: "Item successfully moved."
 #: components/manage/Contents/Contents
-msgid "Item succesfully moved."
+msgid "Item successfully moved."
 msgstr "Objekt wurde erfolgreich verschoben."
 
 #. Default: "Item(s) copied."