[TASK] Pre-Patch: Update TYPO3 versions, spellchecking, syntax

garvinhicking · garvinhicking · commit c3ee0e2a276b · 2024-06-26T14:17:01.000+02:00
This patch should only adress some minor details and wording fixes.
diff --git a/Documentation/AddingDocumentation/Index.rst b/Documentation/AddingDocumentation/Index.rst
@@ -32,14 +32,14 @@ is maintained in the core.
 Changelog
 =========
 
-Some patches require a .rst (reStructuredText) Changelog file describing the change.
+Some patches require a :file:`.rst` (reStructuredText) Changelog file describing the change.
 Not all patches
 need an entry in the Changelog. Check the list below. Also see the current
 `Changelog <https://docs.typo3.org/typo3cms/extensions/core/latest/>`__
 for some examples.
 
 Every file may optionally contain tags, but it must contain at least a
-NotScanned, PartiallyScanned or FullyScanned tag for the extension scanner.
+`NotScanned`, `PartiallyScanned`` or `FullyScanned`` tag for the extension scanner.
 See :ref:`t3coreapi:extension-scanner` in TYPO3 Explained for more
 information.
 
diff --git a/Documentation/Appendix/CommitHook.rst b/Documentation/Appendix/CommitHook.rst
@@ -35,7 +35,7 @@ This Change-Id will only be generated if it is not yet present in your commit me
 a Change-Id on your own, the result will be chaos.
 
 Apart from that the hook will check your commit message for logical errors like missing keywords, Resolves lines etc.
-For detailed information on the format of a commit message, :ref:`click here<commitmessage>`.
+For detailed information on the format of a commit message, :ref:`click here <commitmessage>`.
 
 If the commit-msg hook finds errors in your commit-msg, you can try again, by amending to the commit::
 
diff --git a/Documentation/Appendix/CommitMessage.rst b/Documentation/Appendix/CommitMessage.rst
@@ -15,7 +15,7 @@ Since we strive to automate a lot of things the commit message plays an importan
 Git and related tools work best when following a certain guideline for commit messages. A deeper `introduction on git revision log conventions <http://tbaggery.com/2008/04/19/a-note-about-git-commit-
 messages.html>`_ is helpful to understand the scope.
 
-Here is an example of a final commit message. The change-id will be generated by the commit-hook. Do not set the change-id on your first commit!
+Here is an example of a final commit message. The `Change-Id`` will be generated by the commit-hook. Do not set the `Change-Id`` on your first commit!
 
 .. code-block:: none
 
@@ -104,14 +104,18 @@ Additionally other flags  **should be added** under certain circumstances:
    about security vulnerabilities in a public place such as Slack or push patches
    that disclose information about vulnerabilities.
 
--  Keep the whole line below 52 characters if possible, but below 80 in any case
+-  Keep the whole line below 52 characters if possible, but below 72 in any case
 
 .. sidebar:: The seven rules of a great Git commit message
 
    https://chris.beams.io/posts/git-commit/#seven-rules is an excellent guide about how to write good subject lines.
 
-- It is *very important* that the message is written in **imperative mood**; that means that it must be written as if you are giving a command or an instruction, since a commit is a set of instructions for how to go from a previous state to the new state and the commit message should describe this process. This convention matches up with generated commit messages by commands like git merge and git revert.
-  If in doubt, the *golden rule* to follow is very simple: Review your subject lines, and apply the following words in front of it:
+- It is *very important* that the message is written in **imperative mood**; that means that it must be written as
+  if you are giving a command or an instruction, since a commit is a set of instructions for how to go from a previous
+  state to the new state and the commit message should describe this process. This convention matches up with generated
+  commit messages by commands like git merge and git revert.
+  If in doubt, the *golden rule* to follow is very simple: Review your subject lines, and apply the following words in
+  front of it:
 
 ``if applied, this commit will **"your subject line here"**``
 
@@ -216,11 +220,11 @@ Relationships
    .. code-block:: text
       :caption: commit message
 
-      Releases: main, 10.4, 9.5
+      Releases: main, 12.4, 11.5
 
    Always make sure the target version does indeed exist, when in doubt, as in the coredev channel on Slack_.
 
-4. `Depends`
+4. `Depends:`
    For TYPO3  **documentation patches**.
    Refer to the corresponding TYPO3 Core patch:
 
@@ -309,7 +313,7 @@ should have been:
 
 .. note::
 
-   Please note that in this case the subject of the commit to revert was poorly written,too! This required some additional adjustment..
+   Please note that in this case the subject of the commit to revert was poorly written, too! This required some additional adjustment..
 
 
 **Example 4**
diff --git a/Documentation/Appendix/Composer.rst b/Documentation/Appendix/Composer.rst
@@ -17,10 +17,10 @@ About Composer
 Composer is a dependency manager for PHP.
 
 So what it basically does is find packages you have defined to be part of your application (in our case TYPO3). But what
-if these packages rely on other packages as well? This is where composer jumps in and takes care of keeping all these
+if these packages rely on other packages as well? This is where Composer jumps in and takes care of keeping all these
 packages in sync.
 
-Since we use quite some packages (because why would we invent things ourselves that are already there?) composer is an
+Since we use quite some packages (because why would we invent things ourselves that are already there?) Composer is an
 extremely useful tool for us.
 
 .. index::
@@ -62,7 +62,7 @@ in the correct order!
 Custom TYPO3 Composer Commands
 ==============================
 
-Some additional composer commands have been added for core development.
+Some additional Composer commands have been added for Core development.
 
 Just run::
 
diff --git a/Documentation/Appendix/ResourcesForEditors/Index.rst b/Documentation/Appendix/ResourcesForEditors/Index.rst
@@ -16,8 +16,6 @@ General information
 Resources for this guide
 ========================
 
-* `warnings.txt <https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/_buildinfo/warnings.txt>`__
-  (list of warnings)
 * `Issues on Github <https://github.com/TYPO3-Documentation/TYPO3CMS-Guide-ContributionWorkflow/issues>`__
 
 Best practices for editing this guide
diff --git a/Documentation/CheatSheets/Git.rst b/Documentation/CheatSheets/Git.rst
@@ -163,19 +163,19 @@ Show all branches:
 
    git branch -a
 
-Checkout 10.4 branch:
+Checkout 12.4 branch:
 
 .. code-block:: bash
    :caption: shell command
 
-   git checkout 10.4
+   git checkout 12.4
 
-Checkout 9.5 branch:
+Checkout 11.5 branch:
 
 .. code-block:: bash
    :caption: shell command
 
-   git checkout 9.5
+   git checkout 11.5
 
 
 .. important::
@@ -188,19 +188,19 @@ Checkout 9.5 branch:
 Long story short: In most cases, **push to main**. The rest is being taken
 care of by core team members!
 
-Push 10.4 branch:
+Push 12.4 branch:
 
 .. code-block:: bash
    :caption: shell command
 
-   git push origin HEAD:refs/for/10.4
+   git push origin HEAD:refs/for/12.4
 
-Push 9.5 branch:
+Push 11.5 branch:
 
 .. code-block:: bash
    :caption: shell command
 
-   git push origin HEAD:refs/for/9.5
+   git push origin HEAD:refs/for/11.5
 
 
 Workflow - commit msg
@@ -231,7 +231,7 @@ Other keywords:
    [!!!][FEATURE]
    [WIP][TASK]
 
-* subject < 52 chars
+* subject < 52 chars (if possible, otherwise <= 72)
 * other lines <= 72 chars
 
 
diff --git a/Documentation/Community/Index.rst b/Documentation/Community/Index.rst
@@ -48,7 +48,7 @@ any TYPO3 event in some way or another.
 Look for events like "Review Friday", "Code Sprints" and "Developer Days".
 Next, we will describe some events that are relevant for core
 contribution. They are not specifically targeted at providing support,
-but the event may be open to new core contributors and may give
+but the event may be open to new Core contributors and may give
 you the opportunity to ask questions and get help. In any case,
 read the event description and if in doubt, contact the person
 listed in the event description.
@@ -64,7 +64,7 @@ Code Sprints
 ------------
 
 For joining code sprints, it is recommended that you have at least a little experience
-with TYPO3 core contribution and are familiar with the workflow.
+with TYPO3 Core contribution and are familiar with the workflow.
 
 Look for the next Code Sprints on the `Events page on typo3.org
 <https://typo3.org/community/events/>`__.
diff --git a/Documentation/CoreMergers/Backport.rst b/Documentation/CoreMergers/Backport.rst
@@ -75,7 +75,7 @@ Manual backport
 ===============
 
 If the automatic backport fails, you need to manually cherry-pick the patch to the target branch. (e.g. cherry-pick the
-main patch onto your local (up to date) 10.4 branch) You will most likely need to adjust the code for the older branch.
+main patch onto your local (up to date) 12.4 branch) You will most likely need to adjust the code for the older branch.
 
 Edit the commit message to comply to the guidelines again. (e.g. remove the Reviewed-* and Tested-* lines added by Gerrit)
 
diff --git a/Documentation/CoreMergers/Merge.rst b/Documentation/CoreMergers/Merge.rst
@@ -28,7 +28,7 @@ The merging process
    vote from a Core Merger. A :guilabel:`+2` can be given by the second
    Core Merger to review the patch positively.
 
-   Merging gets blocked by a :guilabel:`-2` vote.
+   Merging gets blocked by a single :guilabel:`-2` vote.
 
 #. Submit the patch
 
diff --git a/Documentation/HandlingAPatch/CherryPick.rst b/Documentation/HandlingAPatch/CherryPick.rst
@@ -69,7 +69,7 @@ to cherry-pick it from the review system into your local git repository.
       git fetch https://review.typo3.org/Packages/TYPO3.CMS refs/changes/47/56947/11 && git cherry-pick FETCH_HEAD
 
    Re-apply your local changes, if you had any.
-   
+
    .. code-block:: bash
 
       git stash pop 'comment-your-changes'
diff --git a/Documentation/HandlingAPatch/GerritBasics.rst b/Documentation/HandlingAPatch/GerritBasics.rst
@@ -17,7 +17,10 @@ Gerrit is a web based code review and project management tool for Git based proj
 
 TYPO3's Gerrit interface is located at https://review.typo3.org.
 
-Gerrit handles the review process and is a gatekeeper in front of the official TYPO3 Git repository on github.com/typo3/typo3. Directly pushing to the GitHub repository is not allowed. Instead every change has to pass a review process in Gerrit, which later pushes the change to the GitHub repository.
+Gerrit handles the review process and is a gatekeeper in front of the official TYPO3 Git
+repository on github.com/typo3/typo3 (mirrored from a TYPO3 GitLab instance). Directly
+pushing to the GitHub (or GitLab) repository is not allowed. Instead every change has to
+pass a review process in Gerrit, which later pushes the change to the GitLab->GitHub repositories.
 
 
 
@@ -29,11 +32,8 @@ Gerrit handles the review process and is a gatekeeper in front of the official T
 Overview of the UI
 ==================
 
-This chapter will explain the most important parts of the Gerrit_ UI to you.
-
-.. note::
-   We will focus on the new UI in this chapter. Currently, when you first open Gerrit, you might see an older
-   version of the UI. If so, please scroll down and click on the link "New UI" on the right side of the footer.
+This chapter will explain the most important parts of the Gerrit_ UI to you. For most developers, this interface
+should be mostly self-explanatory. Gerrit also comes with its own help system.
 
 This is a screenshot of an open review on Gerrit_. We will go through the parts of the UI next:
 
diff --git a/Documentation/HandlingAPatch/Index.rst b/Documentation/HandlingAPatch/Index.rst
@@ -34,7 +34,7 @@ the patch be merged (for more details on voting, see :ref:`gerrit-voting`).
 
 Additionally, a suite of tests (unit, functional and acceptance) will
 automatically run on every patch (set), the results being shown as a +1 or
--1 by typo3.com.
+-1 by "Core CI".
 
 
 
diff --git a/Documentation/HandlingAPatch/Rebase.rst b/Documentation/HandlingAPatch/Rebase.rst
@@ -50,7 +50,7 @@ different commit (typically the latest one) and your patch
 will be based on the latest version.
 
 There are other applications for rebase (e.g. squash commits),
-but this is the one relevant for the TYPO3 Contribution Workflow, so
+but only this is the one relevant for the TYPO3 Contribution Workflow, so
 this is what we mean when we talk about rebase.
 
 Do not let information on the Web confuse you: Usually
diff --git a/Documentation/HandlingAPatch/Review.rst b/Documentation/HandlingAPatch/Review.rst
@@ -138,7 +138,7 @@ and enter your comment. Here, you can also apply your votes.
 .. sidebar:: Votes
 
    The :guilabel:`+2` and :guilabel:`-2` votes are only available for Core Mergers.
-   See the section :ref:`Review a patch as a Core Merger<coreMergers-review>`.
+   See the section :ref:`Review a patch as a Core Merger <coreMergers-review>`.
    for more details.
 
 Click on :guilabel:`Send` and your comments will be saved. At the same time
diff --git a/Documentation/HandlingAPatch/Tips.rst b/Documentation/HandlingAPatch/Tips.rst
@@ -21,7 +21,7 @@ This page contains some general tips beyond the description of the workflow.
 Tips for new contributors
 =========================
 
-You are a new contributor. You found an issue in the core you wanted to
+You are a new contributor. You found an issue in the Core you wanted to
 see fixed, you found a solution, you are satisfied with it, you
 :ref:`setup your environment <setup>`, you figured out how to
 :ref:`create a patch and push to Gerrit <Fixing-a-bug-A-Z>`,
@@ -103,7 +103,7 @@ and evolve in Gerrit until everyone is satisfied. This can take some time.
 
 This is what you can do:
 
-* Familiarized yourself with :ref:`Gerrit <Working-with-Gerrit>`.
+* Familiarize yourself with :ref:`Gerrit <Working-with-Gerrit>`.
 
 * If reviewers make specific suggestions to improve your patch follow these
   suggestions and :ref:`upload another patchset <lifeOfAPatch-improve-patch>`.
@@ -193,7 +193,7 @@ Push new patchsets
 
 **Don't be scared of pushing new patch sets!**
 
-There are two different information on a merged patch set: The author of a
+There are two different pieces of information on a merged patch set: The author of a
 patch and the committer. Usually, the author of a patch is the person who
 pushed the first patch set to gerrit, while the committer is the person
 who finally pressed the merge button. When
diff --git a/Documentation/HandlingIssues/TicketWorkflow.rst b/Documentation/HandlingIssues/TicketWorkflow.rst
@@ -31,7 +31,7 @@ in the **#typo3-cms-coredev** channel. (Remember to :ref:`register <slack-accoun
 Target Versions
 ===============
 
-Target versions are set by the core team only. Until we can enforce this technically,
+Target versions are set by the Core team only. Until we can enforce this technically,
 feel free to remove target versions set by issue reporters.
 
 **Candidate for patchlevel:**
diff --git a/Documentation/ReportingAnIssue/Index.rst b/Documentation/ReportingAnIssue/Index.rst
@@ -64,7 +64,7 @@ by following these guidelines:
 
 Remove side effects
    Work on a TYPO3 instance which is as clean as possible so you can
-   rule out extensions messing with the TYPO3 core. If you need to set
+   rule out extensions messing with the TYPO3 Core. If you need to set
    up an extension to illustrate the problem, make sure it is as free
    of side effects as possible.
 
@@ -117,7 +117,7 @@ that are important. Let's go over these really quick.
 Tracker
 -------
 
-The tracker is just Redmines term for the type of issue. The trackers you will
+The `tracker`` is just Redmine's term for the type of an issue. The trackers you will
 be using the most are **Feature** and **Bug**.
 
 The others are mostly for internal organization (like **Stories** and **Epics**)
diff --git a/Documentation/Setup/Git/Index.rst b/Documentation/Setup/Git/Index.rst
@@ -79,7 +79,8 @@ Set Username and Email
 
 *-- required* (unless this is already setup globally, see `git config --global -l`)
 
-You need to instruct git to work with your name and email address. Make sure the email address and user name are the same as those you used when
+You need to instruct git to work with your name and email address. Make sure the email
+address and user name are the same as those you used when
 :ref:`setting up your TYPO3 account<TYPO3Account>`:
 
 .. code-block:: bash
@@ -103,7 +104,7 @@ Set autosetuprebase
 *-- required*
 
 In order to avoid weird merges in your local repository when pulling in new commits from typo3.org, we encourage everybody
-to set the autosetuprebase option, such that your local commits are always rebased on top of the official code:
+to set the `autosetuprebase` Git option, such that your local commits are always rebased on top of the official code:
 
 .. code-block:: bash
    :caption: shell command
@@ -209,7 +210,7 @@ Setting up a Commit Message Template
 
 If you follow these instructions, whenever you create a new commit,
 Git will use the template to create the commit message, which you can
-then modify in your editor. So use this, to make it easier for you to
+then modify in your editor. So use this to make it easier for you to
 fill out the required information.
 
 First, create a file, for example :file:`~/.gitmessage.txt`.
diff --git a/Documentation/Setup/SetupIde.rst b/Documentation/Setup/SetupIde.rst
@@ -27,7 +27,7 @@ In the Appendix, you can find some hints that might be useful for
 Coding Guidelines
 -----------------
 
-There is an .editorconfig file in the TYPO3 core repository.
+There is an :file:`.editorconfig`` file in the TYPO3 core repository.
 See https://editorconfig.org/ for more information.
 
 Please note that the rules in :file:`.editorconfig` are very minimal. So, additionally,
diff --git a/Documentation/Testing/CoreTesting.rst b/Documentation/Testing/CoreTesting.rst
@@ -35,7 +35,7 @@ System dependencies
 Many developers are familiar with `Docker <https://www.docker.com/>`_. As outlined in the
 :ref:`history <testing-history>` chapter, test execution needs a well defined, isolated, stable and
 reliable environment to run tests and also remove the need to manage niche dependencies on your local
-environment for tests such as "execute functional test "X" using PostgreSQL with xdebug".
+environment for tests such as "execute functional test 'X' using PostgreSQL with xdebug".
 
 Git, docker and docker-compose are all required. For standalone test execution, a local installation of
 PHP is not required. You can even `composer install` a Core by calling `Build/Scripts/runTests.sh -s
@@ -45,7 +45,7 @@ If you're using a Mac, install or update Docker to the most recent version using
 your choice.
 
 If you are using Ubuntu Linux 18.04 or higher, everything should be ok after
-calling `sudo apt-get install git docker docker-compose` once. For other Linux distributions
+calling `sudo apt-get install git docker` once. For other Linux distributions
 including older releases of Ubuntu, users should have a look at the Docker homepage to see how to update
 to a recent version. It usually involves adding some other package repository and updating / installing using it.
 Make sure your local user is a member of the `docker` group, else the script will fail with something like
@@ -70,8 +70,8 @@ running on the host system. Executing the basic Core unit test suite boils down
     Build/Scripts/runTests.sh
 
 That's it. You just executed the entire unit test suite.
-Now that we have examined the initial Core clone and a Composer install process, we will then look at the
-different ways we can apply the :file:`runTests.sh` or other scenarios.
+Now that we have examined the initial Core clone and a Composer install process, we will look at the
+different ways we can utilize the :file:`runTests.sh` for other scenarios.
 
 
 Overview
diff --git a/Documentation/Testing/History.rst b/Documentation/Testing/History.rst
diff --git a/Documentation/Testing/Index.rst b/Documentation/Testing/Index.rst
diff --git a/Documentation/Troubleshooting/Index.rst b/Documentation/Troubleshooting/Index.rst
diff --git a/Documentation/WorkflowExplained/Index.rst b/Documentation/WorkflowExplained/Index.rst
