New release v2.12.2 (#76892)

CentOS 8 has been EOL for ~1 month now.

.azure-pipelines/azure-pipelines.yml

@@ -120,8 +120,6 @@ stages:
               test: centos6
             - name: CentOS 7
               test: centos7
-            - name: CentOS 8
-              test: centos8
             - name: Fedora 33
               test: fedora33
             - name: Fedora 34
@@ -194,8 +192,6 @@ stages:
               test: centos6
             - name: CentOS 7
               test: centos7
-            - name: CentOS 8
-              test: centos8
             - name: Fedora 33
               test: fedora33
             - name: Fedora 34

.azure-pipelines/scripts/aggregate-coverage.sh

@@ -11,7 +11,7 @@ mkdir "${agent_temp_directory}/coverage/"
 
 options=(--venv --venv-system-site-packages --color -v)
 
-ansible-test coverage combine --export "${agent_temp_directory}/coverage/" "${options[@]}"
+ansible-test coverage combine --group-by command --export "${agent_temp_directory}/coverage/" "${options[@]}"
 
 if ansible-test coverage analyze targets generate --help >/dev/null 2>&1; then
     # Only analyze coverage if the installed version of ansible-test supports it.

.azure-pipelines/scripts/publish-codecov.py

@@ -0,0 +1,101 @@
+#!/usr/bin/env python
+"""
+Upload code coverage reports to codecov.io.
+Multiple coverage files from multiple languages are accepted and aggregated after upload.
+Python coverage, as well as PowerShell and Python stubs can all be uploaded.
+"""
+
+import argparse
+import dataclasses
+import pathlib
+import shutil
+import subprocess
+import tempfile
+import typing as t
+import urllib.request
+
+
+@dataclasses.dataclass(frozen=True)
+class CoverageFile:
+    name: str
+    path: pathlib.Path
+    flags: t.List[str]
+
+
+@dataclasses.dataclass(frozen=True)
+class Args:
+    dry_run: bool
+    path: pathlib.Path
+
+
+def parse_args() -> Args:
+    parser = argparse.ArgumentParser()
+    parser.add_argument('-n', '--dry-run', action='store_true')
+    parser.add_argument('path', type=pathlib.Path)
+
+    args = parser.parse_args()
+
+    # Store arguments in a typed dataclass
+    fields = dataclasses.fields(Args)
+    kwargs = {field.name: getattr(args, field.name) for field in fields}
+
+    return Args(**kwargs)
+
+
+def process_files(directory: pathlib.Path) -> t.Tuple[CoverageFile, ...]:
+    processed = []
+    for file in directory.joinpath('reports').glob('coverage*.xml'):
+        name = file.stem.replace('coverage=', '')
+
+        # Get flags from name
+        flags = name.replace('-powershell', '').split('=')  # Drop '-powershell' suffix
+        flags = [flag if not flag.startswith('stub') else flag.split('-')[0] for flag in flags]  # Remove "-01" from stub files
+
+        processed.append(CoverageFile(name, file, flags))
+
+    return tuple(processed)
+
+
+def upload_files(codecov_bin: pathlib.Path, files: t.Tuple[CoverageFile, ...], dry_run: bool = False) -> None:
+    for file in files:
+        cmd = [
+            str(codecov_bin),
+            '--name', file.name,
+            '--file', str(file.path),
+        ]
+        for flag in file.flags:
+            cmd.extend(['--flags', flag])
+
+        if dry_run:
+            print(f'DRY-RUN: Would run command: {cmd}')
+            continue
+
+        subprocess.run(cmd, check=True)
+
+
+def download_file(url: str, dest: pathlib.Path, flags: int, dry_run: bool = False) -> None:
+    if dry_run:
+        print(f'DRY-RUN: Would download {url} to {dest} and set mode to {flags:o}')
+        return
+
+    with urllib.request.urlopen(url) as resp:
+        with dest.open('w+b') as f:
+            # Read data in chunks rather than all at once
+            shutil.copyfileobj(resp, f, 64 * 1024)
+
+    dest.chmod(flags)
+
+
+def main():
+    args = parse_args()
+    url = 'https://ansible-ci-files.s3.amazonaws.com/codecov/linux/codecov'
+    with tempfile.TemporaryDirectory(prefix='codecov-') as tmpdir:
+        codecov_bin = pathlib.Path(tmpdir) / 'codecov'
+        download_file(url, codecov_bin, 0o755, args.dry_run)
+
+        files = process_files(args.path)
+        upload_files(codecov_bin, files, args.dry_run)
+
+
+if __name__ == '__main__':
+    main()

.azure-pipelines/scripts/publish-codecov.sh

@@ -1,27 +0,0 @@
-#!/usr/bin/env bash
-# Upload code coverage reports to codecov.io.
-# Multiple coverage files from multiple languages are accepted and aggregated after upload.
-# Python coverage, as well as PowerShell and Python stubs can all be uploaded.
-
-set -o pipefail -eu
-
-output_path="$1"
-
-curl --silent --show-error https://ansible-ci-files.s3.us-east-1.amazonaws.com/codecov/codecov.sh > codecov.sh
-
-for file in "${output_path}"/reports/coverage*.xml; do
-    name="${file}"
-    name="${name##*/}"  # remove path
-    name="${name##coverage=}"  # remove 'coverage=' prefix if present
-    name="${name%.xml}"  # remove '.xml' suffix
-
-    bash codecov.sh \
-        -f "${file}" \
-        -n "${name}" \
-        -X coveragepy \
-        -X gcov \
-        -X fix \
-        -X search \
-        -X xcode \
-        || echo "Failed to upload code coverage report to codecov.io: ${file}"
-done

.azure-pipelines/scripts/report-coverage.sh

@@ -14,4 +14,4 @@ fi
 
 # Generate stubs using docker (if supported) otherwise fall back to using a virtual environment instead.
 # The use of docker is required when Powershell code is present, but Ansible 2.12 was the first version to support --docker with coverage.
-ansible-test coverage xml --stub --docker --color -v || ansible-test coverage xml --stub --venv --venv-system-site-packages --color -v
+ansible-test coverage xml --group-by command --stub --docker --color -v || ansible-test coverage xml --group-by command --stub --venv --venv-system-site-packages --color -v

.azure-pipelines/templates/coverage.yml

@@ -36,7 +36,7 @@ jobs:
           pathToSources: "$(Agent.BuildDirectory)/$(checkoutPath)"
         displayName: Publish to Azure Pipelines
         condition: gt(variables.coverageFileCount, 0)
-      - bash: .azure-pipelines/scripts/publish-codecov.sh "$(outputPath)"
+      - bash: .azure-pipelines/scripts/publish-codecov.py "$(outputPath)"
         displayName: Publish to codecov.io
         condition: gt(variables.coverageFileCount, 0)
         continueOnError: true

README.rst

@@ -32,8 +32,6 @@ You can install a released version of Ansible with ``pip`` or a package manager.
 `installation guide <https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html>`_ for details on installing Ansible
 on a variety of platforms.
 
-Red Hat offers supported builds of `Ansible Engine <https://www.ansible.com/ansible-engine>`_.
-
 Power users and developers can run the ``devel`` branch, which has the latest
 features and fixes, directly. Although it is reasonably stable, you are more likely to encounter
 breaking changes when running the ``devel`` branch. We recommend getting involved

changelogs/CHANGELOG-v2.12.rst

@@ -0,0 +1,518 @@
+====================================================
+ansible-core 2.12 "Dazed and Confused" Release Notes
+====================================================
+
+.. contents:: Topics
+
+
+v2.12.2
+=======
+
+Release Summary
+---------------
+
+| Release Date: 2022-01-31
+| `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__
+
+
+Bugfixes
+--------
+
+- Fix ``AttributeError`` when providing password file via ``--connection-password-file`` (https://github.com/ansible/ansible/issues/76530)
+- Fix ``end_play`` to end the current play only (https://github.com/ansible/ansible/issues/76672)
+- Templating - Ensure we catch exceptions when getting ``.filters`` and ``.tests`` attributes on their respective plugins and properly error, instead of aborting which results in no filters being added to the jinja2 environment
+- ``Templar.copy_with_new_env`` - set the ``finalize`` method of the new ``Templar`` object for the new environment (https://github.com/ansible/ansible/issues/76379)
+- ansible-config avoid showing _terms and _input when --only-changed.
+- ansible-galaxy - Fix using the '--ignore-certs' option when there is no server-specific configuration for the Galaxy server.
+- ansible-galaxy collection build - Ignore any existing ``MANIFEST.json`` and ``FILES.json`` in the root directory when building a collection.
+- ansible-test - Fix the ``import`` sanity test to work properly when Ansible's built-in vendoring support is in use.
+- ansible-test - Fix traceback in the ``validate-modules`` sanity test when testing an Ansible module without any callables.
+- ansible-test - Fix traceback when running from an install and delegating execution to a different Python interpreter.
+- ansible-test - Show an error message instead of a traceback when running outside of a supported directory.
+- ansible-test - Update help links to reference ``ansible-core`` instead of ``ansible``.
+- ansible-test - Update unit tests to use the ``--forked`` option instead of the deprecated ``--boxed`` option.
+- async - Improve performance of sending async callback events by never sending the full task through the queue (https://github.com/ansible/ansible/issues/76729)
+- default callback - Ensure we compare FQCN also in lockstep logic, to ensure using the FQCN of a strategy plugin triggers the correct behavior in the default callback plugin. (https://github.com/ansible/ansible/issues/76782)
+- hostname - Do not require SystemdStrategy subclasses for every distro (https://github.com/ansible/ansible/issues/76792)
+- include_vars, properly initialize variable as there is corner case in which it can end up referenced and not defined
+- ssh connection - properly quote controlpersist path given by user to avoid issues with spaces and other characters
+- ssh connection avoid parsing ssh cli debug lines as they can match expected output at high verbosities.
+- sudo become plugin, fix handling of non interactive flags, previous substitution was too naive
+- unarchive - Fix zip archive file listing that caused issues with content postprocessing (https://github.com/ansible/ansible/issues/76067).
+- yum - prevent storing unnecessary cache data by running `yum makecache fast` (https://github.com/ansible/ansible/issues/76336)
+
+v2.12.1
+=======
+
+Release Summary
+---------------
+
+| Release Date: 2021-12-06
+| `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__
+
+
+Minor Changes
+-------------
+
+- jinja2_native - keep same behavior on Python 3.10.
+
+Bugfixes
+--------
+
+- Ansible.ModuleUtils.LinkUtil - Ignore the ``LIB`` environment variable when loading the ``LinkUtil`` code
+- ansible-test - Automatic target requirements installation is now based on the target environment instead of the controller environment.
+- ansible-test - Fix Python real prefix detection when running in a ``venv`` virtual environment.
+- ansible-test - Fix installation and usage of ``pyyaml`` requirement for the ``import`` sanity test for collections.
+- ansible-test - Fix traceback in ``import`` sanity test on Python 2.7 when ``pip`` is not available.
+- ansible-test - Relocate constants to eliminate symlink.
+- ansible-test - Target integration test requirements are now correctly installed for target environments running on the controller.
+- ansible-test - Update the ``default`` containers to version 4.1.1, which includes the updated ``import`` sanity test requirements.
+- ansible-test - Use the legacy collection loader for ``import`` sanity tests on target-only Python versions.
+- set_fact/include_vars correctly handle delegation assignments within loops
+- setup - detect docker container with check for ./dockerenv or ./dockinit (https://github.com/ansible/ansible/pull/74349).
+- validate_argument_spec - Skip suboption validation if the top level option is an invalid type (https://github.com/ansible/ansible/issues/75612).
+
+v2.12.0
+=======
+
+Release Summary
+---------------
+
+| Release Date: 2021-11-05
+| `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__
+
+
+Major Changes
+-------------
+
+- Python Controller Requirement - Python 3.8 or newer is required for the control node (the machine that runs Ansible) (https://github.com/ansible/ansible/pull/74013)
+- ansible-test - All "cloud" plugins which use containers can now be used with all POSIX and Windows hosts. Previously the plugins did not work with Windows at all, and support for hosts created with the ``--remote`` option was inconsistent.
+- ansible-test - Collections can now specify controller and target specific integration test requirements and constraints. If provided, they take precedence over the previously available requirements and constraints files.
+- ansible-test - Integration tests run with the ``integration`` command can now be executed on two separate hosts instead of always running on the controller. The target host can be one provided by ``ansible-test`` or by the user, as long as it is accessible using SSH.
+- ansible-test - Most container features are now supported under Podman. Previously a symbolic link for ``docker`` pointing to ``podman`` was required.
+- ansible-test - New ``--controller`` and ``--target`` / ``--target-python`` options have been added to allow more control over test environments.
+- ansible-test - Python 3.8 - 3.10 are now required to run ``ansible-test``, thus matching the Ansible controller Python requirements. Older Python versions (2.6 - 2.7 and 3.5 - 3.10) can still be the target for relevant tests.
+- ansible-test - SSH port forwarding and redirection is now used exclusively to make container ports available on non-container hosts. When testing on POSIX systems this requires SSH login as root. Previously SSH port forwarding was combined with firewall rules or other port redirection methods, with some platforms being unsupported.
+- ansible-test - Sanity tests always run in isolated Python virtual environments specific to the requirements of each test. The environments are cached.
+- ansible-test - Sanity tests are now separated into two categories, controller and target. All tests except ``import`` and ``compile`` are controller tests. The controller tests always run using the same Python version used to run ``ansible-test``. The target tests use the Python version(s) specified by the user, or all available Python versions.
+- ansible-test - Sanity tests now use fully pinned requirements that are independent of each other and other test types.
+- ansible-test - Tests run with the ``centos6`` and ``default`` test containers now use a PyPI proxy container to access PyPI when Python 2.6 is used. This allows tests running under Python 2.6 to continue functioning even though PyPI is discontinuing support for non-SNI capable clients.
+- ansible-test - The ``future-import-boilerplate`` and ``metaclass-boilerplate`` sanity tests are limited to remote-only code. Additionally, they are skipped for collections which declare no support for Python 2.x.
+- ansible-test - The ``import`` and ``compile`` sanity tests limit remote-only Python version checks to remote-only code.
+- ansible-test - Unit tests for controller-only code now require Python 3.8 or later.
+- ansible-test - Version neutral sanity tests now require Python 3.8 or later.
+- junit callback - The ``junit_xml`` and ``ordereddict`` Python modules are no longer required to use the ``junit`` callback plugin.
+
+Minor Changes
+-------------
+
+- Add ``end_batch`` meta task.
+- Allow connection and become passwords to be set by file/executable script. Also document this was already the case for vault.
+- CLI - Remove ``__requires__`` attribute for ``pkg_resources``
+- Collections can define action_groups in ``meta/runtime.yml``.
+- Introduce a config option to enable/disable emitting warning about Jinja2 version being old for ``jinja2_native``. The option is on by default, only in CI it is off.
+- Make the code structure of ansible-doc's generic snippet feature more maintainable.
+- On RHEL 9, CentOS Stream 9 etc., use /usr/bin/python3 as the default interpreter; /usr/libexec/platform-python is just a backwards-compatibility symbolic link there.
+- PowerShell - Added support for optional module_util imports by scanning for ``-Optional`` at the end of the import declaration
+- Python 2.6 Target Support - Deprecate Python 2.6 for targets, requiring Python 2.7 or newer. ``ansible-core==2.13`` will drop support for Python 2.6. (https://github.com/ansible/ansible/pull/74165)
+- Task - Add a resolved_action attribute for Task objects to get the final resolved plugin.
+- Templar - remove ``_fail_on_lookup_errors`` and ``_fail_on_filter_errors`` instance variables that were never used. (https://github.com/ansible/ansible/pull/73785)
+- The AnsiballZ Python wrapper now changes the working directory to ``~`` or ``/`` if the current one is not accessible. This allows become to drop privileges on macOS when using pipelining.
+- Update test container ansible-core-test-container to version 3.6.0
+- Update test container ansible-core-test-container to version 3.7.0
+- Update test container default-test-container to version 3.6.0
+- Update test container default-test-container to version 3.7.0
+- Update vendored copy of ``six`` to 1.16.0 to eliminate warnings for deprecated python loader methods in Python 3.10+ (https://github.com/ansible/ansible/issues/74659)
+- Update vendored copy of distro to 1.6.0
+- Vendor ``distutils.version`` due to it's deprecation in Python 3.10 and impending removal in Python 3.12 (https://github.com/ansible/ansible/issues/74599)
+- YAML parsing - Create common utils for loading and dumping YAML that prefer the C extensions if available
+- ``include_role`` - Allow use of ``omit`` in the ``from_*`` arguments (https://github.com/ansible/ansible/issues/66349)
+- ``uri``/``get_url`` - Expose ``unredirected_headers`` to modules to allow user control
+- `ansible.plugins.callback.CallbackBase.host_label()` has been factored out as a static method (https://github.com/ansible/ansible/pull/73814).
+- action_groups can include actions from other groups by using the special ``metadata`` dictionary field.
+- add a quick short circuit when checking if a string is a template to improve performance on large strings (https://github.com/ansible/ansible/issues/74336)
+- add host label to retry print statements
+- added new function to module utils to choose best possible locale.
+- adds the ``undef`` keyword to the templating environment. This allows for directly creating Undefined values in templates. It is most useful for providing a hint for variables which must be overridden.
+- ansbile-doc now also shows snippets for inventory and lookup, adding to existing modules.
+- ansible adhoc, clarified the help to some options, also added some comments to code.
+- ansible-cli - remove unnecessary trailing space in ``ansible --version`` (https://github.com/ansible/ansible/issues/74875).
+- ansible-config can now list and dump for specific documentable plugins by specifying them in the command line
+- ansible-config has new 'init' option to create, highly commented, example configurations as ini (ansible.cfg), environment variables (shell) or Ansible variable files (YAML)
+- ansible-config now supports displaying plugin configuration info.
+- ansible-doc - ``version_added`` in ``attributes`` now comes with ``version_added_collection`` (https://github.com/ansible/ansible/pull/74602).
+- ansible-doc - show ``version_added`` for the plugin/module itself in text output, and improve ``version_added`` formatting (https://github.com/ansible/ansible/pull/73602).
+- ansible-doc now supports 'attributes' for plugins as per proposal.
+- ansible-doc pretty cli options output.
+- ansible-doc, improve handling of rstisms, try to make the display more meaningfull for the terminal users.
+- ansible-galaxy - Allow specification of client_id override value for Keycloak Token (https://github.com/ansible/ansible/issues/75593).
+- ansible-galaxy - Allow validate_certs to be configured for individual Galaxy servers (https://github.com/ansible/ansible/issues/75677).
+- ansible-galaxy - Installing a collection from a git repository without specifying a version (or using the version ``HEAD``) will clone the repository using --depth=1.
+- ansible-galaxy - Non-HTTP exceptions from Galaxy servers are now a warning and only fatal if the collection to download|install|verify is not available from any of the servers (https://github.com/ansible/ansible/issues/75443).
+- ansible-test - A new ``base`` test container is available. It is similar to the ``default`` test container, but contains no pre-installed Python packages other than ``pip`` and its dependencies.
+- ansible-test - Add RHEL 8.4 as a remote.
+- ansible-test - Add ``--prime-venvs`` option to create virtual environments without running tests.
+- ansible-test - Add constraint for ``decorator`` for Python versions prior to 3.5.
+- ansible-test - Add support for Windows Server 2022.
+- ansible-test - Add support for an ansible-test configuration file in collections under ``tests/config.yml``.
+- ansible-test - Add support for testing with Python 3.10.
+- ansible-test - Added a ``--prime-containers`` option to support downloading containers without running tests.
+- ansible-test - Adding DigitalOcean cloud support to ansible-test (https://github.com/ansible/ansible/pull/74222).
+- ansible-test - All "cloud" plugins have been refactored for more consistency. For those that use docker containers, management of the containers has been standardized.
+- ansible-test - All "cloud" plugins now use fixed hostnames and ports in tests. Previously some tests used IP addresses and/or randomly assigned ports.
+- ansible-test - Changes made to the ``hosts`` file on test systems are now done using an Ansible playbook for both POSIX and Windows systems. Changes are applied before a test target runs and are reverted after the test target finishes.
+- ansible-test - Clean up code in the cloud plugins.
+- ansible-test - Collections can declare their remote-only code (modules/module_utils and related tests) as controller-only.
+- ansible-test - Collections can limit the Python versions used for testing their remote-only code (modules/module_utils and related tests).
+- ansible-test - Command line help has been updated to hide the ``--remote`` option (and related options) when the user lacks an API key to use the feature.
+- ansible-test - Constraints provided by ``ansible-test`` for Python package installs have been reduced.
+- ansible-test - Default settings are now applied to unknown versions of known ``--remote`` platforms.
+- ansible-test - Distribution specific test containers have been updated to version 3.0.0.
+- ansible-test - Environment checking (``pip``, ``python``, ``~/.ssh/known_hosts``, etc.) is no longer performed when running integration tests.
+- ansible-test - Environment variables exposed by "cloud" plugins are now available to the controller for role based tests. Previously only script based tests had access to the exposed environment variables.
+- ansible-test - Fedora 32 and 33 (``fedora32`` and ``fedora33``) containers have been updated and now allow for ssh in more container environments.
+- ansible-test - Fedora 34 (``fedora34``) container has been added.
+- ansible-test - Installation of ``cryptography`` no longer occurs when it is already installed. This avoids downgrading existing OS packages.
+- ansible-test - Minor code cleanup.
+- ansible-test - More efficient string splitting.
+- ansible-test - Most scripts used internally by ``ansible-test`` no longer have a shebang or the executable bit set.
+- ansible-test - Move code from ``_data`` directory to ``_util`` directory.
+- ansible-test - Relocate change classification code.
+- ansible-test - Remove CI provider support for Shippable, now that the service has been discontinued.
+- ansible-test - Remove check for legacy ``core`` and ``extras`` directories.
+- ansible-test - Remove deprecated container ``fedora32``.
+- ansible-test - Remove deprecated remote platforms ``freebsd/11.4`` and ``rhel/8.3```.
+- ansible-test - Removed the warning filter for ``PyYAML`` in the ``import`` sanity test.
+- ansible-test - Removed unused pip constraints. Collections may need to add their own constraints if they depended on any which were removed.
+- ansible-test - Reorganize code for individual commands.
+- ansible-test - Reorganize integration test implementation by command.
+- ansible-test - Rewrite the ``compile`` sanity test to improve error handling and support Python 3.10.
+- ansible-test - Sanity test warnings relating to Python version support have been improved.
+- ansible-test - Set minimum version constraints for ``pytest``.
+- ansible-test - Split out shell command implementation.
+- ansible-test - The "injector" scripts are now generated at runtime to avoid issues with symlinks and shebangs.
+- ansible-test - The HTTP Tester can now be used without the ``--docker`` or `--remote`` options. It still requires use of the ``docker`` command to run the container.
+- ansible-test - The HTTP Tester has been converted to a "cloud" plugin and can now be requested using the ``cloud/httptester`` alias. The original ``needs/httptester`` alias is still supported for backwards compatibility.
+- ansible-test - The ``--docker-keep-git`` option (used only for testing ansible-core) has been renamed to ``--keep-git``.
+- ansible-test - The ``--python`` option can be used without another delegation option such as the ``--venv`` or ``--docker`` options.
+- ansible-test - The ``ansible-test coverage`` commands ``combine``, ``report``, ``html`` and ``xml`` now support delegation.
+- ansible-test - The ``default`` test container has been updated to version 3.4.0 and now uses Python 3.9 by default instead of Python 3.6.
+- ansible-test - The ``docker run`` option ``--link`` is no longer used to connect test containers. As a result, changes are made to the ``/etc/hosts`` file as needed on all test containers. Previously containers which were used with the ``--link`` option did not require changes to the ``/etc/hosts`` file.
+- ansible-test - The ``import`` sanity test now requires that Ansible modules guard instantiation of ``AnsibleModule`` with a ``if __name__ == '__main__'`` conditional, or equivalent logic.
+- ansible-test - The ``import`` sanity test now requires that non-modules do not instantiate ``AnsibleModule`` on import.
+- ansible-test - The ``validate-modules`` sanity test codes ``ansible-deprecated-module`` and ``collection-deprecated-module`` have been added.
+- ansible-test - The ``validate-modules`` sanity test codes ``last-line-main-call``, ``missing-if-name-main`` and ``missing-main-call`` have been removed.
+- ansible-test - The ``validate-modules`` sanity test no longer enforces the ``missing-if-name-main``, ``last-line-main-call`` or ``missing-main-call`` checks on non-deleted Ansible modules. Modules are still required to instantiate ``AnsibleModule`` when ``__name__ == '__main__'``.
+- ansible-test - Unit tests are now run in separate contexts (``controller``, ``modules``, ``module_utils``), each using separate invocations of ``pytest``.
+- ansible-test - Unit tests other than ``modules`` and ``module_utils`` are now run only on Python versions supported by the controller (Python 3.8+).
+- ansible-test - Update ``typed-ast`` constraint to version 1.4.3 for compatibility with Python 3.10.
+- ansible-test - Update distribution test containers from version 2.0.1 to 2.0.2.
+- ansible-test - Update the Ansible Core and Ansible Collection default test containers to 3.2.0 and 3.2.2 respectively.
+- ansible-test - Update the ``base`` and ``default`` containers from Python 3.10.0rc2 to 3.10.0.
+- ansible-test - Update the ``import`` sanity test to avoid a new warning in Python 3.10.
+- ansible-test - Update the ``runtime-metadata`` sanity test to handle a new warning on Python 3.10.
+- ansible-test - Updated the ``default`` containers to version 4.0.1.
+- ansible-test - Updated the help message for failed tests in the ``azure`` test plugin.
+- ansible-test - Upgrade ``pylint`` to version 2.9.3 and update its dependencies to the latest versions as well.
+- ansible-test - Using an unknown ``--docker`` or ``--remote`` environment now requires specifying a Python version.
+- ansible-test - add freebsd/13.0 as a remote option.
+- ansible-test - aws creates and exposes a new tiny_prefix variable to provide a shorter prefix for the AWS tests.
+- ansible-test - display recent ``ssh`` debug logs after connection failures (https://github.com/ansible/ansible/pull/75374)
+- ansible-test - validate-modules now properly checks ``attributes`` for plugins (https://github.com/ansible/ansible/pull/74602).
+- ansible-test - virtualenv-isolated.sh is no longer provided. Prefer virtualenv.sh in its place.
+- ansible-test validate-modules - enforce that ``_info`` and ``_facts`` modules set ``supports_check_mode=True`` (https://github.com/ansible/ansible/pull/75324).
+- ansible-vault - remove support for ``PyCrypto`` (https://github.com/ansible/ansible/issues/72646)
+- apt - added an ``allow_downgrade`` option to enable safe downgrade of packages without using ``force`` which doesn't verify signatures (https://github.com/ansible/ansible/issues/29451, https://github.com/ansible/ansible/pull/74852).
+- apt, added a 'lock_timeout' to be more resilient when encountering the apt db already locked and handle it w/o haveing to rerun task.
+- async tasks - the use of the task-level ``ANSIBLE_ASYNC_DIR`` variable within ``environment:`` is no longer valid. Use the shell configuration variable ``async_dir`` instead.
+- async_wrapper, better reporting on timeout, slight refactor on reporting itself.
+- basic module_util - Clean up ``selinux`` compat import.
+- blockinfile - Remove unused code for Ansible 1.x.
+- cache base - More efficient string splitting.
+- callback API - implemented ``v2_runner_on_async_ok`` and ``v2_runner_on_async_failed`` callbacks (https://github.com/ansible/ansible/pull/74953).
+- cli scripts - remove trailing blank space in help after newline when outputting.
+- collection - match skip message as per role installation.
+- command - update the user warning message to point out command name (https://github.com/ansible/ansible/pull/74475).
+- config lookup now can handle plugin settings.
+- config, default site for ansible-core is now under /ansbile-core/.
+- connection base - Avoid using deprecated ``@abstractproperty`` decorator.
+- constructed - a new options ``trailing_separator`` and ``default_value`` to deal with key's value empty on keyed group.
+- cron - ``name`` is now a required parameter always
+- cron - ``reboot`` parameter has been dropped in favor of ``special_time: reboot``
+- cron, removed previously deprecated 'reboot' and now requires either 'name' as unique identifier.
+- default callback plugin - displays output for ``v2_runner_on_async_ok`` and ``v2_runner_on_async_failed`` callbacks.
+- deprecate ``_remote_checksum()`` and remove all internal uses (https://github.com/ansible/ansible/pull/74848)
+- dnf - Add ``cacheonly`` option (https://github.com/ansible/ansible/issues/69397).
+- dnf - allow for ``download_only`` to be run without root privileges (https://github.com/ansible/ansible/issues/75530)
+- encrypt - add new parameter ``ident`` to specify version of BCrypt algorithm to be used (https://github.com/ansible/ansible/issues/74571).
+- fact cache - Remove deprecated backwards compatibility shim for the FactCache `update` method to accept multiple arguments.
+- fact cache - Remove the deprecated location for FactCache. Import FactCache from `ansible.vars.fact_cache` instead.
+- facts - add fiber channel facts for HP-UX (https://github.com/ansible/ansible/pull/57406)
+- galaxy - support role artifact download from API response ``download_url`` location (https://github.com/ansible/ansible/issues/73103).
+- get_distribution - ``lib.ansible.module_utils.common.sys_info.get_distribution`` now returns distribution information for all platforms not just Linux (https://github.com/ansible/ansible/issues/17587)
+- get_distribution_version - ``lib.ansible.module_utils.common.sys_info.get_distribution_version`` now returns the version for all platfroms not just Linux (https://github.com/ansible/ansible/issues/17587)
+- git - Add ``accept_newhostkey`` option (https://github.com/ansible/ansible/issues/69846).
+- hostname - add support RedOS (https://github.com/ansible/ansible/issues/74779).
+- import_role - Template tasks_from, vars_from, defaults_from, and handlers_from with --extra-vars (https://github.com/ansible/ansible/issues/69097).
+- include_vars - add ``hash_behaviour`` option (https://github.com/ansible/ansible/pull/72944).
+- ini - added new parameter ``allow_no_value`` to ini lookup plugin (https://github.com/ansible/ansible/issues/50594).
+- ini lookup - add case sensitive option (https://github.com/ansible/ansible/issues/74601)
+- interpreter discovery - allow the default list of ``INTERPRETER_PYTHON_FALLBACK`` to be changed using a variable
+- interpreter discovery - prefer Python 3 over Python 2
+- inventory plugins - Remove the deprecated cache interface. Set top level keys in the inventory plugin's `_cache` attribute (a dictionary) instead.
+- jinja2_native - short-circuit ``ast.literal_eval`` for non-string values
+- module_utils distro - when a 'distro' package/module is in PYTHONPATH but isn't the real 'distro' package/module that we expect, gracefully fall back to our own bundled distro.
+- modules - add Anolis distro in hostname.py. project website https://openanolis.org/
+- move all builtin modules to use the best possible locale function instead of hardcoding 'C'.
+- password - add new parameter ``ident`` to specify version of BCrypt algorithm to be used (https://github.com/ansible/ansible/issues/74571).
+- password - add new parameter ``seed`` in lookup plugin (https://github.com/ansible/ansible/pull/69775).
+- password_hash uses passlib default if option isn't set
+- playbook - Error if a playbook is an empty list instead of just skipping
+- playbook - Error if using ``include`` instead of ``import_playbook``
+- replaced examples/ansible.cfg with instructions on how to generate an up to date copy.
+- service - add description how service module works internally (https://github.com/ansible/ansible/issues/74507).
+- service_facts now handles more states/statuses from systemd and in a more reliable way (failed, not-found, masked).
+- setup - add ``epoch_int`` option to date_time facts (https://github.com/ansible/ansible/pull/73822).
+- ssh - added pkcs11 support by adding the pkcs11_provider option in the ssh connection module. (https://www.github.com/ansible/ansible/pull/32829)
+- ssh connection, can not configure ssh_transfer_method with a variable.
+- ssh connection, ssh_transfer_method is now configurable via variable.
+- subelements lookup - Use generator in instance type check.
+- tempfile - Remove unnecessary conditional for creating a temporary directory.
+- template - Add comment attributes (``comment_start_string`` and ``comment_end_string``)
+- unicode utils - Fix ``__all__`` which was incorrectly declared as a string instead of a tuple.
+- user - Add ``umask`` option (https://github.com/ansible/ansible/issues/40359).
+- user module - Remove unused code.
+- validation testcases for check_* APIs (https://github.com/ansible/ansible/issues/55994).
+- winrm - Allow explicit environment variables to be passed through to the ``kinit`` call for Kerberos authentication
+- yaml dumper - YAML representer for AnsibleUndefined (https://github.com/ansible/ansible/issues/75072).
+- yum - Add ``cacheonly`` option (https://github.com/ansible/ansible/issues/69397).
+
+Breaking Changes / Porting Guide
+--------------------------------
+
+- Action, module, and group names in module_defaults must be static values. Their values can still be templates.
+- Fully qualified 'ansible.legacy' plugin names are not included implicitly in action_groups.
+- Unresolvable groups, action plugins, and modules in module_defaults are an error.
+- ansible-test - Automatic installation of requirements for "cloud" test plugins no longer occurs. The affected test plugins are ``aws``, ``azure``, ``cs``, ``hcloud``, ``nios``, ``opennebula``, ``openshift`` and ``vcenter``. Collections should instead use one of the supported integration test requirements files, such as the ``tests/integration/requirements.txt`` file.
+- ansible-test - The HTTP Tester is no longer available with the ``ansible-test shell`` command. Only the ``integration`` and ``windows-integration`` commands provide HTTP Tester.
+- ansible-test - The ``--disable-httptester`` option is no longer available. The HTTP Tester is no longer optional for tests that specify it.
+- ansible-test - The ``--httptester`` option is no longer available. To override the container used for HTTP Tester tests, set the ``ANSIBLE_HTTP_TEST_CONTAINER`` environment variable instead.
+- ansible-test - Unit tests for ``modules`` and ``module_utils`` are now limited to importing only ``ansible.module_utils`` from the ``ansible`` module.
+- conditionals - ``when`` conditionals no longer automatically parse string booleans such as ``"true"`` and ``"false"`` into actual booleans. Any non-empty string is now considered true. The ``CONDITIONAL_BARE_VARS`` configuration variable no longer has any effect.
+- hostname - Drops any remaining support for Python 2.4 by using ``with open()`` to simplify exception handling code which leaked file handles in several spots
+- hostname - On FreeBSD, the string ``temporarystub`` no longer gets written to the hostname file in the get methods (and in check_mode). As a result, the default hostname will now appear as ``''`` (empty string) instead of ``temporarystub`` for consistency with other strategies. This means the ``before`` result will be different.
+- hostname - On OpenRC systems and Solaris, the ``before`` value will now be ``''`` (empty string) if the permanent hostname file does not exist, for consistency with other strategies.
+- intersect, difference, symmetric_difference, union filters - the default behavior is now to be case-sensitive (https://github.com/ansible/ansible/issues/74255)
+- unique filter - the default behavior is now to fail if Jinja2's filter fails and explicit ``case_sensitive=False`` as the Ansible's fallback is case-sensitive (https://github.com/ansible/ansible/pull/74256)
+
+Deprecated Features
+-------------------
+
+- ansible-test - The ``--docker-no-pull`` option is deprecated and has no effect.
+- ansible-test - The ``--no-pip-check`` option is deprecated and has no effect.
+- include action is deprecated in favor of include_tasks, import_tasks and import_playbook.
+- module_utils' FileLock is scheduled to be removed, it is not used due to its unreliable nature.
+
+Removed Features (previously deprecated)
+----------------------------------------
+
+- The built-in module_util ``ansible.module_utils.common.removed`` was previously deprecated and has been removed.
+- connections, removed password check stubs that had been moved to become plugins.
+- task, inline parameters being auto coerced into variables has been removed.
+
+Security Fixes
+--------------
+
+- Do not include params in exception when a call to ``set_options`` fails. Additionally, block the exception that is returned from being displayed to stdout. (CVE-2021-3620)
+- templating engine fix for not preserving usnafe status when trying to preserve newlines. CVE-2021-3583
+
+Bugfixes
+--------
+
+- Add RockyLinux to fact gathering (https://github.com/ansible/ansible/pull/74530).
+- Add unicode support to ``ansible-inventory`` CLI (https://github.com/ansible/ansible/issues/57378)
+- Add yaml representer for VarsWithSources (https://github.com/ansible/ansible/pull/68525).
+- Added page describing terminal plugins to docsite
+- AnsibleModule.set_mode_if_different - don't check file existence when check_mode is activated (https://github.com/ansible/ansible/issues/61185).
+- Apply ``display_failed_stderr`` callback option on loop item results. (https://github.com/ansible/ansible/issues/74864)
+- Binary GnuPG keys downloaded via URLs by the 'ansible.builtin.apt_key' module were corrupted so 'gpg' could not import them (https://github.com/ansible/ansible/issues/74424).
+- Ensure end_play ends play, not batch (https://github.com/ansible/ansible/issues/73971)
+- Ensure we get full path for extra vars into cliargs to avoid realpath issues after initial load.
+- Fix ``keys()`` implementation of ``BaseFileCacheModule`` to strip the prefix from the key and only return keys that share the same prefix as the cache.
+- Fix ``when`` evaluation on Native Jinja and Python 3.10.
+- Fix templating task action with host-specific vars (https://github.com/ansible/ansible/issues/75568)
+- Fully qualified 'ansible.legacy' and 'ansible.builtin' plugin names work in conjunction with module_defaults.
+- Give a warning instead of an error if a handler name contains undefined variables and has no listen topics (https://github.com/ansible/ansible/issues/58841).
+- Improve resilience of ``ansible-galaxy collection`` by increasing the page size to make fewer requests overall and retrying queries with a jittered exponential backoff when rate limiting HTTP codes (520 and 429) occur. (https://github.com/ansible/ansible/issues/74191)
+- Jinja2 globals should be accessible even when importing a template without the context (https://github.com/ansible/ansible/issues/75371)
+- PlayContext - Remove deprecated ``make_become_cmd`` (https://github.com/ansible/ansible/issues/74136)
+- PowerShell - Ignore the ``LIB`` environment variable when compiling C# Ansible code
+- Prevent ``ansible_failed_task`` from further templating (https://github.com/ansible/ansible/issues/74036)
+- Remove 'default' from ssh plugin as we want to rely on default from ssh itself or ssh/config.
+- Replace usage of private dnf.Base() attribute by future dnf API
+- Save unreachable hosts between plays by adding them to the PlayIterator's _play._removed_hosts (https://github.com/ansible/ansible/issues/66945).
+- Solaris - correct version check in svcadm_supports_sync (https://github.com/ansible/ansible/pull/73860).
+- Task depth - Prevent exception when the task depth exceeds Pythons recursion depth (https://github.com/ansible/ansible/issues/73996)
+- Templating - Ensure we catch exceptions when calling ``.filters()`` or ``.tests()`` on their respective plugins and properly error, instead of aborting which results in no filters being added to the jinja2 environment (https://github.com/ansible/ansible/pull/74127)
+- The ``apt_key`` module did not properly handle GnuPG errors (https://github.com/ansible/ansible/issues/74477)
+- The error message about the failure to import a ```gpg`` key by the ``apt_key`` module was incorrect (https://github.com/ansible/ansible/issues/74423).
+- Update network user guide to explain use of cli_parse and validate plugins.
+- Variable Manager - Only check if ``play.hosts`` is a template when the play hasn't been finalized (https://github.com/ansible/ansible/issues/73926)
+- WorkerProcess - Python 3.5 fix for workaround for stdout deadlock in multiprocessing shutdown to avoid process hangs. (https://github.com/ansible/ansible/issues/74149)
+- ``AnsibleModule.run_command`` - Address thread safety issues, concerning mutating the environment, current working directory, and umask. (https://github.com/ansible/ansible/issues/74783)
+- ``failed_when``/``changed_when`` - Catch templating errors to prevent masking of module output (https://github.com/ansible/ansible/issues/37187)
+- ``heuristic_log_sanitize`` - Return the full string if there is no password (https://github.com/ansible/ansible/issues/75542)
+- ``pip`` now uses the ``pip`` Python module installed for the Ansible module's Python interpreter, if available, unless ``executable`` or ``virtualenv`` were specified.
+- advanced_host_list inventory plugin - Fixed variable referenced before assignment when hostname/range could not be parsed.
+- ansiballz - avoid treating path to site_packages as regex; escape it. This prevents a crash when ansible is installed to, or running from, an oddly named directory like ``ansi[ble``
+- ansible-doc - in text output, do not show empty ``version_added_collection`` values (https://github.com/ansible/ansible/pull/74999).
+- ansible-doc can now dump kewyords with --metadata-dump (still just for internal use)
+- ansible-doc, fix output for internal metadata dump option
+- ansible-doc, make inventory plugin selection for snippets generic and not a hardcoded list
+- ansible-galaxy - Fix a bug with build_ignore when installing collections from source (https://github.com/ansible/ansible/issues/75528).
+- ansible-galaxy - Fix handling HTTP exceptions from Galaxy servers. Continue to the next server in the list until the collection is found.
+- ansible-galaxy - Improve error message from dependency resolution when a candidate has inconsistent requirements (https://github.com/ansible/ansible/issues/75139).
+- ansible-inventory - handle an exception while parsing inventory in toml format (https://github.com/ansible/ansible/issues/74404).
+- ansible-playbook, more robust handling of --list-hosts and undefined vars in hosts keyword.
+- ansible-pull - update documentation for ``--directory`` option to clarify path must be absolute.
+- ansible-pull, restore other options to use as repo other than git.
+- ansible-test - Add constraint for ``pyspnego>=0.1.6`` for Python 3.10 - https://github.com/ansible/ansible/pull/74612
+- ansible-test - Avoid publishing the port used by the ``pypi-test-container`` since it is only accessed by other containers. This avoids issues when trying to run tests in parallel on a single host.
+- ansible-test - Failure to download test results from a remote host no longer hide test failures. If a download failure occurs after tests fail, a warning will be issued instead.
+- ansible-test - Fix docker container IP address detection. The ``bridge`` network is no longer assumed to be the default.
+- ansible-test - Fix path to inventory file for ``windows-integration`` and ``network-integration`` commands for collections.
+- ansible-test - Fix traceback when generating coverage reports and no coverage directory exists.
+- ansible-test - Random port selection is no longer handled by ``ansible-test``, avoiding possible port conflicts. Previously ``ansible-test`` would, under some circumstances, use one host's available ports to determine those of another host.
+- ansible-test - Running tests in a single test run with multiple "cloud" plugins no longer results in port conflicts. Previously two or more containers with overlapping ports could not be used in the same test run.
+- ansible-test - Tab completion after options like ``--docker`` which accept an optional argument will no longer provide incorrect completions.
+- ansible-test - The ``--python`` and ``--venv`` options are no longer ignored by some commands, such as ``coverage``.
+- ansible-test - The ``docker inspect`` command is now used to check for existing images instead of the ``docker images`` command. This resolves an issue where a ``docker pull`` would be unnecessarily executed for an image referenced by checksum.
+- ansible-test - Update distribution test containers to version 3.1.0.
+- ansible-test - Use ``--strict`` for ``pytest`` on Python 2.6 since ``--strict-markers`` is not available.
+- ansible-test - Use documented API to retrieve build information from Azure Pipelines.
+- ansible-test - Use pwsh to generate correct coverage line counts for stub files to get a more accurate coverage result
+- ansible-test - Use the correct variable to reference the client's SSH key when generating inventory.
+- ansible-test - add packaging python module to ``ansible-doc`` sanity test requirements.
+- ansible-test - allow the same listening port on all container interfaces
+- ansible-test - ensure the correct unit test target is given when the ``__init__.py`` file is modified inside the connection plugins directory
+- ansible-test - make the ``a/`` and ``b/`` prefixes an optional match since these can be turned off with the ``diff.noprefix`` setting in ``git``
+- ansible-test - restrict ``packaging`` to ``< 21.0`` for Python ``< 3.6`` (https://github.com/ansible/ansible/pull/75186).
+- ansible-test pslint - Fix error when encountering validation results that are highly nested - https://github.com/ansible/ansible/issues/74151
+- ansible-test validate-modules - EXAMPLES will no longer be marked as invalid YAML when it uses Ansible-specific YAML tags (https://github.com/ansible/ansible/pull/74384).
+- ansible-test validate-modules - correctly validate positional parameters to ``AnsibleModules`` (https://github.com/ansible/ansible/pull/75332).
+- ansible.builtin.cron - Keep non-empty crontabs, when removing cron jobs (https://github.com/ansible/ansible/pull/74497).
+- ansible.utils.encrypt now handles missing or unusable 'crypt' library.
+- ansible_test - add constraint for ``MarkupSafe`` (https://github.com/ansible/ansible/pull/74666)
+- apt_key - set --recv argument as last one in apt-key command when using env var HTTP_PROXY (https://github.com/ansible/ansible/issues/74946)
+- arg_spec - remove unused imports
+- async_status, ensure we always get documented returns
+- async_status, resurrected module to deprecate for those that were invoking it directly.
+- basic - skip over module parameters which are used in ``journal.send`` API call (https://github.com/ansible/ansible/issues/71343).
+- become - fix a regression on Solaris where chmod can return 5 which we interpret as auth failure and stop trying become tmpdir permission fallbacks
+- become - work around setfacl not existing on modern Solaris (and possibly failing on some filesystems even when it does exist)
+- callbacks, restore displaying delegation to host as host label.
+- cli defaults for ssh args set to None as '' was bypassing normal default.
+- command - remove unreachable code path when trying to convert the value for ``chdir`` to bytes (https://github.com/ansible/ansible/pull/75036)
+- command module, clarify order of remove/creates checks.
+- command module, correctly handles chdir to symlinks.
+- command module, move to standarized messages in 'msg' vs abusing 'stdout'.
+- command module, now all options work in ad-hoc execution.
+- command module, now always returns what we documented as 'returns always'.
+- config - use ``callbacks_enabled`` instead ``callback_enabled`` in a deprecated message (https://github.com/ansible/ansible/issues/70028).
+- config lookup, can also handle collection plugins now
+- config, ensure 'quoted' lists from ini or env do not take the quotes literally as part of the list item.
+- connection ssh, no ssh_args cli option, so removed doc entry.
+- constants, internal _deprecated function always requires version.
+- correct doc links for become on warnings over world readable settings.
+- correctly use world readable setting since old constant is not 'settable' anymore.
+- dnf - align the return value of the list argument with the ``yum`` module (https://github.com/ansible/ansible/issues/75483)
+- dnf - properly capture transaction error (https://github.com/ansible/ansible/issues/72651)
+- dnf - refactor code to use `dnf whatprovides` API (https://github.com/ansible/ansible/issues/73503).
+- dnf - support non-english environments (https://github.com/ansible/ansible/issues/75021)
+- dnf module - Use all components of a package name to determine if it's installed (https://github.com/ansible/ansible/issues/75311).
+- do not trigger interpreter discovery in the forced_local module path as they should use the ansible playbook python unless otherwise configured.
+- facts - detect homebrew installed at /opt/homebrew/bin/brew
+- facts, service_mgr, handle issues if ps command fails or returns empty.
+- filter plugins - patch new versions of Jinja2 to prevent warnings/errors on renamed filter decorators (https://github.com/ansible/ansible/issues/74667)
+- find - fix a bug where ``size`` argument was ignored for regular files with ``file_type`` of ``any``.
+- find action, correctly convert path to text when warning about skiping.
+- find does not ignore errors from os.walk anymore and issues warnings as expected.
+- gather_facts, improved message on timeout.
+- gather_facts, package, service - fix using module_defaults for the modules in addition to the action plugins. (https://github.com/ansible/ansible/issues/72918)
+- get_bin_path, clarify with quotes what the missing required executable is.
+- get_url - Fixed checksum validation for binary files (leading asterisk) in checksum files (https://github.com/ansible/ansible/pull/74502).
+- getent, fix return data for when there are multiple results for the same key
+- git - Fix git path used when .git file is present (https://github.com/ansible/ansible/issues/75608).
+- host_group_vars vars plugin fixed ini entry, section and key were reversed.
+- hostname - Add Rocky Linux support
+- hostname - No longer modifies system files in get_* methods and therefore when consulted in check_mode (https://github.com/ansible/ansible/issues/66432)
+- include - Remove deprecated ``static`` argument for ``include`` (https://github.com/ansible/ansible/issues/74135)
+- includes - Remove the deprecated ability to specify ``tags`` as ``vars`` on includes (https://github.com/ansible/ansible/issues/74144)
+- ini lookup - better error on mixed/bad parameters
+- ini lookup - handle errors for duplicate keys and missing sections (https://github.com/ansible/ansible/issues/74601)
+- interpreter discovery - Debian 8 and lower will avoid unsupported Python3 version in interpreter discovery
+- interpreter discovery is now handling special (ansible_network_os) cases in less noisy ways.
+- interpreter_discovery - hide warning 'No python interpreters...' when ANSIBLE_PYTHON_INTERPRETER=auto_silent (https://github.com/ansible/ansible/issues/74274).
+- module_common - handle exception when multiple workers try to create the cache directory
+- module_defaults - Fix action defaults for legacy actions/modules (https://github.com/ansible/ansible/issues/75279).
+- module_utils - detect symlinked init systems, even if unable to read /proc/1/comm (https://github.com/ansible/ansible/issues/74866).
+- netconf - catch and handle exception to prevent stack trace when running in FIPS mode
+- network module_utils - fix bug where ``to_bits()`` returned the ``str`` type instead of a useful value.
+- paramiko_ssh - mark connection as connected when ``_connect()`` is called (https://github.com/ansible/ansible/issues/74081)
+- password - Handle passlib wrapped algos bsd_nthash, django_argon2, django_bcrypt, ldap_bcrypt, ldap_bsdi_crypt, ldap_des_crypt, ldap_hex_md5, ldap_hex_sha1, ldap_md5_crypt, ldap_pbkdf2_sha1, ldap_pbkdf2_sha256, ldap_pbkdf2_sha512, ldap_sha1_crypt, ldap_sha256_crypt, ldap_sha512_crypt, roundup_plaintext (https://github.com/ansible/ansible/pull/75527).
+- pause - ensure control characters are always set to an appropriate value (https://github.com/ansible/ansible/issues/73264)
+- pkg_mgr.py - Lower the priority of rpm-ostree detection to avoid false positives on systems not using it as the main package manager (https://github.com/ansible/ansible/issues/74578)
+- play - validate the ``hosts`` entry in a play (https://github.com/ansible/ansible/issues/65386)
+- playbook loaded from collection subdir now does not ignore subdirs.
+- plugin config now allows list type options to have multiple valid choices (#74225).
+- psrp - Always cleanup the last run pipeline if a second pipeline is invoked to avoid violating any resource limits.
+- psrp - Fix error when resetting a connection that was initialised but not connected - (https://github.com/ansible/ansible/issues/74092).
+- psrp - Try to clean up any server-side resources when resetting a connection.
+- recursive_diff - handle condition when parameters are not dict (https://github.com/ansible/ansible/issues/56249).
+- register - Ensure that ``register`` used on ``set_fact`` or ``include_vars`` does not automatically wrap the facts as unsafe. (https://github.com/ansible/ansible/issues/21088)
+- rekey_on_member - handle undefined positional arguments better.
+- remote tmpdir permissions - fix type error in macOS chmod ACL fallback (https://github.com/ansible/ansible/pull/74613).
+- replace - better handling of file operation exceptions (https://github.com/ansible/ansible/pull/74686).
+- roles - allow for role arg specs in new meta file (https://github.com/ansible/ansible/issues/74525).
+- roles - fix unexpected ``AttributeError`` when an empty ``argument_specs.yml`` is present (https://github.com/ansible/ansible/pull/75604).
+- roles - make sure argspec validation task is tagged with ``always`` (https://github.com/ansible/ansible/pull/74994).
+- roles - make sure argspec validation task templates suboptions (https://github.com/ansible/ansible/issues/75070).
+- schema validation now uses dynamic range of versions for valid deprecation entries vs hardcoded out of date list.
+- script inventory plugin - Remove deprecated caching support (https://github.com/ansible/ansible/issues/74143)
+- sequence - fix error message so that unrecognized options to the plugin display correctly as a list and normalize error messages.
+- service - compare version without LooseVersion API (https://github.com/ansible/ansible/issues/74488).
+- set ssh host_key_checking defaults to True, restoring original behaviour (https://github.com/ansible/ansible/issues/75168)
+- setup module should now not truncate hpux interface names.
+- setup module, fix filter to adjust for missing ``ansible_`` prefix on query.
+- setup, while gathering linux hardware facts be more resilient to errors and try to return more info.
+- slurp - Fix error messages for unreadable files and directories(https://github.com/ansible/ansible/issues/67340).
+- slurp - handle error when ``path`` is a directory and not a file (https://github.com/ansible/ansible/pull/74930).
+- slurp - improve the logic in the error handling and remove ``os.stat()`` call (https://github.com/ansible/ansible/pull/75038)
+- ssh connection now correctly handle ssh_transfer_method and scp_if_ssh interactions.
+- ssh connection, fix interaction between trasnfer settings options.
+- ssh connection, use self.host which has the most up2date info instead of pc.remote_addr
+- ssh_connection - rename ``retries`` to ``reconnection_retries`` to avoid conflicts with task vars (https://github.com/ansible/ansible/issues/75142).
+- ssh_connection - set the default for ``reconnection_retries`` back to ``0`` (https://github.com/ansible/ansible/issues/75142).
+- subversion - fix stack trace when getting information about the repository (https://github.com/ansible/ansible/issues/36498)
+- system_service - use a context manager for file handling.
+- task_executor, Actions using AnsibleActionFail/Skip will now propagate 'results' if given
+- task_executor/ssh_connection - use the ``retries`` value from ``ssh_connection`` settings, not the default from the ``Task`` field attributes (https://github.com/ansible/ansible/issues/75142).
+- template - ensure Jinja2 overrides from template header are used (https://github.com/ansible/ansible/issues/75275)
+- unarchive - allow extracting archives that contain files which size exceeds free system memory (https://github.com/ansible/ansible/issues/73985).
+- unarchive - fail when zipinfo binary is not found in executable paths (https://github.com/ansible/ansible/issues/39029).
+- unarchive - move failure for missing binary to ``can_handle_archive()`` rather than ``__init__()``
+- uri - Fix traceback and provide error message when trying to use non-string or mapping for ``form-multipart`` body - https://github.com/ansible/ansible/issues/74276
+- urls - Fix logic in matching ``unredirected_headers`` to perform case insensitive matching
+- validate_argument_spec, correct variable precedence and merge method and add missing examples
+- variable manager, avoid sourcing delegated variables when no inventory hostname is present. This affects scenarios like syntax check and imports.
+- version test - improve error message when an empty version is provided
+- yum - Fixed typo in failure message (https://github.com/ansible/ansible/pull/72964).
+- yum - When upgrading, every architecture of a package is now included in the module results, instead of just one (https://github.com/ansible/ansible/issues/73284).
+- yum - fix ``yumstate`` return value when wildcards are used in the ``list`` argument (https://github.com/ansible/ansible/issues/74557)
+- yum - fix parsing of multiple subsequent empty lines from ``yum check-update`` output (https://github.com/ansible/ansible/issues/70949)
+- yum - yum action plugin changes to support 'use' as an alias of 'use_backend' (https://github.com/ansible/ansible/issues/70774).
+
+Known Issues
+------------
+
+- ansible-test - Tab completion anywhere other than the end of the command with the new composite options will provide incorrect results. See https://github.com/kislyuk/argcomplete/issues/351 for additional details.

changelogs/fragments/74127-bad-filter-2.yml

@@ -0,0 +1,5 @@
+bugfixes:
+- Templating - Ensure we catch exceptions when getting ``.filters`` and
+  ``.tests`` attributes on their respective plugins and properly error,
+  instead of aborting which results in no filters being added to the
+  jinja2 environment

changelogs/fragments/74349-improve-docker-detection.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - setup - detect docker container with check for ./dockerenv or ./dockinit (https://github.com/ansible/ansible/pull/74349).

changelogs/fragments/75635-fix-role-argspec-suboption-validation.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - validate_argument_spec - Skip suboption validation if the top level option is an invalid type (https://github.com/ansible/ansible/issues/75612).

changelogs/fragments/76069-fix-unarchive-file-listing-in-zip.yaml

@@ -0,0 +1,3 @@
+bugfixes:
+- unarchive - Fix zip archive file listing that caused issues with content
+  postprocessing (https://github.com/ansible/ansible/issues/76067).

changelogs/fragments/76336-yum-makecache-fast.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - yum - prevent storing unnecessary cache data by running `yum makecache fast` (https://github.com/ansible/ansible/issues/76336)

changelogs/fragments/76379-set-finalize-on-new-env.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - "``Templar.copy_with_new_env`` - set the ``finalize`` method of the new ``Templar`` object for the new environment (https://github.com/ansible/ansible/issues/76379)"

changelogs/fragments/76530-connection-password-file-tb-fix.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - Fix ``AttributeError`` when providing password file via ``--connection-password-file`` (https://github.com/ansible/ansible/issues/76530)

changelogs/fragments/76672-fix-end_play-multiple_plays.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - Fix ``end_play`` to end the current play only (https://github.com/ansible/ansible/issues/76672)

changelogs/fragments/76729-async-callback-perf.yml

@@ -0,0 +1,3 @@
+bugfixes:
+- async - Improve performance of sending async callback events by never sending the full task through the queue
+  (https://github.com/ansible/ansible/issues/76729)

changelogs/fragments/76735-ansible-galaxy-fix-ignore-certs.yaml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-galaxy - Fix using the '--ignore-certs' option when there is no server-specific configuration for the Galaxy server.

changelogs/fragments/76782-fqcn-compare-lockstep-strategies.yml

@@ -0,0 +1,4 @@
+bugfixes:
+- default callback - Ensure we compare FQCN also in lockstep logic, to ensure
+  using the FQCN of a strategy plugin triggers the correct behavior in the
+  default callback plugin. (https://github.com/ansible/ansible/issues/76782)

changelogs/fragments/76792-hostname-all-systemd.yml

@@ -0,0 +1,3 @@
+bugfixes:
+- hostname - Do not require SystemdStrategy subclasses for every distro
+  (https://github.com/ansible/ansible/issues/76792)

changelogs/fragments/ansible-test-default-base-containers-python-3.10.yaml

@@ -0,0 +1,2 @@
+minor_changes:
+  - ansible-test - Update the ``base`` and ``default`` containers from Python 3.10.0rc2 to 3.10.0.

changelogs/fragments/ansible-test-default-containers-4.1.1.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Update the ``default`` containers to version 4.1.1, which includes the updated ``import`` sanity test requirements.

changelogs/fragments/ansible-test-delegation-pythonpath.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Fix traceback when running from an install and delegating execution to a different Python interpreter.

changelogs/fragments/ansible-test-distro-containers-3.1.0.yaml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Update distribution test containers to version 3.1.0.

changelogs/fragments/ansible-test-inventory-path.yaml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Fix path to inventory file for ``windows-integration`` and ``network-integration`` commands for collections.

changelogs/fragments/ansible-test-inventory-ssh-key.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Use the correct variable to reference the client's SSH key when generating inventory.

changelogs/fragments/ansible-test-links.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Update help links to reference ``ansible-core`` instead of ``ansible``.

changelogs/fragments/ansible-test-pytest-forked.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Update unit tests to use the ``--forked`` option instead of the deprecated ``--boxed`` option.

changelogs/fragments/ansible-test-relocate-constants.yaml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Relocate constants to eliminate symlink.

changelogs/fragments/ansible-test-requirements-target.yaml

@@ -0,0 +1,3 @@
+bugfixes:
+  - ansible-test - Target integration test requirements are now correctly installed for target environments running on the controller.
+  - ansible-test - Automatic target requirements installation is now based on the target environment instead of the controller environment.

changelogs/fragments/ansible-test-sanity-import-loader.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Use the legacy collection loader for ``import`` sanity tests on target-only Python versions.

changelogs/fragments/ansible-test-sanity-import-no-pip.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Fix traceback in ``import`` sanity test on Python 2.7 when ``pip`` is not available.

changelogs/fragments/ansible-test-sanity-import.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Fix installation and usage of ``pyyaml`` requirement for the ``import`` sanity test for collections.

changelogs/fragments/ansible-test-sanity-vendoring.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Fix the ``import`` sanity test to work properly when Ansible's built-in vendoring support is in use.

changelogs/fragments/ansible-test-unsupported-directory-traceback.yaml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Show an error message instead of a traceback when running outside of a supported directory.

changelogs/fragments/ansible-test-validate-modules-no-callable.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Fix traceback in the ``validate-modules`` sanity test when testing an Ansible module without any callables.

changelogs/fragments/ansible-test-venv-real-prefix.yaml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-test - Fix Python real prefix detection when running in a ``venv`` virtual environment.

changelogs/fragments/avoid-set_options-leak.yaml

@@ -0,0 +1,5 @@
+---
+security_fixes:
+  - Do not include params in exception when a call to ``set_options`` fails.
+    Additionally, block the exception that is returned from being displayed to stdout.
+    (CVE-2021-3620)

changelogs/fragments/config_fix_terms.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ansible-config avoid showing _terms and _input when --only-changed.

changelogs/fragments/fix_sudo_flag_mangling.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - sudo become plugin, fix handling of non interactive flags, previous substitution was too naive

changelogs/fragments/galaxy-build-files-ignore.yml

@@ -0,0 +1,4 @@
+bugfixes:
+- >-
+  ansible-galaxy collection build - Ignore any existing ``MANIFEST.json`` and ``FILES.json`` in the root directory
+  when building a collection.

changelogs/fragments/include_vars_failed.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - include_vars, properly initialize variable as there is corner case in which it can end up referenced and not defined

changelogs/fragments/jinja2_native-literal_eval-py310.yml

@@ -0,0 +1,2 @@
+minor_changes:
+  - jinja2_native - keep same behavior on Python 3.10.

changelogs/fragments/pslint-sanity-warning.yml

@@ -0,0 +1,2 @@
+bugfixes:
+- ansible-test pslint - Fix error when encountering validation results that are highly nested - https://github.com/ansible/ansible/issues/74151

changelogs/fragments/set_fact_delegation.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - set_fact/include_vars correctly handle delegation assignments within loops

changelogs/fragments/ssh_debug_noparse.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ssh connection avoid parsing ssh cli debug lines as they can match expected output at high verbosities.

changelogs/fragments/ssh_quote_cp.yml

@@ -0,0 +1,2 @@
+bugfixes:
+  - ssh connection - properly quote controlpersist path given by user to avoid issues with spaces and other characters

changelogs/fragments/v2.12.0_summary.yaml

@@ -0,0 +1,3 @@
+release_summary: |
+   | Release Date: 2021-11-05
+   | `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__

changelogs/fragments/v2.12.0b1_summary.yaml

@@ -0,0 +1,3 @@
+release_summary: |
+   | Release Date: 2021-09-27
+   | `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__

changelogs/fragments/v2.12.0b2_summary.yaml

@@ -0,0 +1,3 @@
+release_summary: |
+   | Release Date: 2021-10-11
+   | `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__

changelogs/fragments/v2.12.0rc1_summary.yaml

@@ -0,0 +1,3 @@
+release_summary: |
+   | Release Date: 2021-10-18
+   | `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__

changelogs/fragments/v2.12.1_summary.yaml

@@ -0,0 +1,3 @@
+release_summary: |
+   | Release Date: 2021-12-06
+   | `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__

changelogs/fragments/v2.12.1rc1_summary.yaml

@@ -0,0 +1,3 @@
+release_summary: |
+   | Release Date: 2021-11-29
+   | `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__

changelogs/fragments/v2.12.2_summary.yaml

@@ -0,0 +1,3 @@
+release_summary: |
+   | Release Date: 2022-01-31
+   | `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__

changelogs/fragments/v2.12.2rc1_summary.yaml

@@ -0,0 +1,3 @@
+release_summary: |
+   | Release Date: 2022-01-24
+   | `Porting Guide <https://docs.ansible.com/ansible/devel/porting_guides.html>`__

changelogs/fragments/win_LinkUtil-ignore-LIB.yml

@@ -0,0 +1,2 @@
+bugfixes:
+- Ansible.ModuleUtils.LinkUtil - Ignore the ``LIB`` environment variable when loading the ``LinkUtil`` code

docs/docsite/.templates/banner.html

@@ -14,7 +14,8 @@
       });
     }
     var banner = '';
-    //use extra_banner for when marketing wants something extra, like a survey or AnsibleFest notice
+      var extra_banner = '';
+    /*use extra_banner for when marketing wants something extra, like a survey or AnsibleFest notice
     var extra_banner =
       '<div id="latest_extra_banner_id" class="admonition important">' +
       '<br>' +
@@ -26,7 +27,7 @@
         '<a href="https://reg.ansiblefest.redhat.com/flow/redhat/ansible21/regGenAttendee/login?sc_cid=7013a000002pemAAAQ">Register now!</a> ' +
       '</p>' +
       '<br>' +
-      '</div>';
+      '</div>'; */
     // Create a banner if we're not on the official docs site
     if (location.host == "docs.testing.ansible.com") {
       document.write('<div id="testing_banner_id" class="admonition important">' +

docs/docsite/requirements.txt

@@ -3,7 +3,7 @@
 # if you want known good versions of these dependencies
 # use known_good_reqs.txt instead 
 
-antsibull >= 0.34.0
+antsibull >= 0.38.2
 docutils == 0.16 # pin for now until the problem with unordered lists is fixed
 # see https://github.com/readthedocs/sphinx_rtd_theme/issues/1115jinja2==3.0.1
 jinja2

docs/docsite/rst/community/communication.rst

@@ -71,7 +71,9 @@ IRC chat supports:
 * simple text interface
 * bridging from Matrix
 
-Our IRC channels may require you to register your IRC nickname. If you receive an error when you connect or when posting a message, see `libera.chat's Nickname Registration guide <https://libera.chat/guides/registration>`_ for instructions. To find all ``ansible`` specific channels on the libera.chat network, use the following command in your IRC client::
+Our IRC channels may require you to register your IRC nickname. If you receive an error when you connect or when posting a message, see `libera.chat's Nickname Registration guide <https://libera.chat/guides/registration>`_ for instructions. To find all ``ansible`` specific channels on the libera.chat network, use the following command in your IRC client:
+
+.. code-block:: text
 
    /msg alis LIST #ansible* -min 5
 

docs/docsite/rst/community/development_process.rst

@@ -243,7 +243,7 @@ Here are some examples:
       remote_src=True even if mode was not set as a parameter.  This failed on
       filesystems which do not have permission bits (https://github.com/ansible/ansible/issues/29444).
 
-You can find more example changelog fragments in the `changelog directory <https://github.com/ansible/ansible/tree/stable-2.11/changelogs/fragments>`_ for the 2.11 release.
+You can find more example changelog fragments in the `changelog directory <https://github.com/ansible/ansible/tree/stable-2.12/changelogs/fragments>`_ for the 2.12 release.
 
 After you have written the changelog fragment for your PR, commit the file and include it with the pull request.
 
@@ -307,20 +307,20 @@ We do **not** backport features.
 
    These instructions assume that:
 
-    * ``stable-2.11`` is the targeted release branch for the backport
+    * ``stable-2.12`` is the targeted release branch for the backport
     * ``https://github.com/ansible/ansible.git`` is configured as a ``git remote`` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly.
     * ``https://github.com/<yourgithubaccount>/ansible.git`` is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``origin``, adjust the instructions accordingly.
 
 #. Prepare your devel, stable, and feature branches:
 
-   ::
+.. code-block:: shell
 
        git fetch upstream
-       git checkout -b backport/2.11/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.11
+       git checkout -b backport/2.12/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.12
 
 #. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary:
 
-   ::
+.. code-block:: shell
 
        git cherry-pick -x [SHA_FROM_DEVEL]
 
@@ -328,17 +328,17 @@ We do **not** backport features.
 
 #. Push your feature branch to your fork on GitHub:
 
-   ::
+.. code-block:: shell
 
-       git push origin backport/2.11/[PR_NUMBER_FROM_DEVEL]
+       git push origin backport/2.12/[PR_NUMBER_FROM_DEVEL]
 
-#. Submit the pull request for ``backport/2.11/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.11`` branch
+#. Submit the pull request for ``backport/2.12/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.12`` branch
 
 #. The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green.
 
 .. note::
 
-    The branch name ``backport/2.11/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary, but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
+    The branch name ``backport/2.12/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary, but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
 
 .. note::
 

docs/docsite/rst/dev_guide/developing_collections_contributing.rst

@@ -25,16 +25,22 @@ Creating a PR
 
 
 
-* Create the directory ``~/dev/ansible/collections/ansible_collections/community``::
+* Create the directory ``~/dev/ansible/collections/ansible_collections/community``:
+
+.. code-block:: shell
 
     mkdir -p ~/dev/ansible/collections/ansible_collections/community
 
-* Clone `the community.general Git repository <https://github.com/ansible-collections/community.general/>`_ or a fork of it into the directory ``general``::
+* Clone `the community.general Git repository <https://github.com/ansible-collections/community.general/>`_ or a fork of it into the directory ``general``:
+
+.. code-block:: shell
 
     cd ~/dev/ansible/collections/ansible_collections/community
     git clone git@github.com:ansible-collections/community.general.git general
 
-* If you clone from a fork, add the original repository as a remote ``upstream``::
+* If you clone from a fork, add the original repository as a remote ``upstream``:
+
+.. code-block:: shell
 
     cd ~/dev/ansible/collections/ansible_collections/community/general
     git remote add upstream git@github.com:ansible-collections/community.general.git

docs/docsite/rst/dev_guide/developing_collections_distributing.rst

@@ -54,7 +54,7 @@ You can create additional namespaces on Ansible Galaxy if you choose. For Red Ha
 * To create a namespace on Galaxy, see `Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_ on the Galaxy docsite for details.
 * To create a namespace on Red Hat Automation Hub, see the `Ansible Certified Content FAQ <https://access.redhat.com/articles/4916901>`_.
 
-Specify the namespace in the :file:`galaxy.yaml` file for each collection. For more information on the :file:`galaxy.yaml` file, see :ref:`collections_galaxy_meta`.
+Specify the namespace in the :file:`galaxy.yml` file for each collection. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`.
 
 .. _galaxy_get_token:
 
@@ -124,7 +124,7 @@ Building your collection tarball
 
 After configuring one or more distribution servers, build a collection tarball. The collection tarball is the published artifact, the object that you upload and other users download to install your collection. To build a collection tarball:
 
-#. Review the version number in your :file:`galaxy.yaml` file. Each time you publish your collection, it must have a new version number. You cannot make changes to existing versions of your collection on a distribution server. If you try to upload the same collection version more than once, the distribution server returns the error ``Code: conflict.collection_exists``. Collections follow semantic versioning rules. For more information on versions, see :ref:`collection_versions`. For more information on the :file:`galaxy.yaml` file, see :ref:`collections_galaxy_meta`.
+#. Review the version number in your :file:`galaxy.yml` file. Each time you publish your collection, it must have a new version number. You cannot make changes to existing versions of your collection on a distribution server. If you try to upload the same collection version more than once, the distribution server returns the error ``Code: conflict.collection_exists``. Collections follow semantic versioning rules. For more information on versions, see :ref:`collection_versions`. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`.
 #. Run ``ansible-galaxy collection build`` from inside the top-level directory of the collection. For example:
 
 .. code-block:: bash

docs/docsite/rst/dev_guide/developing_collections_structure.rst

@@ -13,7 +13,9 @@ A collection is a simple data structure. None of the directories are required un
 Collection directories and files
 ================================
 
-A collection can contain these directories and files::
+A collection can contain these directories and files:
+
+.. code-block:: shell-session
 
     collection/
     ├── docs/
@@ -201,7 +203,7 @@ A collection can store some additional metadata in a ``runtime.yml`` file in the
 
 - *requires_ansible*:
 
-  The version of Ansible required to use the collection. Multiple versions can be separated with a comma.
+  The version of Ansible Core (ansible-core) required to use the collection. Multiple versions can be separated with a comma.
 
   .. code:: yaml
 

docs/docsite/rst/dev_guide/developing_collections_testing.rst

@@ -20,7 +20,9 @@ You must always execute ``ansible-test`` from the root directory of a collection
 Compile and sanity tests
 ------------------------
 
-To run all compile and sanity tests::
+To run all compile and sanity tests:
+
+.. code-block:: shell-session
 
     ansible-test sanity --docker default -v
 
@@ -31,15 +33,21 @@ Adding unit tests
 
 You must place unit tests in the appropriate ``tests/unit/plugins/`` directory. For example, you would place tests for ``plugins/module_utils/foo/bar.py`` in ``tests/unit/plugins/module_utils/foo/test_bar.py`` or ``tests/unit/plugins/module_utils/foo/bar/test_bar.py``. For examples, see the `unit tests in community.general <https://github.com/ansible-collections/community.general/tree/master/tests/unit/>`_.
 
-To run all unit tests for all supported Python versions::
+To run all unit tests for all supported Python versions:
+
+.. code-block:: shell-session
 
     ansible-test units --docker default -v
 
-To run all unit tests only for a specific Python version::
+To run all unit tests only for a specific Python version:
+
+.. code-block:: shell-session
 
     ansible-test units --docker default -v --python 3.6
 
-To run only a specific unit test::
+To run only a specific unit test:
+
+.. code-block:: shell-session
 
     ansible-test units --docker default -v --python 3.6 tests/unit/plugins/module_utils/foo/test_bar.py
 
@@ -59,13 +67,17 @@ For examples, see the `integration tests in community.general <https://github.co
 
 Since integration tests can install requirements, and set-up, start and stop services, we recommended running them in docker containers or otherwise restricted environments whenever possible. By default, ``ansible-test`` supports Docker images for several operating systems. See the `list of supported docker images <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/completion/docker.txt>`_ for all options. Use the ``default`` image mainly for platform-independent integration tests, such as those for cloud modules. The following examples use the ``centos8`` image.
 
-To execute all integration tests for a collection::
+To execute all integration tests for a collection:
+
+.. code-block:: shell-session
 
     ansible-test integration --docker centos8 -v
 
 If you want more detailed output, run the command with ``-vvv`` instead of ``-v``. Alternatively, specify ``--retry-on-error`` to automatically re-run failed tests with higher verbosity levels.
 
-To execute only the integration tests in a specific directory::
+To execute only the integration tests in a specific directory:
+
+.. code-block:: shell-session
 
     ansible-test integration --docker centos8 -v connection_bar
 

docs/docsite/rst/dev_guide/developing_inventory.rst

@@ -360,9 +360,11 @@ Inventory script conventions
 Inventory scripts must accept the ``--list`` and ``--host <hostname>`` arguments. Although other arguments are allowed, Ansible will not use them.
 Such arguments might still be useful for executing the scripts directly.
 
-When the script is called with the single argument ``--list``, the script must output to stdout a JSON object that contains all the groups to be managed. Each group's value should be either an object containing a list of each host, any child groups, and potential group variables, or simply a list of hosts::
+When the script is called with the single argument ``--list``, the script must output to stdout a JSON object that contains all the groups to be managed. Each group's value should be either an object containing a list of each host, any child groups, and potential group variables, or simply a list of hosts:
 
 
+.. code-block:: json
+
     {
         "group001": {
             "hosts": ["host001", "host002"],
@@ -383,12 +385,13 @@ When the script is called with the single argument ``--list``, the script must o
 
 If any of the elements of a group are empty, they may be omitted from the output.
 
-When called with the argument ``--host <hostname>`` (where <hostname> is a host from above), the script must print a JSON object, either empty or containing variables to make them available to templates and playbooks. For example::
+When called with the argument ``--host <hostname>`` (where <hostname> is a host from above), the script must print a JSON object, either empty or containing variables to make them available to templates and playbooks. For example:
 
+.. code-block:: json
 
     {
         "VAR001": "VALUE",
-        "VAR002": "VALUE",
+        "VAR002": "VALUE"
     }
 
 Printing variables is optional. If the script does not print variables, it should print an empty JSON object.
@@ -404,7 +407,9 @@ The stock inventory script system mentioned above works for all versions of Ansi
 
 To avoid this inefficiency, if the inventory script returns a top-level element called "_meta", it is possible to return all the host variables in a single script execution. When this meta element contains a value for "hostvars", the inventory script will not be invoked with ``--host`` for each host. This behavior results in a significant performance increase for large numbers of hosts.
 
-The data to be added to the top-level JSON object looks like this::
+The data to be added to the top-level JSON object looks like this:
+
+.. code-block:: text
 
     {
 
@@ -424,7 +429,9 @@ The data to be added to the top-level JSON object looks like this::
     }
 
 To satisfy the requirements of using ``_meta``, to prevent ansible from calling your inventory with ``--host`` you must at least populate ``_meta`` with an empty ``hostvars`` object.
-For example::
+For example:
+
+.. code-block:: text
 
     {
 

docs/docsite/rst/dev_guide/developing_module_utilities.rst

@@ -8,7 +8,9 @@ Ansible provides a number of module utilities, or snippets of shared code, that
 provide helper functions you can use when developing your own modules. The
 ``basic.py`` module utility provides the main entry point for accessing the
 Ansible library, and all Python Ansible modules must import something from
-``ansible.module_utils``. A common option is to import ``AnsibleModule``::
+``ansible.module_utils``. A common option is to import ``AnsibleModule``:
+
+.. code-block:: python
 
   from ansible.module_utils.basic import AnsibleModule
 

docs/docsite/rst/dev_guide/developing_modules.rst

@@ -36,7 +36,7 @@ If your use case isn't covered by an existing module, an action plugin, or a rol
 * I want to :ref:`write a Windows module <developing_modules_general_windows>`.
 * I want :ref:`an overview of Ansible's architecture <developing_program_flow_modules>`.
 * I want to :ref:`document my module <developing_modules_documenting>`.
-* I want to :ref:`contribute my module back to Ansible Core <developing_modules_checklist>`.
+* I want to :ref:`contribute my module to an existing Ansible collection <developing_modules_checklist>`.
 * I want to :ref:`add unit and integration tests to my module <developing_testing>`.
 * I want to :ref:`add Python 3 support to my module <developing_python_3>`.
 * I want to :ref:`write multiple modules <developing_modules_in_groups>`.

docs/docsite/rst/dev_guide/developing_modules_documenting.rst

@@ -217,11 +217,20 @@ All fields in the ``DOCUMENTATION`` block are lower-case. All fields are require
         - ref: aci_guide
           description: Detailed information on how to manage your ACI infrastructure using Ansible.
 
+        # Reference by rST documentation anchor (with custom title)
+        - ref: The official Ansible ACI guide <aci_guide>
+          description: Detailed information on how to manage your ACI infrastructure using Ansible.
+
         # Reference by Internet resource
         - name: APIC Management Information Model reference
           description: Complete reference of the APIC object model.
           link: https://developer.cisco.com/docs/apic-mim-ref/
 
+
+  * If you use ``ref:`` to link to an anchor that is not associated with a title, you must add a title to the ref for the link to work correctly.
+  * You can link to non-module plugins with ``ref:`` using the rST anchor, but plugin and module anchors are never associated with a title, so you must supply a title when you link to them. For example ``ref: namespace.collection.plugin_name lookup plugin  <ansible_collections.namespace.collection.plugin_name_lookup>``.
+
+
 :notes:
 
   * Details of any important information that doesn't fit in one of the above sections.
@@ -235,6 +244,8 @@ You can link from your module documentation to other module docs, other resource
 
 * ``L()`` for links with a heading. For example: ``See L(Ansible Automation Platform,https://www.ansible.com/products/automation-platform).`` As of Ansible 2.10, do not use ``L()`` for relative links between Ansible documentation and collection documentation.
 * ``U()`` for URLs. For example: ``See U(https://www.ansible.com/products/automation-platform) for an overview.``
+* ``R()`` for cross-references with a heading (added in Ansible 2.10). For example: ``See R(Cisco IOS Platform Guide,ios_platform_options)``.  Use the RST anchor for the cross-reference. See :ref:`adding_anchors_rst` for details.
+* ``M()`` for module names. For example: ``See also M(ansible.builtin.yum) or M(community.general.apt_rpm)``.
 
 There are also some macros which do not create links but we use them to display certain types of
 content in a uniform way:
@@ -247,12 +258,17 @@ content in a uniform way:
 
 .. note::
 
-  For links between modules and documentation within a collection, you can use either of the options above. Use ``U()`` or ``L()`` with full URLs (not relative links).
+  Cross-references with ``R()`` currently **do not work** inside option and return value documentations. They do work however in the global description, notes, and ``seealso`` descriptions.
 
 .. note::
-    - When a collection is not the right granularity, use ``C(..)``:
 
-        - ``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.``
+  For links between modules and documentation within a collection, you can use any of the options above. For links outside of your collection, use ``R()`` if available. Otherwise, use ``U()`` or ``L()`` with full URLs (not relative links). For modules, use ``M()`` with the FQCN or ``ansible.builtin`` as shown in the example. If you are creating your own documentation site, you will need to use the `intersphinx extension <https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html>`_ to convert ``R()`` and ``M()`` to the correct links.
+
+.. note::
+  To refer to a group of modules in a collection, use ``R()``.  When a collection is not the right granularity, use ``C(..)``:
+
+    - ``Refer to the R(kubernetes.core collection, plugins_in_kubernetes.core) for information on managing kubernetes clusters.``
+    - ``The C(win_*) modules (spread across several collections) allow you to manage various aspects of windows hosts.``
 
 .. note::
 
@@ -325,7 +341,9 @@ EXAMPLES block
 
 After the shebang, the UTF-8 coding, the copyright line, the license section, and the ``DOCUMENTATION`` block comes the ``EXAMPLES`` block. Here you show users how your module works with real-world examples in multi-line plain-text YAML format. The best examples are ready for the user to copy and paste into a playbook. Review and update your examples with every change to your module.
 
-Per playbook best practices, each example should include a ``name:`` line::
+Per playbook best practices, each example should include a ``name:`` line:
+
+.. code-block:: text
 
     EXAMPLES = r'''
     - name: Ensure foo is installed
@@ -371,7 +389,9 @@ Otherwise, for each value returned, provide the following fields. All fields are
   :contains:
     Optional. To describe nested return values, set ``type: dict``, or ``type: list``/``elements: dict``, or if you really have to, ``type: complex``, and repeat the elements above for each sub-field.
 
-Here are two example ``RETURN`` sections, one with three simple fields and one with a complex nested field::
+Here are two example ``RETURN`` sections, one with three simple fields and one with a complex nested field:
+
+.. code-block:: text
 
     RETURN = r'''
     dest:

docs/docsite/rst/dev_guide/developing_modules_general.rst

@@ -153,7 +153,9 @@ Verifying your module code in a playbook
 The next step in verifying your new module is to consume it with an Ansible playbook.
 
 -  Create a playbook in any directory: ``$ touch testmod.yml``
--  Add the following to the new playbook file::
+-  Add the following to the new playbook file:
+
+.. code-block:: yaml
 
     - name: test my new module
       hosts: localhost

docs/docsite/rst/dev_guide/developing_modules_general_windows.rst

@@ -579,7 +579,9 @@ are some steps that need to be followed to set this up:
     #!powershell
 
 You can add more args to ``$complex_args`` as required by the module or define the module options through a JSON file
-with the structure::
+with the structure:
+
+.. code-block:: json
 
     {
         "ANSIBLE_MODULE_ARGS": {

docs/docsite/rst/dev_guide/developing_plugins.rst

@@ -473,7 +473,7 @@ Vars plugins
 
 Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins.
 
-Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. Vars plugins are unsupported by collections.
+Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. Vars plugins are supported by collections starting with Ansible 2.10.
 
 Older plugins used a ``run`` method as their main body/work:
 

docs/docsite/rst/dev_guide/developing_program_flow_modules.rst

@@ -425,7 +425,9 @@ _ansible_selinux_special_fs
 
 List. Names of filesystems which should have a special SELinux
 context. They are used by the `AnsibleModule` methods which operate on
-files (changing attributes, moving, and copying). To set, add a comma separated string of filesystem names in :file:`ansible.cfg`::
+files (changing attributes, moving, and copying). To set, add a comma separated string of filesystem names in :file:`ansible.cfg`:
+
+.. code-block:: ini
 
   # ansible.cfg
   [selinux]

docs/docsite/rst/dev_guide/developing_rebasing.rst

@@ -14,17 +14,23 @@ Rebasing the branch used to create your PR will resolve both of these issues.
 Configuring your remotes
 ========================
 
-Before you can rebase your PR, you need to make sure you have the proper remotes configured. These instructions apply to any repository on GitHub, including collections repositories. On other platforms (bitbucket, gitlab), the same principles and commands apply but the syntax may be different. We use the ansible/ansible repository here as an example. In other repositories, the branch names may be different. Assuming you cloned your fork in the usual fashion, the ``origin`` remote will point to your fork::
+Before you can rebase your PR, you need to make sure you have the proper remotes configured. These instructions apply to any repository on GitHub, including collections repositories. On other platforms (bitbucket, gitlab), the same principles and commands apply but the syntax may be different. We use the ansible/ansible repository here as an example. In other repositories, the branch names may be different. Assuming you cloned your fork in the usual fashion, the ``origin`` remote will point to your fork:
+
+.. code-block:: shell-session
 
    $ git remote -v
    origin  git@github.com:YOUR_GITHUB_USERNAME/ansible.git (fetch)
    origin  git@github.com:YOUR_GITHUB_USERNAME/ansible.git (push)
 
-However, you also need to add a remote which points to the upstream repository::
+However, you also need to add a remote which points to the upstream repository:
+
+.. code-block:: shell-session
 
    $ git remote add upstream https://github.com/ansible/ansible.git
 
-Which should leave you with the following remotes::
+Which should leave you with the following remotes:
+
+.. code-block:: shell-session
 
    $ git remote -v
    origin  git@github.com:YOUR_GITHUB_USERNAME/ansible.git (fetch)
@@ -32,7 +38,9 @@ Which should leave you with the following remotes::
    upstream        https://github.com/ansible/ansible.git (fetch)
    upstream        https://github.com/ansible/ansible.git (push)
 
-Checking the status of your branch should show your fork is up-to-date with the ``origin`` remote::
+Checking the status of your branch should show your fork is up-to-date with the ``origin`` remote:
+
+.. code-block:: shell-session
 
    $ git status
    On branch YOUR_BRANCH
@@ -42,14 +50,18 @@ Checking the status of your branch should show your fork is up-to-date with the
 Rebasing your branch
 ====================
 
-Once you have an ``upstream`` remote configured, you can rebase the branch for your PR::
+Once you have an ``upstream`` remote configured, you can rebase the branch for your PR:
+
+.. code-block:: shell-session
 
    $ git pull --rebase upstream devel
 
 This will replay the changes in your branch on top of the changes made in the upstream ``devel`` branch.
 If there are merge conflicts, you will be prompted to resolve those before you can continue.
 
-After you rebase, the status of your branch changes::
+After you rebase, the status of your branch changes:
+
+.. code-block:: shell-session
 
    $ git status
    On branch YOUR_BRANCH
@@ -65,7 +77,9 @@ Updating your pull request
 
 Now that you've rebased your branch, you need to push your changes to GitHub to update your PR.
 
-Since rebasing re-writes git history, you will need to use a force push::
+Since rebasing re-writes git history, you will need to use a force push:
+
+.. code-block:: shell-session
 
    $ git push --force-with-lease
 

docs/docsite/rst/dev_guide/overview_architecture.rst

@@ -40,7 +40,9 @@ To add new machines, there is no additional SSL signing server involved, so ther
 
 If there's another source of truth in your infrastructure, Ansible can also connect to that. Ansible can draw inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more.
 
-Here's what a plain text inventory file looks like::
+Here's what a plain text inventory file looks like:
+
+.. code-block:: text
 
     ---
     [webservers]
@@ -62,7 +64,9 @@ Playbooks can finely orchestrate multiple slices of your infrastructure topology
 
 Ansible's approach to orchestration is one of finely-tuned simplicity, as we believe your automation code should make perfect sense to you years down the road and there should be very little to remember about special syntax or features.
 
-Here's what a simple playbook looks like::
+Here's what a simple playbook looks like:
+
+.. code-block:: yaml
 
     ---
     - hosts: webservers

docs/docsite/rst/dev_guide/testing.rst

@@ -60,7 +60,9 @@ Organization
 
 When Pull Requests (PRs) are created they are tested using Azure Pipelines, a Continuous Integration (CI) tool. Results are shown at the end of every PR.
 
-When Azure Pipelines detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example::
+When Azure Pipelines detects an error and it can be linked back to a file that has been modified in the PR then the relevant lines will be added as a GitHub comment. For example:
+
+.. code-block:: text
 
    The test `ansible-test sanity --test pep8` failed with the following errors:
 
@@ -71,11 +73,15 @@ When Azure Pipelines detects an error and it can be linked back to a file that h
 
 From the above example we can see that ``--test pep8`` and ``--test validate-modules`` have identified an issue. The commands given allow you to run the same tests locally to ensure you've fixed all issues without having to push your changes to GitHub and wait for Azure Pipelines, for example:
 
-If you haven't already got Ansible available, use the local checkout by running::
+If you haven't already got Ansible available, use the local checkout by running:
+
+.. code-block:: shell-session
 
   source hacking/env-setup
 
-Then run the tests detailed in the GitHub comment::
+Then run the tests detailed in the GitHub comment:
+
+.. code-block:: shell-session
 
   ansible-test sanity --test pep8
   ansible-test sanity --test validate-modules
@@ -126,8 +132,9 @@ Here's how:
    other flavors, since some features (for example, package managers such as apt or yum) are specific to those OS versions.
 
 
-Create a fresh area to work::
+Create a fresh area to work:
 
+.. code-block:: shell-session
 
    git clone https://github.com/ansible/ansible.git ansible-pr-testing
    cd ansible-pr-testing
@@ -140,7 +147,9 @@ Next, find the pull request you'd like to test and make note of its number. It w
 
    It is important that the PR request target be ``ansible:devel``, as we do not accept pull requests into any other branch. Dot releases are cherry-picked manually by Ansible staff.
 
-Use the pull request number when you fetch the proposed changes and create your branch for testing::
+Use the pull request number when you fetch the proposed changes and create your branch for testing:
+
+.. code-block:: shell-session
 
    git fetch origin refs/pull/XXXX/head:testing_PRXXXX
    git checkout testing_PRXXXX
@@ -156,7 +165,9 @@ The first command fetches the proposed changes from the pull request and creates
 The Ansible source includes a script that allows you to use Ansible directly from source without requiring a
 full installation that is frequently used by developers on Ansible.
 
-Simply source it (to use the Linux/Unix terminology) to begin using it immediately::
+Simply source it (to use the Linux/Unix terminology) to begin using it immediately:
+
+.. code-block:: shell-session
 
    source ./hacking/env-setup
 

docs/docsite/rst/dev_guide/testing/sanity/no-main-display.rst

@@ -3,7 +3,9 @@ no-main-display
 
 As of Ansible 2.8, ``Display`` should no longer be imported from ``__main__``.
 
-``Display`` is now a singleton and should be utilized like the following::
+``Display`` is now a singleton and should be utilized like the following:
+
+.. code-block:: python
 
    from ansible.utils.display import Display
    display = Display()

docs/docsite/rst/dev_guide/testing_integration.rst

@@ -33,12 +33,16 @@ ansible-test command
 --------------------
 
 The example below assumes ``bin/`` is in your ``$PATH``. An easy way to achieve that
-is to initialize your environment with the ``env-setup`` command::
+is to initialize your environment with the ``env-setup`` command:
+
+.. code-block:: shell-session
 
     source hacking/env-setup
     ansible-test --help
 
-You can also call ``ansible-test`` with the full path::
+You can also call ``ansible-test`` with the full path:
+
+.. code-block:: shell-session
 
     bin/ansible-test --help
 
@@ -66,27 +70,31 @@ Non-destructive Tests
 These tests will modify files in subdirectories, but will not do things that install or remove packages or things
 outside of those test subdirectories.  They will also not reconfigure or bounce system services.
 
-.. note:: Running integration tests within Docker
+.. note:: Running integration tests within containers
 
-   To protect your system from any potential changes caused by integration tests, and to ensure a sensible set of dependencies are available we recommend that you always run integration tests with the ``--docker`` option, for example ``--docker centos8``. See the `list of supported docker images <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/completion/docker.txt>`_ for options (the ``default`` image is used for sanity and unit tests, as well as for platform independent integration tests such as those for cloud modules).
+   To protect your system from any potential changes caused by integration tests, and to ensure a sensible set of dependencies are available we recommend that you always run integration tests with the ``--docker`` option, for example ``--docker centos8``. See the `list of supported container images <https://github.com/ansible/ansible/blob/devel/test/lib/ansible_test/_data/completion/docker.txt>`_ for options (the ``default`` image is used for sanity and unit tests, as well as for platform independent integration tests such as those for cloud modules).
 
-.. note:: Avoiding pulling new Docker images
+Run as follows for all POSIX platform tests executed by our CI system in a Fedora 34 container:
 
-   Use the ``--docker-no-pull`` option to avoid pulling the latest container image. This is required when using custom local images that are not available for download.
+.. code-block:: shell-session
 
-Run as follows for all POSIX platform tests executed by our CI system in a fedora32 docker container::
+    ansible-test integration shippable/ --docker fedora34
 
-    ansible-test integration shippable/ --docker fedora32
+You can target a specific tests as well, such as for individual modules:
 
-You can target a specific tests as well, such as for individual modules::
+.. code-block:: shell-session
 
     ansible-test integration ping
 
-You can use the ``-v`` option to make the output more verbose::
+You can use the ``-v`` option to make the output more verbose:
+
+.. code-block:: shell-session
 
     ansible-test integration lineinfile -vvv
 
-Use the following command to list all the available targets::
+Use the following command to list all the available targets:
+
+.. code-block:: shell-session
 
     ansible-test integration --list-targets
 
@@ -98,9 +106,11 @@ Destructive Tests
 =================
 
 These tests are allowed to install and remove some trivial packages.  You will likely want to devote these
-to a virtual environment, such as Docker.  They won't reformat your filesystem::
+to a virtual environment, such as Docker.  They won't reformat your filesystem:
 
-    ansible-test integration destructive/ --docker fedora32
+.. code-block:: shell-session
+
+    ansible-test integration destructive/ --docker fedora34
 
 Windows Tests
 =============
@@ -112,25 +122,36 @@ for testing, and enable PowerShell Remoting to continue.
 Running these tests may result in changes to your Windows host, so don't run
 them against a production/critical Windows environment.
 
-Enable PowerShell Remoting (run on the Windows host via Remote Desktop)::
+Enable PowerShell Remoting (run on the Windows host via Remote Desktop):
+
+.. code-block:: shell-session
 
     Enable-PSRemoting -Force
 
-Define Windows inventory::
+Define Windows inventory:
+
+.. code-block:: shell-session
 
     cp inventory.winrm.template inventory.winrm
     ${EDITOR:-vi} inventory.winrm
 
-Run the Windows tests executed by our CI system::
+Run the Windows tests executed by our CI system:
+
+.. code-block:: shell-session
 
     ansible-test windows-integration -v shippable/
 
-Tests in Docker containers
+Tests in containers
 ==========================
 
-If you have a Linux system with Docker installed, running integration tests using the same Docker containers used by
+If you have a Linux system with Docker or Podman installed, running integration tests using the same containers used by
 the Ansible continuous integration (CI) system is recommended.
 
+.. note:: Podman
+
+   By default, Podman will only be used if the Docker CLI is not installed. If you have Docker installed but want to use
+   Podman, you can change this behavior by setting the environment variable ``ANSIBLE_TEST_PREFER_PODMAN``.
+
 .. note:: Docker on non-Linux
 
    Using Docker Engine to run Docker on a non-Linux host (such as macOS) is not recommended.
@@ -140,40 +161,43 @@ the Ansible continuous integration (CI) system is recommended.
 Running Integration Tests
 -------------------------
 
-To run all CI integration test targets for POSIX platforms in a Ubuntu 18.04 container::
+To run all CI integration test targets for POSIX platforms in a Ubuntu 18.04 container:
+
+.. code-block:: shell-session
 
     ansible-test integration shippable/ --docker ubuntu1804
 
 You can also run specific tests or select a different Linux distribution.
-For example, to run tests for the ``ping`` module on a Ubuntu 18.04 container::
+For example, to run tests for the ``ping`` module on a Ubuntu 18.04 container:
+
+.. code-block:: shell-session
 
     ansible-test integration ping --docker ubuntu1804
 
 Container Images
 ----------------
 
-Python 2
-^^^^^^^^
-
-Most container images are for testing with Python 2:
-
-  - centos6
-  - centos7
-  - opensuse15py2
-
 Python 3
 ^^^^^^^^
 
-To test with Python 3 use the following images:
+Most container images are for testing with Python 3:
 
   - alpine3
   - centos8
-  - fedora32
   - fedora33
+  - fedora34
   - opensuse15
   - ubuntu1804
   - ubuntu2004
 
+Python 2
+^^^^^^^^
+
+To test with Python 2 use the following images:
+
+  - centos7
+  - opensuse15py2
+
 
 Legacy Cloud Tests
 ==================

docs/docsite/rst/dev_guide/testing_integration_legacy.rst

@@ -41,7 +41,9 @@ In order to run cloud tests, you must provide access credentials in a file
 named ``credentials.yml``. A sample credentials file named
 ``credentials.template`` is available for syntax help.
 
-Provide cloud credentials::
+Provide cloud credentials:
+
+.. code-block:: shell-session
 
     cp credentials.template credentials.yml
     ${EDITOR:-vi} credentials.yml
@@ -85,11 +87,15 @@ Running Tests
 
 The tests are invoked via a ``Makefile``.
 
-If you haven't already got Ansible available use the local checkout by doing::
+If you haven't already got Ansible available use the local checkout by doing:
+
+.. code-block:: shell-session
 
   source hacking/env-setup
 
-Run the tests by doing::
+Run the tests by doing:
+
+.. code-block:: shell-session
 
   cd test/integration/
   # TARGET is the name of the test from the list at the top of this page

docs/docsite/rst/dev_guide/testing_running_locally.rst

@@ -70,7 +70,9 @@ be written.  Online reports are available but only cover the ``devel`` branch (s
 Add the ``--coverage`` option to any test command to collect code coverage data.  If you
 aren't using the ``--venv`` or ``--docker`` options which create an isolated python
 environment then you may have to use the ``--requirements`` option to ensure that the
-correct version of the coverage module is installed::
+correct version of the coverage module is installed:
+
+.. code-block:: shell-session
 
    ansible-test coverage erase
    ansible-test units --coverage apt
@@ -84,6 +86,8 @@ Reports can be generated in several different formats:
 * ``ansible-test coverage html`` - HTML report.
 * ``ansible-test coverage xml`` - XML report.
 
-To clear data between test runs, use the ``ansible-test coverage erase`` command. For a full list of features see the online help::
+To clear data between test runs, use the ``ansible-test coverage erase`` command. For a full list of features see the online help:
+
+.. code-block:: shell-session
 
    ansible-test coverage --help

docs/docsite/rst/dev_guide/testing_units.rst

@@ -53,7 +53,9 @@ If you are running unit tests against things other than modules, such as module
 
    ansible-test units --docker -v test/units/module_utils/basic/test_imports.py
 
-For advanced usage see the online help::
+For advanced usage see the online help:
+
+.. code:: shell
 
    ansible-test units --help
 
@@ -104,35 +106,39 @@ Ansible drives unit tests through `pytest <https://docs.pytest.org/en/latest/>`_
 means that tests can either be written a simple functions which are included in any file
 name like ``test_<something>.py`` or as classes.
 
-Here is an example of a function::
+Here is an example of a function:
+
+.. code:: python
 
   #this function will be called simply because it is called test_*()
 
-  def test_add()
+  def test_add():
       a = 10
       b = 23
       c = 33
-      assert a + b = c
+      assert a + b == c
 
-Here is an example of a class::
+Here is an example of a class:
+
+.. code:: python
 
   import unittest
 
-  class AddTester(unittest.TestCase)
+  class AddTester(unittest.TestCase):
 
-      def SetUp()
+      def SetUp():
           self.a = 10
           self.b = 23
 
       # this function will
-      def test_add()
+      def test_add():
         c = 33
-        assert self.a + self.b = c
+        assert self.a + self.b == c
 
      # this function will
-      def test_subtract()
+      def test_subtract():
         c = -13
-        assert self.a - self.b = c
+        assert self.a - self.b == c
 
 Both methods work fine in most circumstances; the function-based interface is simpler and
 quicker and so that's probably where you should start when you are just trying to add a

docs/docsite/rst/dev_guide/testing_units_modules.rst

@@ -168,7 +168,9 @@ Ensuring failure cases are visible with mock objects
 Functions like :meth:`module.fail_json` are normally expected to terminate execution. When you
 run with a mock module object this doesn't happen since the mock always returns another mock
 from a function call. You can set up the mock to raise an exception as shown above, or you can
-assert that these functions have not been called in each test. For example::
+assert that these functions have not been called in each test. For example:
+
+.. code-block:: python
 
   module = MagicMock()
   function_to_test(module, argument)
@@ -185,7 +187,9 @@ The setup of an actual module is quite complex (see `Passing Arguments`_ below)
 isn't needed for most functions which use a module. Instead you can use a mock object as
 the module and create any module attributes needed by the function you are testing. If
 you do this, beware that the module exit functions need special handling as mentioned
-above, either by throwing an exception or ensuring that they haven't been called. For example::
+above, either by throwing an exception or ensuring that they haven't been called. For example:
+
+.. code-block:: python
 
     class AnsibleExitJson(Exception):
         """Exception class to be raised by module.exit_json and caught by the test case"""
@@ -218,7 +222,9 @@ present in the message. This means that we can check that we use the correct
 parameters and nothing else.
 
 
-*Example:  in rds_instance unit tests a simple instance state is defined*::
+*Example:  in rds_instance unit tests a simple instance state is defined*:
+
+.. code-block:: python
 
     def simple_instance_list(status, pending):
         return {u'DBInstances': [{u'DBInstanceArn': 'arn:aws:rds:us-east-1:1234567890:db:fakedb',
@@ -226,7 +232,9 @@ parameters and nothing else.
                                   u'PendingModifiedValues': pending,
                                   u'DBInstanceIdentifier': 'fakedb'}]}
 
-This is then used to create a list of states::
+This is then used to create a list of states:
+
+.. code-block:: python
 
     rds_client_double = MagicMock()
     rds_client_double.describe_db_instances.side_effect = [
@@ -243,7 +251,9 @@ This is then used to create a list of states::
 
 These states are then used as returns from a mock object to ensure that the ``await`` function
 waits through all of the states that would mean the RDS instance has not yet completed
-configuration::
+configuration:
+
+.. code-block:: python
 
    rds_i.await_resource(rds_client_double, "some-instance", "available", mod_mock,
                         await_pending=1)
@@ -292,7 +302,9 @@ To pass arguments to a module correctly, use the ``set_module_args`` method whic
 as its parameter. Module creation and argument processing is
 handled through the :class:`AnsibleModule` object in the basic section of the utilities. Normally
 this accepts input on ``STDIN``, which is not convenient for unit testing. When the special
-variable is set it will be treated as if the input came on ``STDIN`` to the module. Simply call that function before setting up your module::
+variable is set it will be treated as if the input came on ``STDIN`` to the module. Simply call that function before setting up your module:
+
+.. code-block:: python
 
     import json
     from units.modules.utils import set_module_args
@@ -314,7 +326,9 @@ Handling exit correctly
 The :meth:`module.exit_json` function won't work properly in a testing environment since it
 writes error information to ``STDOUT`` upon exit, where it
 is difficult to examine. This can be mitigated by replacing it (and :meth:`module.fail_json`) with
-a function that raises an exception::
+a function that raises an exception:
+
+.. code-block:: python
 
     def exit_json(*args, **kwargs):
         if 'changed' not in kwargs:
@@ -322,7 +336,9 @@ a function that raises an exception::
         raise AnsibleExitJson(kwargs)
 
 Now you can ensure that the first function called is the one you expected simply by
-testing for the correct exception::
+testing for the correct exception:
+
+.. code-block:: python
 
     def test_returned_value(self):
         set_module_args({
@@ -342,7 +358,9 @@ Running the main function
 -------------------------
 
 If you do want to run the actual main function of a module you must import the module, set
-the arguments as above, set up the appropriate exit exception and then run the module::
+the arguments as above, set up the appropriate exit exception and then run the module:
+
+.. code-block:: python
 
     # This test is based around pytest's features for individual test functions
     import pytest
@@ -364,7 +382,9 @@ Handling calls to external executables
 Module must use :meth:`AnsibleModule.run_command` in order to execute an external command. This
 method needs to be mocked:
 
-Here is a simple mock of :meth:`AnsibleModule.run_command` (taken from :file:`test/units/modules/packaging/os/test_rhn_register.py`)::
+Here is a simple mock of :meth:`AnsibleModule.run_command` (taken from :file:`test/units/modules/packaging/os/test_rhn_register.py`):
+
+.. code-block:: python
 
         with patch.object(basic.AnsibleModule, 'run_command') as run_command:
             run_command.return_value = 0, '', ''  # successful execution, no output
@@ -381,7 +401,9 @@ A Complete Example
 ------------------
 
 The following example is a complete skeleton that reuses the mocks explained above and adds a new
-mock for :meth:`Ansible.get_bin_path`::
+mock for :meth:`Ansible.get_bin_path`:
+
+.. code-block:: python
 
     import json
 
@@ -470,7 +492,9 @@ Restructuring modules to enable testing module set up and other processes
 
 Often modules have a ``main()`` function which sets up the module and then performs other
 actions. This can make it difficult to check argument processing. This can be made easier by
-moving module configuration and initialization into a separate function. For example::
+moving module configuration and initialization into a separate function. For example:
+
+.. code-block:: python
 
     argument_spec = dict(
         # module function variables
@@ -498,7 +522,9 @@ moving module configuration and initialization into a separate function. For exa
         return_dict = run_task(module, conn)
         module.exit_json(**return_dict)
 
-This now makes it possible to run tests against the module initiation function::
+This now makes it possible to run tests against the module initiation function:
+
+.. code-block:: python
 
     def test_rds_module_setup_fails_if_db_instance_identifier_parameter_missing():
         # db_instance_identifier parameter is missing

docs/docsite/rst/galaxy/user_guide.rst

@@ -54,7 +54,7 @@ You can download collections from Automation Hub at the command line. Automation
       server_list = automation_hub
 
       [galaxy_server.automation_hub]
-      url=https://cloud.redhat.com/api/automation-hub/
+      url=https://console.redhat.com/api/automation-hub/
       auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
       token=my_ah_token
 
@@ -83,6 +83,11 @@ Downloading a collection for offline use
 
 .. include:: ../shared_snippets/download_tarball_collections.txt
 
+Installing a collection from source files
+-----------------------------------------
+
+.. include:: ../shared_snippets/installing_collections_file.rst
+
 Installing a collection from a git repository
 ---------------------------------------------
 

docs/docsite/rst/installation_guide/intro_installation.rst

@@ -239,20 +239,6 @@ On CentOS:
     $ sudo yum install epel-release
     $ sudo yum install ansible
 
-RPMs for RHEL 7 and RHEL 8 are available from the `Ansible Engine repository <https://access.redhat.com/articles/3174981>`_.
-
-To enable the Ansible Engine repository for RHEL 8, run the following command:
-
-.. code-block:: bash
-
-    $ sudo subscription-manager repos --enable ansible-2.9-for-rhel-8-x86_64-rpms
-
-To enable the Ansible Engine repository for RHEL 7, run the following command:
-
-.. code-block:: bash
-
-    $ sudo subscription-manager repos --enable rhel-7-server-ansible-2.9-rpms
-
 RPMs for currently supported versions of RHEL and CentOS are also available from `EPEL <https://fedoraproject.org/wiki/EPEL>`_.
 
 .. note::
@@ -294,7 +280,7 @@ Debian users may use the same source as the Ubuntu PPA (using the following tabl
   :header-rows: 1
 
   * - Debian
-    - 
+    -
     - Ubuntu
   * - Debian 11 (Bullseye)
     - ->
@@ -308,7 +294,7 @@ Debian users may use the same source as the Ubuntu PPA (using the following tabl
   * - Debian 8 (Jessie)
     - ->
     - Ubuntu 14.04 (Trusty)
-    
+
 .. note::
 
     As of Ansible 4.0.0, new releases will only be generated for Ubuntu 18.04 (Bionic) or later releases.
@@ -318,7 +304,7 @@ Add the following line to ``/etc/apt/sources.list`` or ``/etc/apt/sources.list.d
 .. code-block:: bash
 
     deb http://ppa.launchpad.net/ansible/ansible/ubuntu MATCHING_UBUNTU_CODENAME_HERE main
-    
+
 Example for Debian 11 (Bullseye)
 
 .. code-block:: bash
@@ -421,7 +407,7 @@ Ansible is available in the Community repository::
 
     $ pacman -S ansible
 
-The AUR has a PKGBUILD for pulling directly from GitHub called `ansible-git <https://aur.archlinux.org/packages/ansible-git>`_.
+The AUR has a PKGBUILD for pulling directly from GitHub called `ansible-core-git <https://aur.archlinux.org/packages/ansible-core-git>`_.
 
 Also see the `Ansible <https://wiki.archlinux.org/index.php/Ansible>`_ page on the ArchWiki.
 
@@ -457,6 +443,14 @@ Update of the software will be managed by the swupd tool::
 .. _from_pip_devel:
 .. _getting_ansible:
 
+.. _from_windows:
+
+Installing Ansible on Windows
+------------------------------
+
+See :ref:`windows_faq_ansible`
+
+
 Installing and running the ``devel`` branch from source
 =======================================================
 
@@ -624,7 +618,7 @@ Installing ``argcomplete`` with ``apt``
 
 .. code-block:: bash
 
-    $ sudo apt install python-argcomplete
+    $ sudo apt install python3-argcomplete
 
 
 Installing ``argcomplete`` with ``pip``

docs/docsite/rst/locales/ja/LC_MESSAGES/galaxy.po

@@ -7,7 +7,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: Ansible devel\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2021-03-08 20:25+0100\n"
+"POT-Creation-Date: 2021-10-05 13:53+0200\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
@@ -49,7 +49,7 @@ msgid "The above will create the following directory structure in the current wo
 msgstr "上記により、現在の作業ディレクトリーに以下のディレクトリー構造が作成されます。"
 
 #: ../../rst/galaxy/dev_guide.rst:57
-msgid "If you want to create a repository for the role the repository root should be `role_name`."
+msgid "If you want to create a repository for the role, the repository root should be `role_name`."
 msgstr "ロールのリポジトリーを作成する場合、リポジトリーのルートは `role_name` である必要があります。"
 
 #: ../../rst/galaxy/dev_guide.rst:60
@@ -245,12 +245,12 @@ msgid "Questions? Help? Ideas?  Stop by the list on Google Groups"
 msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。"
 
 #: ../../rst/galaxy/dev_guide.rst:245
-msgid "`irc.freenode.net <http://irc.freenode.net>`_"
-msgstr "`irc.freenode.net <http://irc.freenode.net>`_"
+msgid ":ref:`communication_irc`"
+msgstr ":ref:`communication_irc`"
 
 #: ../../rst/galaxy/dev_guide.rst:246
-msgid "#ansible IRC chat channel"
-msgstr "IRC チャットチャンネル (#ansible)"
+msgid "How to join Ansible chat channels"
+msgstr "Ansible チャットチャンネルへの参加方法"
 
 #: ../../rst/galaxy/user_guide.rst:6
 msgid "Galaxy User Guide"
@@ -302,7 +302,7 @@ msgstr "デフォルトでは、``ansible-galaxy collection install`` は https:
 
 #: ../../rst/shared_snippets/installing_collections.txt:7
 msgid "See :ref:`Configuring the ansible-galaxy client <galaxy_server_config>` if you are using any other Galaxy server, such as Red Hat Automation Hub."
-msgstr "Red Hat Automation Hub などの他の Galaxy サーバーを使用している場合は、「:ref:`Configuring the ansible-galaxy client <galaxy_server_config>`」を参照してください。"
+msgstr "Red Hat Automation Hub などの他の Galaxy サーバーを使用している場合は、「:ref:`ansible-galaxy クライアントの設定 <galaxy_server_config>`」を参照してください。"
 
 #: ../../rst/shared_snippets/installing_collections.txt:9
 msgid "To install a collection hosted in Galaxy:"
@@ -326,11 +326,11 @@ msgstr "名前空間ディレクトリーに複数のコレクションをイン
 
 #: ../../rst/shared_snippets/installing_collections.txt:51
 msgid "The install command automatically appends the path ``ansible_collections`` to the one specified  with the ``-p`` option unless the parent directory is already in a folder called ``ansible_collections``."
-msgstr "install コマンドは、親ディレクトリーが ``ansible_collections`` ディレクトリーに含まれている場合を除き、``-p`` オプションで指定したパスに、パス ``ansible_collections`` を自動的に追加します。"
+msgstr "install コマンドは、親ディレクトリーが ``ansible_collections`` ディレクトリーに含まれている場合を除き、``-p`` オプションで指定したものに、パス ``ansible_collections`` を自動的に追加します。"
 
 #: ../../rst/shared_snippets/installing_collections.txt:55
 msgid "When using the ``-p`` option to specify the install path, use one of the values configured in :ref:`COLLECTIONS_PATHS`, as this is where Ansible itself will expect to find collections. If you don't specify a path, ``ansible-galaxy collection install`` installs the collection to the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections``"
-msgstr "``-p`` オプションを使用してインストールパスを指定する場合は、Ansible 自体がコレクションを見つけることが予想される場所であるため、:ref:`COLLECTIONS_PATHS` に設定された値のいずれかを使用します。パスを指定しないと、``ansible-galaxy collection install`` は :ref:`COLLECTIONS_PATHS` で定義されている最初のパスにコレクションをインストールします。これは、デフォルトでは ``~/.ansible/collections`` です。"
+msgstr "``-p`` オプションを使用してインストールパスを指定する場合は、Ansible 自体がコレクションを見つけることが予想される場所であるため、:ref:`COLLECTIONS_PATHS` に設定された値のいずれかを使用します。パスを指定しないと、``ansible-galaxy collection install`` は、:ref:`COLLECTIONS_PATHS` で定義されている最初のパスにコレクションをインストールします。これは、デフォルトでは ``~/.ansible/collections`` です。"
 
 #: ../../rst/shared_snippets/installing_collections.txt:59
 msgid "You can also keep a collection adjacent to the current playbook, under a ``collections/ansible_collections/`` directory structure."
@@ -421,36 +421,56 @@ msgid "Install multiple collections with a requirements file"
 msgstr "要件ファイルを使用した複数のコレクションのインストール"
 
 #: ../../rst/shared_snippets/installing_multiple_collections.txt:2
-msgid "You can also setup a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format:"
-msgstr "``requirements.yml`` ファイルを設定して、1 つのコマンドで複数のコレクションをインストールすることもできます。このファイルは、以下の形式の YAML ファイルです。"
+msgid "You can set up a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format:"
+msgstr "``requirements.yml`` ファイルを設定して、1 つのコマンドで複数のコレクションをインストールできます。このファイルは、以下の形式の YAML ファイルです。"
 
 #: ../../rst/shared_snippets/installing_multiple_collections.txt:16
-msgid "The supported keys for collection requirement entries are ``name``, ``version``, ``source``, and ``type``."
-msgstr "コレクション要件エントリーでサポートされるキーは ``name``、``version``、``source``、および ``type`` です。"
+msgid "You can specify four keys for each collection entry:"
+msgstr "各コレクションエントリーに 4 つのキーを指定できます。"
 
 #: ../../rst/shared_snippets/installing_multiple_collections.txt:18
-msgid "The ``version`` key can take in the same range identifier format documented above. If you're installing a collection from a git repository instead of a built collection artifact, the ``version`` key refers to a `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_."
-msgstr "``version`` キーは、上記の範囲識別子の形式を取ることができます。ビルドコレクションアーティファクトではなく git リポジトリーからコレクションをインストールする場合は、``version`` キーは `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ を参照します。"
+msgid "``name``"
+msgstr "``name``"
+
+#: ../../rst/shared_snippets/installing_multiple_collections.txt:19
+msgid "``version``"
+msgstr "``version``"
 
 #: ../../rst/shared_snippets/installing_multiple_collections.txt:20
+msgid "``source``"
+msgstr "``source``"
+
+#: ../../rst/shared_snippets/installing_multiple_collections.txt:21
+msgid "``type``"
+msgstr "``type``"
+
+#: ../../rst/shared_snippets/installing_multiple_collections.txt:23
+msgid "The ``version`` key uses the same range identifier format documented in :ref:`collections_older_version`."
+msgstr "``version`` キーは、:ref:`collections_older_version` に記載されているものと同じ範囲識別子形式を使用します。"
+
+#: ../../rst/shared_snippets/installing_multiple_collections.txt:25
 msgid "The ``type`` key can be set to ``galaxy``, ``url``, ``file``, and ``git``. If ``type`` is omitted, the ``name`` key is used to implicitly determine the source of the collection."
 msgstr "``type`` キーは ``galaxy``、``url``、``file``、および ``git`` に設定できます。``type`` を省略すると、``name`` キーを使用してコレクションのソースを暗黙的に決定します。"
 
-#: ../../rst/shared_snippets/installing_multiple_collections.txt:22
-msgid "Roles can also be specified and placed under the ``roles`` key. The values follow the same format as a requirements file used in older Ansible releases."
-msgstr "ロールは、``roles`` キーの下に指定して配置することもできます。この値は、古い Ansible リリースで使用される要件ファイルと同じ形式に従います。"
+#: ../../rst/shared_snippets/installing_multiple_collections.txt:27
+msgid "When you install a collection with ``type: git``, the ``version`` key can refer to a branch or to a `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ object (commit or tag). For example:"
+msgstr "``type: git`` でコレクションをインストールする場合、``version`` キーはブランチまたは `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ オブジェクト（コミットまたはタグ）を参照できます。以下に例を示します。"
 
-#: ../../rst/shared_snippets/installing_multiple_collections.txt:39
+#: ../../rst/shared_snippets/installing_multiple_collections.txt:36
+msgid "You can also add roles to a ``requirements.yml`` file, under the ``roles`` key. The values follow the same format as a requirements file used in older Ansible releases."
+msgstr "``roles``キーの下にある``requirements.yml``ファイルにロールを追加することもできます。この値は、古い Ansible リリースで使用される要件ファイルと同じ形式に従います。"
+
+#: ../../rst/shared_snippets/installing_multiple_collections.txt:52
 msgid "To install both roles and collections at the same time with one command, run the following:"
 msgstr "1 つのコマンドで、ロールとコレクションを同時にインストールするには、以下のコマンドを実行します。"
 
-#: ../../rst/shared_snippets/installing_multiple_collections.txt:45
+#: ../../rst/shared_snippets/installing_multiple_collections.txt:58
 msgid "Running ``ansible-galaxy collection install -r`` or ``ansible-galaxy role install -r`` will only install collections, or roles respectively."
 msgstr "``ansible-galaxy collection install -r`` または ``ansible-galaxy role install -r`` を実行すると、それぞれコレクションまたはロールがインストールされます。"
 
-#: ../../rst/shared_snippets/installing_multiple_collections.txt:49
+#: ../../rst/shared_snippets/installing_multiple_collections.txt:61
 msgid "Installing both roles and collections from the same requirements file will not work when specifying a custom collection or role install path. In this scenario the collections will be skipped and the command will process each like ``ansible-galaxy role install`` would."
-msgstr "カスタムコレクションまたはロールインストールパスを指定する場合は、同じ要件ファイルからロールとコレクションの両方をインストールすることはできません。今回の例では、コレクションは省略され、コマンドは ``ansible-galaxy role install`` のように処理されます。"
+msgstr "カスタムコレクションまたはロールインストールパスを指定する場合、同じ要件ファイルからロールとコレクションの両方をインストールすることはできません。今回の例では、コレクションは省略され、コマンドは ``ansible-galaxy role install`` のように処理されます。"
 
 #: ../../rst/galaxy/user_guide.rst:82
 msgid "Downloading a collection for offline use"
@@ -477,44 +497,80 @@ msgid "Installing a collection from a git repository"
 msgstr "git リポジトリーからのコレクションのインストール"
 
 #: ../../rst/shared_snippets/installing_collections_git_repo.txt:1
-msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` or ``MANIFEST.json`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ version (for example, a commit or tag)."
-msgstr "コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーに URI を提供することにより、git リポジトリーにコレクションをインストールできます。コレクションには、``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルが必要です。このコレクションは、ディレクトリーからの will-be コレクションアーティファクトデータを生成するのに使用されます。URI の接頭辞には ``git+`` (または ssh 認証でプライベートリポジトリーを使用する ``git@``）を付け、必要に応じてコンマ区切りの `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ バージョン (コミットまたはタグなど) をサポートする必要があります。"
+msgid "You can install a collection from a git repository instead of from Galaxy or Automation Hub. As a developer, installing from a git repository lets you review your collection before you create the tarball and publish the collection. As a user, installing from a git repository lets you use collections or versions that are not in Galaxy or Automation Hub yet."
+msgstr "コレクションは、Galaxy または Automation Hub の代わりに git リポジトリーからインストールできます。開発者は、git リポジトリーからインストールし、tarball を作成してコレクションを公開する前にコレクションを確認できます。ユーザーとして git リポジトリーからインストールすることで、Galaxy または Automation Hub にないコレクションまたはバージョンを使用できます。"
 
-#: ../../rst/shared_snippets/installing_collections_git_repo.txt:5
-msgid "Embedding credentials into a git URI is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_, `netrc <https://linux.die.net/man/5/netrc>`_ or `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_/`url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ in Git config to prevent your creds from being exposed in logs."
-msgstr "認証情報を git URI に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_、`netrc <https://linux.die.net/man/5/netrc>`_、または `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_/`url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ で、クレジットがログに公開されないようにします。"
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:3
+msgid "The repository must contain a ``galaxy.yml`` or ``MANIFEST.json`` file. This file provides metadata such as the version number and namespace of the collection."
+msgstr "リポジトリーには ``galaxy.yml`` または ``MANIFEST.json`` ファイルが含まれている必要があります。このファイルは、コレクションのバージョン番号、namespace などのメタデータを提供します。"
 
-#: ../../rst/shared_snippets/installing_collections_git_repo.txt:18
-msgid "In a ``requirements.yml`` file, you can also use the ``type`` and ``version`` keys in addition to using the ``git+repo,version`` syntax for the collection name."
-msgstr "``requirements.yml`` ファイルでは、コレクション名の ``git+repo,version`` 構文を使用する他に、``type`` キーおよび ``version`` キーを使用することもできます。"
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:6
+msgid "Installing a collection from a git repository at the command line"
+msgstr "コマンドガイドで git リポジトリーからのコレクションのインストール"
+
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:8
+msgid "To install a collection from a git repository at the command line, use the URI of the repository instead of a collection name or path to a ``tar.gz`` file.  Prefix the URI with ``git+`` (or with ``git@`` to use a private repository with ssh authentication). You can specify a branch, commit, or tag using the comma-separated `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ syntax."
+msgstr "git リポジトリーからコレクションをインストールするには、コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーの URI を使用します。``git+`` を使用して URI をプレフィックスします（または ``git@`` を使用して、ssh 認証でプライベートリポジトリーを使用します）。コンマ区切りの `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ 構文を使用して、ブランチ、コミット、またはタグを指定できます。"
+
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:10
+msgid "For example:"
+msgstr "例:"
+
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:25
+msgid "Embedding credentials into a git URI is not secure. Use safe authentication options to prevent your credentials from being exposed in logs or elsewhere."
+msgstr "認証情報を git URI に埋め込むことは安全ではありません。安全な認証オプションを使用して、認証情報がログに公開されないようにします。"
 
 #: ../../rst/shared_snippets/installing_collections_git_repo.txt:27
-msgid "Git repositories can be used for collection dependencies as well. This can be helpful for local development and testing but built/published artifacts should only have dependencies on other artifacts."
-msgstr "git リポジトリーはコレクションの依存関係にも使用できます。これは、ローカル開発およびテストに役立ちますが、ビルド/公開されたアーティファクトには他のアーティファクトへの依存関係のみが必要です。"
+msgid "Use `SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_ authentication"
+msgstr "`SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_ 認証を使用する"
 
-#: ../../rst/shared_snippets/installing_collections_git_repo.txt:34
-msgid "Default repository search locations"
-msgstr "デフォルトのリポジトリー検索の場所"
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:28
+msgid "Use `netrc <https://linux.die.net/man/5/netrc>`_ authentication"
+msgstr "`netrc <https://linux.die.net/man/5/netrc>`_ 認証を使用する"
 
-#: ../../rst/shared_snippets/installing_collections_git_repo.txt:36
-msgid "There are two paths searched in a repository for collections by default."
-msgstr "デフォルトでは、コレクション用のリポジトリーで 2 つのパスが検索されます。"
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:29
+msgid "Use `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_ in your git configuration"
+msgstr "お使いの git 設定で `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_ を使用する"
+
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:30
+msgid "Use `url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ in your git configuration"
+msgstr "お使いの git 設定で `url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ を使用する"
+
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:33
+msgid "Specifying the collection location within the git repository"
+msgstr "git リポジトリー内でのコレクションの場所の指定"
+
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:35
+msgid "When you install a collection from a git repository, Ansible uses the collection ``galaxy.yml`` or ``MANIFEST.json`` metadata file to build the collection. By default, Ansible searches two paths for collection ``galaxy.yml`` or ``MANIFEST.json`` metadata files:"
+msgstr "git リポジトリーからコレクションをインストールする場合、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルを使用してコレクションを構築します。デフォルトでは、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルの 2 つのパスを検索します。"
+
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:37
+msgid "The top level of the repository."
+msgstr "リポジトリーのトップレベル。"
 
 #: ../../rst/shared_snippets/installing_collections_git_repo.txt:38
-msgid "The first is the ``galaxy.yml`` or ``MANIFEST.json`` file in the top level of the repository path. If the file exists it's used as the collection metadata and the individual collection will be installed."
-msgstr "1 つ目は、リポジトリーパスの最上位にある ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ファイルが存在する場合は、コレクションのメタデータとして使用され、個々のコレクションがインストールされます。"
+msgid "Each directory in the repository path (one level deep)."
+msgstr "リポジトリーパス内の各ディレクトリー（1 レベルの深さ）"
 
-#: ../../rst/shared_snippets/installing_collections_git_repo.txt:49
-msgid "The second is a ``galaxy.yml`` or ``MANIFEST.json`` file in each directory in the repository path (one level deep). In this scenario, each directory with a metadata file is installed as a collection."
-msgstr "2 つ目は、リポジトリーパス (1 レベルの深さ) の各ディレクトリーの ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ここでは、メタデータファイルが含まれる各ディレクトリーがコレクションとしてインストールされます)。"
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:40
+msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in the top level of the repository, Ansible uses the collection metadata in that file to install an individual collection."
+msgstr "``galaxy.yml`` または ``MANIFEST.json`` ファイルがリポジトリーのトップレベルにある場合、Ansible はそのファイル内のコレクションメタデータを使用して個別のコレクションをインストールします。"
 
-#: ../../rst/shared_snippets/installing_collections_git_repo.txt:62
-msgid "Specifying the location to search for collections"
-msgstr "コレクションを検索する場所の指定"
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:51
+msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in one or more directories in the repository path (one level deep), Ansible installs each directory with a metadata file as a collection. For example, Ansible installs both collection1 and collection2 from this repository structure by default:"
+msgstr "リポジトリーパス内の 1 つ以上のディレクトリーに ``galaxy.yml`` または ``MANIFEST.json`` ファイルが存在する場合は、Ansible はメタデータファイルを持つ各ディレクトリーをコレクションとしてインストールします。たとえば、Ansible は、デフォルトで、このリポジトリー構造から collection1 と collection2 の両方をインストールします。"
 
-#: ../../rst/shared_snippets/installing_collections_git_repo.txt:64
-msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate which path ansible-galaxy should inspect for metadata file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file or ``MANIFEST.json`` file)."
-msgstr "異なるリポジトリー構造がある場合や、コレクションのサブセットのみをインストールする場合は、URI の最後にフラグメントを追加して (任意のコンマ区切りバージョンの前）、ansible-galaxy がメタデータファイルを調べるパスを示すことができます。パスは、(``MANIFEST.json`` ファイルまたは ``galaxy.yml`` ファイルへのパスではなく) コレクションまたは複数のコレクションへのディレクトリーである必要があります。"
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:69
+msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate the location of the metadata file or files. The path should be a directory, not the metadata file itself. For example, to install only collection2 from the example repository with two collections:"
+msgstr "リポジトリ構造が異なる場合、またはコレクションのサブセットのみをインストールする場合は、URI の末尾（オプションのコンマ区切りバージョンの前）にフラグメントを追加して、メタデータファイルの場所を示すことができます。パスは、メタデータファイル自体ではなく、ディレクトリである必要があります。たとえば、2つのコレクションを持つサンプルリポジトリからcollection2のみをインストールするには、次のようにします。"
+
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:75
+msgid "In some repositories, the main directory corresponds to the namespace:"
+msgstr "リポジトリーによっては、メインのディレクトリーは名前空間に対応します。"
+
+#: ../../rst/shared_snippets/installing_collections_git_repo.txt:97
+msgid "You can install all collections in this repository, or install one collection from a specific commit:"
+msgstr "このリポジトリーのすべてのコレクションをインストールするか、特定のコミットから 1 つのコレクションをインストールできます。"
 
 #: ../../rst/galaxy/user_guide.rst:92
 msgid "Listing installed collections"
@@ -530,7 +586,7 @@ msgstr "``ansible-galaxy`` クライアントの設定"
 
 #: ../../rst/shared_snippets/galaxy_server_list.txt:3
 msgid "By default, ``ansible-galaxy`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`)."
-msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載）。"
+msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載)。"
 
 #: ../../rst/shared_snippets/galaxy_server_list.txt:5
 msgid "You can use either option below to configure ``ansible-galaxy collection`` to use other servers (such as Red Hat Automation Hub or a custom Galaxy server):"
@@ -538,7 +594,7 @@ msgstr "以下のオプションを使用して、他のサーバー (Red Hat Au
 
 #: ../../rst/shared_snippets/galaxy_server_list.txt:7
 msgid "Set the server list in the :ref:`galaxy_server_list` configuration option in :ref:`ansible_configuration_settings_locations`."
-msgstr "「:ref:`ansible_configuration_settings_locations`」の「:ref:`galaxy_server_list`」設定オプションにサーバーリストを設定します。"
+msgstr ":ref:`ansible_configuration_settings_locations` の :ref:`galaxy_server_list` 設定オプションにサーバーリストを設定します。"
 
 #: ../../rst/shared_snippets/galaxy_server_list.txt:8
 msgid "Use the ``--server`` command line argument to limit to an individual server."
@@ -578,53 +634,61 @@ msgstr "各サーバー名に ``auth_url`` オプションを設定します。"
 
 #: ../../rst/shared_snippets/galaxy_server_list.txt:24
 msgid "Set the API token for each server name. Go to https://cloud.redhat.com/ansible/automation-hub/token/ and click ::guilabel:`Get API token` from the version dropdown to copy your API token."
-msgstr "各サーバー名の API トークンを設定します。https://cloud.redhat.com/ansible/automation-hub/token/ に、バージョンドロップダウンリストから ::guilabel:`Get API token` をクリックして API トークンをコピーします。"
+msgstr "各サーバー名の API トークンを設定します。https://cloud.redhat.com/ansible/automation-hub/token/ で、バージョンドロップダウンリストから ::guilabel:`Get API token` をクリックして API トークンをコピーします。"
 
 #: ../../rst/shared_snippets/galaxy_server_list.txt:26
 msgid "The following example shows how to configure multiple servers:"
 msgstr "以下の例は、複数のサーバーを設定する方法を示しています。"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:52
+#: ../../rst/shared_snippets/galaxy_server_list.txt:58
 msgid "You can use the ``--server`` command line argument to select an explicit Galaxy server in the ``server_list`` and the value of this argument should match the name of the server. To use a server not in the server list, set the value to the URL to access that server (all servers in the server list will be ignored). Also you cannot use the ``--api-key`` argument for any of the predefined servers. You can only use the ``api_key`` argument if you did not define a server list or if you specify a URL in the ``--server`` argument."
 msgstr "``--server`` コマンドライン引数を使用して ``server_list`` で明示的な Galaxy サーバーを選択し、この引数の値はサーバー名と一致する必要があります。サーバー一覧にないサーバーを使用する場合は、そのサーバーにアクセスする URL に値を設定します (サーバーリスト内のすべてのサーバーは無視されます)。また、事前定義されたサーバーのいずれかに ``--api-key`` 引数を使用することはできません。サーバーの一覧を定義していない場合、または ``--server`` に URL を指定した場合限り、``api_key`` 引数を使用できます。"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:56
+#: ../../rst/shared_snippets/galaxy_server_list.txt:62
 msgid "**Galaxy server list configuration options**"
 msgstr "**Galaxy サーバー一覧設定オプション**"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:58
-msgid "The :ref:`galaxy_server_list` option is a list of server identifiers in a prioritized order. When searching for a collection, the install process will search in that order, for example, ``automation_hub`` first, then ``my_org_hub``, ``release_galaxy``, and finally ``test_galaxy`` until the collection is found. The actual Galaxy instance is then defined under the section ``[galaxy_server.{{ id }}]`` where ``{{ id }}`` is the server identifier defined in the list. This section can then define the following keys:"
-msgstr ":ref:`galaxy_server_list` オプションは、優先順位が付けられたサーバー識別子の一覧です。コレクションを検索する場合、インストールプロセスは次の順序で検索します。たとえば、``automation_hub`` を検索してから、``my_org_hub``、``release_galaxy``、最後に ``test_galaxy`` で、コレクションが見つかるまで行います。次に、実際の Galaxy インスタンスが ``[galaxy_server.{{ id }}]`` セクションで定義され。ここでは、``{{ id }}`` は、一覧で定義されているサーバー識別子です。このセクションでは、次のキーを定義できます。"
-
 #: ../../rst/shared_snippets/galaxy_server_list.txt:64
+msgid "The :ref:`galaxy_server_list` option is a list of server identifiers in a prioritized order. When searching for a collection, the install process will search in that order, for example, ``automation_hub`` first, then ``my_org_hub``, ``release_galaxy``, and finally ``test_galaxy`` until the collection is found. The actual Galaxy instance is then defined under the section ``[galaxy_server.{{ id }}]`` where ``{{ id }}`` is the server identifier defined in the list. This section can then define the following keys:"
+msgstr ":ref:`galaxy_server_list` オプションは、優先順位が付けられたサーバー識別子の一覧です。コレクションを検索する場合、インストールプロセスは次の順序で検索します。たとえば、``automation_hub`` を検索してから、``my_org_hub``、``release_galaxy``、最後に ``test_galaxy`` で、コレクションが見つかるまで行います。次に、実際の Galaxy インスタンスが ``[galaxy_server.{{ id }}]`` セクションで定義されます。``{{ id }}`` は、一覧で定義されているサーバー識別子です。このセクションでは、次のキーを定義できます。"
+
+#: ../../rst/shared_snippets/galaxy_server_list.txt:70
 msgid "``url``: The URL of the Galaxy instance to connect to. Required."
 msgstr "``url``: 接続する Galaxy インスタンスの URL。必須。"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:65
+#: ../../rst/shared_snippets/galaxy_server_list.txt:71
 msgid "``token``: An API token key to use for authentication against the Galaxy instance. Mutually exclusive with ``username``."
 msgstr "``token``: Galaxy インスタンスに対する認証に使用する API トークンキー。``username`` と相互に排他的です。"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:66
+#: ../../rst/shared_snippets/galaxy_server_list.txt:72
 msgid "``username``: The username to use for basic authentication against the Galaxy instance. Mutually exclusive with ``token``."
 msgstr "``username``: Galaxy インスタンスに対する Basic 認証に使用するユーザー名。``token`` と相互に排他的です。"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:67
+#: ../../rst/shared_snippets/galaxy_server_list.txt:73
 msgid "``password``: The password to use, in conjunction with ``username``, for basic authentication."
 msgstr "``password``: Basic 認証に使用するパスワード。``username`` と併用します。"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:68
+#: ../../rst/shared_snippets/galaxy_server_list.txt:74
 msgid "``auth_url``: The URL of a Keycloak server 'token_endpoint' if using SSO authentication (for example, Automation Hub). Mutually exclusive with ``username``. Requires ``token``."
 msgstr "``auth_url``: SSO 認証 (例: Automation Hub) を使用する場合は Keycloak サーバー「token_endpoint」の URL です。``username`` と相互に排他的です。``token`` が必要です。"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:70
+#: ../../rst/shared_snippets/galaxy_server_list.txt:75
+msgid "``validate_certs``: Whether or not to verify TLS certificates for the Galaxy server. This defaults to True unless the ``--ignore-certs`` option is provided or ``GALAXY_IGNORE_CERTS`` is configured to True."
+msgstr "``validate_certs``: Galaxy サーバーの TLS 証明書を検証するかどうか。これは、``--ignore-certs`` オプションが提供されるか、``GALAXY_IGNORE_CERTS`` が True に設定されている場合を除き、デフォルトで True に設定されます。"
+
+#: ../../rst/shared_snippets/galaxy_server_list.txt:76
+msgid "``client_id``: The Keycloak token's client_id to use for authentication. Requires ``auth_url`` and ``token``. The default ``client_id`` is cloud-services to work with Red Hat SSO."
+msgstr "``client_id``: 認証に使用する Keycloak トークンの client_id。``auth_url`` および ``token`` が必要です。デフォルトの ``client_id`` は、Red Hat SSO と連携するクラウドサービスです。"
+
+#: ../../rst/shared_snippets/galaxy_server_list.txt:78
 msgid "As well as defining these server options in the ``ansible.cfg`` file, you can also define them as environment variables. The environment variable is in the form ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` where ``{{ id }}`` is the upper case form of the server identifier and ``{{ key }}`` is the key to define. For example I can define ``token`` for ``release_galaxy`` by setting ``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token``."
 msgstr "これらのサーバーオプションを ``ansible.cfg`` ファイルで定義するだけでなく、それらを環境変数として定義することもできます。環境変数は ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` の形式です。``{{ id }}`` はサーバー識別子の大文字形式であり、``{{ key }}`` は定義するキーです。たとえば、``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token`` を設定することで、``release_galaxy`` に ``token`` を定義することができます。"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:75
+#: ../../rst/shared_snippets/galaxy_server_list.txt:83
 msgid "For operations that use only one Galaxy server (for example, the ``publish``, ``info``, or ``install`` commands). the ``ansible-galaxy collection`` command uses the first entry in the ``server_list``, unless you pass in an explicit server with the ``--server`` argument."
 msgstr "Galaxy サーバー 1 つだけを使用する操作 (例: ``publish`` コマンド、``info`` コマンド、または ``install`` コマンド) の場合、``ansible-galaxy collection`` コマンドは、``--server`` 引数を使用して明示的なサーバーに渡しない限り、``server_list`` の最初のエントリーを使用します。"
 
-#: ../../rst/shared_snippets/galaxy_server_list.txt:79
+#: ../../rst/shared_snippets/galaxy_server_list.txt:87
 msgid "Once a collection is found, any of its requirements are only searched within the same Galaxy instance as the parent collection. The install process will not search for a collection requirement in a different Galaxy instance."
 msgstr "コレクションが見つかると、その要件は親コレクションと同じ Galaxy インスタンス内でのみ検索されます。インストールプロセスでは、別の Galaxy インスタンスでコレクション要件を検索しません。"
 
@@ -941,3 +1005,39 @@ msgstr "既知のディレクトリー構造の再利用可能なタスク、ハ
 #~ msgid "`.. versionadded:: 2.10`"
 #~ msgstr ""
 
+#~ msgid "`irc.freenode.net <http://irc.freenode.net>`_"
+#~ msgstr "`irc.freenode.net <http://irc.freenode.net>`_"
+
+#~ msgid "The supported keys for collection requirement entries are ``name``, ``version``, ``source``, and ``type``."
+#~ msgstr "コレクション要件エントリーでサポートされるキーは ``name``、``version``、``source``、および ``type`` です。"
+
+#~ msgid "The ``version`` key can take in the same range identifier format documented above. If you're installing a collection from a git repository instead of a built collection artifact, the ``version`` key refers to a `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_."
+#~ msgstr "``version`` キーは、上記の範囲識別子の形式を取ることができます。ビルドコレクションアーティファクトではなく git リポジトリーからコレクションをインストールする場合は、``version`` キーは `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ を参照します。"
+
+#~ msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` or ``MANIFEST.json`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ version (for example, a commit or tag)."
+#~ msgstr "コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーに URI を提供することにより、git リポジトリーにコレクションをインストールできます。コレクションには、``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルが必要です。このコレクションは、ディレクトリーからの will-be コレクションアーティファクトデータを生成するのに使用されます。URI の接頭辞には ``git+`` (または ssh 認証でプライベートリポジトリーを使用する ``git@``）を付け、必要に応じてコンマ区切りの `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ バージョン (コミットまたはタグなど) をサポートする必要があります。"
+
+#~ msgid "Embedding credentials into a git URI is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_, `netrc <https://linux.die.net/man/5/netrc>`_ or `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_/`url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ in Git config to prevent your creds from being exposed in logs."
+#~ msgstr "認証情報を git URI に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_、`netrc <https://linux.die.net/man/5/netrc>`_、または `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_/`url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ で、クレジットがログに公開されないようにします。"
+
+#~ msgid "In a ``requirements.yml`` file, you can also use the ``type`` and ``version`` keys in addition to using the ``git+repo,version`` syntax for the collection name."
+#~ msgstr "``requirements.yml`` ファイルでは、コレクション名の ``git+repo,version`` 構文を使用する他に、``type`` キーおよび ``version`` キーを使用することもできます。"
+
+#~ msgid "Git repositories can be used for collection dependencies as well. This can be helpful for local development and testing but built/published artifacts should only have dependencies on other artifacts."
+#~ msgstr "git リポジトリーはコレクションの依存関係にも使用できます。これは、ローカル開発およびテストに役立ちますが、ビルド/公開されたアーティファクトには他のアーティファクトへの依存関係のみが必要です。"
+
+#~ msgid "Default repository search locations"
+#~ msgstr "デフォルトのリポジトリー検索の場所"
+
+#~ msgid "There are two paths searched in a repository for collections by default."
+#~ msgstr "デフォルトでは、コレクション用のリポジトリーで 2 つのパスが検索されます。"
+
+#~ msgid "The second is a ``galaxy.yml`` or ``MANIFEST.json`` file in each directory in the repository path (one level deep). In this scenario, each directory with a metadata file is installed as a collection."
+#~ msgstr "2 つ目は、リポジトリーパス (1 レベルの深さ) の各ディレクトリーの ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ここでは、メタデータファイルが含まれる各ディレクトリーがコレクションとしてインストールされます)。"
+
+#~ msgid "Specifying the location to search for collections"
+#~ msgstr "コレクションを検索する場所の指定"
+
+#~ msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate which path ansible-galaxy should inspect for metadata file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file or ``MANIFEST.json`` file)."
+#~ msgstr "異なるリポジトリー構造がある場合や、コレクションのサブセットのみをインストールする場合は、URI の最後にフラグメントを追加して (任意のコンマ区切りバージョンの前）、ansible-galaxy がメタデータファイルを調べるパスを示すことができます。パスは、(``MANIFEST.json`` ファイルまたは ``galaxy.yml`` ファイルへのパスではなく) コレクションまたは複数のコレクションへのディレクトリーである必要があります。"
+

docs/docsite/rst/locales/ja/LC_MESSAGES/index.po

@@ -7,7 +7,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: Ansible devel\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2021-03-08 20:25+0100\n"
+"POT-Creation-Date: 2021-10-05 13:53+0200\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
@@ -17,30 +17,30 @@ msgstr ""
 "Generated-By: Babel 2.9.0\n"
 
 #: ../../rst/2.10_index.rst:23 ../../rst/ansible_index.rst:25
-#: ../../rst/core_index.rst:30
+#: ../../rst/core_index.rst:36
 msgid "Installation, Upgrade & Configuration"
 msgstr "インストール、アップグレード、および設定"
 
-#: ../../rst/core_index.rst:37
+#: ../../rst/core_index.rst:43
 msgid "Using Ansible Core"
 msgstr "Ansible Core の使用"
 
-#: ../../rst/core_index.rst:43
+#: ../../rst/core_index.rst:49
 msgid "Contributing to Ansible Core"
 msgstr "Ansible Core への貢献"
 
 #: ../../rst/2.10_index.rst:42 ../../rst/ansible_index.rst:44
-#: ../../rst/core_index.rst:49
+#: ../../rst/core_index.rst:55
 msgid "Extending Ansible"
 msgstr "Ansible の拡張"
 
 #: ../../rst/2.10_index.rst:73 ../../rst/ansible_index.rst:75
-#: ../../rst/core_index.rst:56
+#: ../../rst/core_index.rst:62
 msgid "Reference & Appendices"
 msgstr "参照および付録"
 
 #: ../../rst/2.10_index.rst:102 ../../rst/ansible_index.rst:100
-#: ../../rst/core_index.rst:80
+#: ../../rst/core_index.rst:86
 msgid "Roadmaps"
 msgstr "ロードマップ"
 
@@ -57,34 +57,49 @@ msgstr "ansible-core の概要"
 msgid "Ansible is an IT automation tool.  It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates."
 msgstr "Ansible は IT 自動化ツールです。このツールを使用すると、システムの構成、ソフトウェアの展開、より高度な IT タスク (継続的なデプロイメント、ダウンタイムなしのローリング更新など) のオーケストレーションが可能になります。"
 
-#: ../../rst/2.10_index.rst:11 ../../rst/ansible_index.rst:13
 #: ../../rst/core_index.rst:15
+msgid "Ansible core, or ``ansible-core`` is the main building block and architecture for Ansible, and includes:"
+msgstr "Ansible コアまたは ``ansible-core`` は Ansible の主要なビルディングブロックおよびアーキテクチャーであり、以下が含まれます。"
+
+#: ../../rst/core_index.rst:17
+msgid "CLI tools such as ``ansible-playbook``, ``ansible-doc``. and others for driving and interacting with automation."
+msgstr "自動化で動作や対話を行う ``ansible-playbook``、``ansible-doc`` などの CLI ツール"
+
+#: ../../rst/core_index.rst:18
+msgid "The Ansible language that uses YAML to create a set of rules for developing Ansible Playbooks and includes functions such as conditionals, blocks, includes, loops, and other Ansible imperatives."
+msgstr "YAML を使用して Ansible Playbook を開発するための一連のルールを作成し、conditional、block、include、include、その他の Ansible 命令などの関数を追加する Ansible 言語"
+
+#: ../../rst/core_index.rst:19
+msgid "An architectural framework that allows extensions through Ansible collections."
+msgstr "Ansible コレクションで拡張機能を可能にするアーキテクチャーフレームワーク"
+
+#: ../../rst/2.10_index.rst:11 ../../rst/ansible_index.rst:13
+#: ../../rst/core_index.rst:21
 msgid "Ansible's main goals are simplicity and ease-of-use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with other transports and pull modes as alternatives), and a language that is designed around auditability by humans--even those not familiar with the program."
 msgstr "Ansible の主な目標は、簡単で使いやすいことです。また、セキュリティーおよび信頼性に重点を置いており、最小限の可動部品、トランスポート用の OpenSSH の使用 (代替として他のトランスポートとプルモードを使用)、およびプログラムに精通していない人でも監査を可能にする言語も備えています。"
 
 #: ../../rst/2.10_index.rst:13 ../../rst/ansible_index.rst:15
-#: ../../rst/core_index.rst:17
+#: ../../rst/core_index.rst:23
 msgid "We believe simplicity is relevant to all sizes of environments, so we design for busy users of all types: developers, sysadmins, release engineers, IT managers, and everyone in between. Ansible is appropriate for managing all environments, from small setups with a handful of instances to enterprise environments with many thousands of instances."
 msgstr "簡素化はあらゆる規模の環境に関連しており、開発者、システム管理者、リリースエンジニア、IT マネージャーなど、あらゆるタイプのビジーユーザー向けに設計されています。Ansible は、わずかなインスタンスしかない小規模のセットアップから、インスタンスが数千にもなるエンタープライズ環境まで、すべての環境を管理するのに適しています。"
 
 #: ../../rst/2.10_index.rst:15 ../../rst/ansible_index.rst:17
-#: ../../rst/core_index.rst:19
+#: ../../rst/core_index.rst:25
 msgid "You can learn more at `AnsibleFest <https://www.ansible.com/ansiblefest>`_, the annual event for all Ansible contributors, users, and customers hosted by Red Hat. AnsibleFest is the place to connect with others, learn new skills, and find a new friend to automate with."
 msgstr "詳細は、`AnsibleFest <https://www.ansible.com/ansiblefest>`_ (Red Hat が開催する、Ansible のすべての貢献者、ユーザー、および顧客のための毎年恒例のイベント) で学ぶことができます。AnsibleFest は、他の人とつながり、新しいスキルを学び、自動化に興味のある人達と知り合うためのイベントです。"
 
 #: ../../rst/2.10_index.rst:17 ../../rst/ansible_index.rst:19
-#: ../../rst/core_index.rst:21
+#: ../../rst/core_index.rst:27
 msgid "Ansible manages machines in an agent-less manner. There is never a question of how to upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled.  Because OpenSSH is one of the most peer-reviewed open source components, security exposure is greatly reduced. Ansible is decentralized--it relies on your existing OS credentials to control access to remote machines. If needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems."
 msgstr "Ansible は、エージェントを使用せずにマシンを管理します。リモートデーモンをアップグレードする方法や、デーモンがアンインストールされているためにシステムを管理できないという問題はありません。OpenSSH は、相互評価が最も行われるオープンソースコンポーネントの 1 つであるため、セキュリティーの危険性は大幅に軽減されます。Ansible は分散化されており、既存の OS 認証情報を使用して、リモートマシンへのアクセスを制御します。必要に応じて、Ansible は、Kerberos、LDAP、およびその他の集中認証管理システムに簡単に接続できます。"
 
-#: ../../rst/2.10_index.rst:19 ../../rst/ansible_index.rst:21
-#: ../../rst/core_index.rst:23
-msgid "This documentation covers the version of Ansible noted in the upper left corner of this page. We maintain multiple versions of Ansible and of the documentation, so please be sure you are using the version of the documentation that covers the version of Ansible you're using. For recent features, we note the version of Ansible where the feature was added."
-msgstr "本ドキュメントは、本ページの左上にある Ansible のバージョンを説明します。Red Hat は、複数のバージョンの Ansible とドキュメントを提供しているため、参照しているドキュメントが、お使いの Ansible のバージョンのものであることを確認してください。最新の機能については、この機能が追加された Ansible のバージョンを記載しています。"
+#: ../../rst/core_index.rst:29
+msgid "This documentation covers the version of ``ansible-core`` noted in the upper left corner of this page. We maintain multiple versions of ``ansible-core`` and of the documentation, so please be sure you are using the version of the documentation that covers the version of Ansible you're using. For recent features, we note the version of Ansible where the feature was added."
+msgstr "本ドキュメントは、本ページの左上に示されている ``ansible-core`` のバージョンについて説明します。Red Hat は、複数のバージョンの ``ansible-core`` とドキュメントを提供しているため、参照しているドキュメントが、お使いの Ansible のバージョンのものであることを確認してください。最新の機能については、その機能が追加された Ansible のバージョンが記載されています。"
 
-#: ../../rst/core_index.rst:26
+#: ../../rst/core_index.rst:32
 msgid "``ansible-core`` releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins, hosted in collections since version 2.10, much more quickly."
-msgstr "``ansible-core`` は、年に約 2 回、新しいメジャーリリースをリリースします。コアアプリケーションは、言語の設計および設定の単純性が重視され、その進化は若干保守的となります。貢献者はバージョン 2.10 以降のコレクションでホストされるモジュールとプラグインを、はるかに迅速に開発および変更します。"
+msgstr "``ansible-core`` は、年に約 2 回、新しいメジャーリリースをリリースします。コアアプリケーションは、言語の設計および設定の単純性が重視され、その進化は若干保守的となります。バージョン 2.10 以降のコレクションで提供されるモジュールとプラグインは、貢献者によりはるかに迅速に開発および変更されます。"
 
 #: ../../rst/2.10_index.rst:30 ../../rst/ansible_index.rst:32
 msgid "Using Ansible"
@@ -114,9 +129,13 @@ msgstr "Ansible ドキュメント"
 msgid "About Ansible"
 msgstr "Ansible の概要"
 
+#: ../../rst/2.10_index.rst:19 ../../rst/ansible_index.rst:21
+msgid "This documentation covers the version of Ansible noted in the upper left corner of this page. We maintain multiple versions of Ansible and of the documentation, so please be sure you are using the version of the documentation that covers the version of Ansible you're using. For recent features, we note the version of Ansible where the feature was added."
+msgstr "本ドキュメントは、本ページの左上に示されている Ansible のバージョンについて説明します。Red Hat は、複数のバージョンの Ansible とドキュメントを提供しているため、参照しているドキュメントが、お使いの Ansible のバージョンのものであることを確認してください。最新の機能については、その機能が追加された Ansible のバージョンが記載されています。"
+
 #: ../../rst/2.10_index.rst:21 ../../rst/ansible_index.rst:23
 msgid "Ansible releases a new major release approximately twice a year. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. Contributors develop and change modules and plugins, hosted in collections since version 2.10, much more quickly."
-msgstr "Ansible は、年に約 2 回、新しいメジャーリリースをリリースします。コアアプリケーションは、言語の設計および設定の単純性が重視され、その進化は若干保守的となります。貢献者はバージョン 2.10 以降のコレクションでホストされるモジュールとプラグインを、はるかに迅速に開発および変更します。"
+msgstr "Ansible は、年に約 2 回、新しいメジャーリリースをリリースします。コアアプリケーションは、言語の設計および設定の単純性が重視され、その進化は若干保守的となります。バージョン 2.10 以降のコレクションで提供されるモジュールとプラグインは、貢献者によりはるかに迅速に開発および変更されます。"
 
 #: ../../rst/2.10_index.rst:98
 msgid "Release Notes"

docs/docsite/rst/locales/ja/LC_MESSAGES/roadmap.po

@@ -7,7 +7,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: Ansible devel\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2021-03-08 20:25+0100\n"
+"POT-Creation-Date: 2021-11-09 14:07+0100\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
@@ -26,13 +26,15 @@ msgstr "本リリーススケジュールには、`ansible <https://pypi.org/pro
 
 #: ../../rst/roadmap/COLLECTIONS_2_10.rst:11
 #: ../../rst/roadmap/ROADMAP_2_10.rst:11 ../../rst/roadmap/ROADMAP_2_11.rst:11
-#: ../../rst/roadmap/ROADMAP_2_6.rst:8 ../../rst/roadmap/ROADMAP_2_7.rst:8
-#: ../../rst/roadmap/ROADMAP_2_8.rst:9 ../../rst/roadmap/ROADMAP_2_9.rst:9
+#: ../../rst/roadmap/ROADMAP_2_12.rst:11 ../../rst/roadmap/ROADMAP_2_6.rst:8
+#: ../../rst/roadmap/ROADMAP_2_7.rst:8 ../../rst/roadmap/ROADMAP_2_8.rst:9
+#: ../../rst/roadmap/ROADMAP_2_9.rst:9
 msgid "Release Schedule"
 msgstr "リリーススケジュール"
 
 #: ../../rst/roadmap/COLLECTIONS_2_10.rst:13
 #: ../../rst/roadmap/ROADMAP_2_10.rst:19 ../../rst/roadmap/ROADMAP_2_11.rst:19
+#: ../../rst/roadmap/ROADMAP_2_12.rst:19
 msgid "Dates subject to change."
 msgstr "日付は変更する可能性があります。"
 
@@ -81,8 +83,8 @@ msgid "After this date only changes blocking a release are accepted."
 msgstr "この日付以降は、リリースをブロックする変更のみが許可されます。"
 
 #: ../../rst/roadmap/COLLECTIONS_2_10.rst:34
-msgid "Collections will only be updated to a new version if a blocker is approved.  Collection owners should discuss any blockers at the community IRC meeting (on 9-17) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda <https://github.com/ansible/community/issues/539>`_."
-msgstr "コレクションは、ブロッカーが承認された場合にのみ新規バージョンに更新されます。コレクションの所有者は、修正のためにコレクションのバージョンを上げるかどうかを決めるために、コミュニティー IRC ミーティングのブロッカーについて (9 ~ 17 上) 議論する必要があります。`Community IRC meeting agenda <https://github.com/ansible/community/issues/539>`_ を参照してください。"
+msgid "Collections will only be updated to a new version if a blocker is approved.  Collection owners should discuss any blockers at the community meeting (on 9-17) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda <https://github.com/ansible/community/issues/539>`_."
+msgstr "コレクションは、ブロッカーが承認された場合にのみ新規バージョンに更新されます。コレクションの所有者は、修正のためにコレクションのバージョンを上げるかどうかを決めるために、コミュニティーミーティングのブロッカーについて (9 ~ 17 上) 議論する必要があります。`Community meeting agenda <https://github.com/ansible/community/issues/539>`_ を参照してください。"
 
 #: ../../rst/roadmap/COLLECTIONS_2_10.rst:36
 msgid "** Additional release candidates to be published as needed as blockers are fixed **"
@@ -96,34 +98,36 @@ msgstr "2020 年 09 月 22 日: Ansible-2.10 GA リリース日。"
 msgid "Ansible-2.10.x patch releases will occur roughly every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x.  Ansible-2.10.x patch releases may contain new features but not backwards incompatibilities.  In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed (example: Ansible-2.10 ships with community-crypto-1.1.0; ansible-2.10.1 may ship with community-crypto-1.2.0 but would not ship with community-crypto-2.0.0)."
 msgstr "コレクションに変更が加えられた場合、または後で ansible-base-2.10.x へのアップグレードを強制する必要があると見なされた場合、Ansible-2.10.x パッチのリリースは約 3 週間ごとに行われます。Ansible-2.10.x パッチリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときは変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-2.10 が community-crypto-1.1.0 に同梱されると、ansible-2.10.1 は community-crypto-1.2.0 に同梱される場合がありますが、community-crypto-2.0.0 には同梱されません。"
 
-#: ../../rst/roadmap/COLLECTIONS_2_10.rst:42
-msgid "Breaking changes may be introduced in ansible-2.11.0 although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before being changed incompatibly."
-msgstr "ansible-2.11.0 で重大な変更が導入される可能性がありますが、コレクションの所有者は、非互換性になる前に少なくとも 1 つの Ansible リリースに含まれる非推奨期間を使用することが推奨されます。"
+#: ../../rst/roadmap/COLLECTIONS_2_10.rst:45
+msgid "Minor releases will stop when :ref:`Ansible-3 <ansible_3_roadmap>` is released.  See the :ref:`Release and Maintenance Page <release_and_maintenance>` for more information."
+msgstr ":ref:`Ansible-3 <ansible_3_roadmap>` がリリースされると、マイナーリリースは停止します。詳細は「:ref:`リリースおよびメンテナンスページ <release_and_maintenance>`」を参照してください。"
 
-#: ../../rst/roadmap/COLLECTIONS_2_10.rst:44
-msgid "The rough schedule for Ansible-2.11 and beyond (such as how many months we'll aim for between versions) is still to be discussed and likely will be made after 2.10.0 has been released."
-msgstr "Ansible-2.11 以降の大まかなスケジュール (バージョン間の目標数など) は依然として検討されており、2.10.0 のリリース後に行われる可能性があります。"
+#: ../../rst/roadmap/COLLECTIONS_2_10.rst:48
+msgid "Breaking changes may be introduced in ansible-3.0 although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before being changed incompatibly."
+msgstr "ansible-3.0 で重大な変更が導入される可能性がありますが、コレクションの所有者は、非互換性になる前に少なくとも 1 つの Ansible リリースに含まれる非推奨期間を使用することが推奨されます。"
 
-#: ../../rst/roadmap/COLLECTIONS_2_10.rst:46
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:45
-#: ../../rst/roadmap/COLLECTIONS_4.rst:48
-msgid "For more information, reach out on a mailing list or an IRC channel - see :ref:`communication` for more details."
-msgstr "詳細は、メーリングリストまたは IRC チャンネルをご利用ください。「:ref:`communication`」を参照してください。"
+#: ../../rst/roadmap/COLLECTIONS_2_10.rst:51
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:52
+#: ../../rst/roadmap/COLLECTIONS_4.rst:55
+#: ../../rst/roadmap/COLLECTIONS_5.rst:58
+msgid "For more information, reach out on a mailing list or a chat channel - see :ref:`communication` for more details."
+msgstr "詳細は、メーリングリストまたはチャットチャンネルをご利用ください。「:ref:`communication`」を参照してください。"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:3
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:5
 msgid "Ansible project 3.0"
 msgstr "Ansible プロジェクト 3.0"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:5
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:7
 msgid "This release schedule includes dates for the `ansible <https://pypi.org/project/ansible/>`_ package, with a few dates for the `ansible-base <https://pypi.org/project/ansible-base/>`_ package as well. All dates are subject to change. Ansible 3.x.x includes ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for the most recent updates on ``ansible-base``."
 msgstr "本リリーススケジュールには、`ansible <https://pypi.org/project/ansible/>`_ パッケージの日付が含まれており、`ansible-base <https://pypi.org/project/ansible-base/>`_ パッケージの日付もいくつか含まれています。この日付はすべて変更する可能性があります。Ansible 3.x.x には ``ansible-base`` 2.10 が含まれます。``ansible-base`` の最新の更新については、「:ref:`base_roadmap_2_10`」を参照してください。"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:11
-#: ../../rst/roadmap/COLLECTIONS_4.rst:12
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:13
+#: ../../rst/roadmap/COLLECTIONS_4.rst:14
+#: ../../rst/roadmap/COLLECTIONS_5.rst:14
 msgid "Release schedule"
 msgstr "リリーススケジュール"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:15
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:17
 msgid "Ansible is switching from its traditional versioning scheme to `semantic versioning <https://semver.org/>`_ starting with this release.  So this version is 3.0.0 instead of 2.11.0."
 msgstr "Ansible は、本リリース以降の従来のバージョン管理スキームから `semantic versioning <https://semver.org/>`_ に切り替えるため、このバージョンは 2.11.0 ではなく 3.0.0 になります。"
 
@@ -131,7 +135,7 @@ msgstr "Ansible は、本リリース以降の従来のバージョン管理ス
 msgid "2020-12-16"
 msgstr "2020 年 12 月 16 日"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:19
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:21
 msgid "Finalize rules for net-new collections submitted for the ansible release."
 msgstr "Ansible リリースに送信された net-new コレクションのルールのファイナライズ。"
 
@@ -139,7 +143,7 @@ msgstr "Ansible リリースに送信された net-new コレクションのル
 msgid "2021-01-27"
 msgstr "2021 年 01 月 27 日"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:20
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:22
 msgid "Final day for new collections to be **reviewed and approved**. They MUST be submitted prior to this to give reviewers a chance to look them over and for collection owners to fix any problems."
 msgstr "新しいコレクションの **レビューおよび承認** の最終日。レビュー担当者が新しいコレクションを確認し、コレクションの所有者が問題を修正する機会を得るために、この日付までに提出する必要があります。"
 
@@ -147,7 +151,7 @@ msgstr "新しいコレクションの **レビューおよび承認** の最終
 msgid "2021-02-02"
 msgstr "2021 年 02 月 02 日"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:23
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:25
 msgid "Ansible-3.0.0-beta1 -- feature freeze [1]_"
 msgstr "ansible-3.0.0-beta1 -- 機能フリーズ [1]_"
 
@@ -155,7 +159,7 @@ msgstr "ansible-3.0.0-beta1 -- 機能フリーズ [1]_"
 msgid "2021-02-09"
 msgstr "2021 年 02 月 09 日"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:24
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:26
 msgid "Ansible-3.0.0-rc1 -- final freeze [2]_ [3]_"
 msgstr "Ansible-3.0.0-rc1 -- 最終フリーズ [2]_ [3]_"
 
@@ -163,7 +167,7 @@ msgstr "Ansible-3.0.0-rc1 -- 最終フリーズ [2]_ [3]_"
 msgid "2021-02-16"
 msgstr "2021 年 02 月 16 日"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:25
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:27
 msgid "Release of Ansible-3.0.0"
 msgstr "Ansible-3.0.0 のリリース"
 
@@ -171,51 +175,55 @@ msgstr "Ansible-3.0.0 のリリース"
 msgid "2021-03-09"
 msgstr "2021 年 03 月 09 日"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:26
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:28
 msgid "Release of Ansible-3.1.0 (bugfix + compatible features: every three weeks)"
 msgstr "Ansible-3.1.0 のリリース (バグ修正 + 互換性のある機能: 3 週間ごと)"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:28
-#: ../../rst/roadmap/COLLECTIONS_4.rst:31
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:30
 msgid "No new modules or major features accepted after this date. In practice this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1.  It would not ship with community-crypto-2.2.0."
 msgstr "この日付以降は、新しいモジュールやメジャー機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community-crypto-2.1.0 であれば、ansible-3.0.0 は community-crypto-2.1.1 に同梱される可能性がありました。community-crypto-2.2.0 は同梱されません。"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:30
-#: ../../rst/roadmap/COLLECTIONS_4.rst:33
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:32
+#: ../../rst/roadmap/COLLECTIONS_4.rst:35
+#: ../../rst/roadmap/COLLECTIONS_5.rst:38
 msgid "After this date only changes blocking a release are accepted.  Accepted changes require creating a new rc and may slip the final release date."
 msgstr "この日付以降は、リリースをブロックする変更のみが許可されます。受け入れ可能な変更には、新しい rc を作成する必要があり、最終リリース日は処理されない可能性があります。"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:31
-#: ../../rst/roadmap/COLLECTIONS_4.rst:34
-msgid "Collections will only be updated to a new version if a blocker is approved.  Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda <https://github.com/ansible/community/issues/539>`_."
-msgstr "コレクションは、ブロッカーが承認された場合にのみ新しいバージョンに更新されます。コレクションの所有者は、(フリーズの前に) 修正のためにコレクションのバージョンを上げるかどうかを決定するために、コミュニティー IRC ミーティングのブロッカーについて検討する必要があります。`コミュニティー IRC ミーティングの議題 <https://github.com/ansible/community/issues/539>`_ を参照してください。"
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:33
+msgid "Collections will only be updated to a new version if a blocker is approved.  Collection owners should discuss any blockers at a community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda <https://github.com/ansible/community/issues/539>`_."
+msgstr "コレクションは、ブロッカーが承認された場合にのみ新しいバージョンに更新されます。コレクションの所有者は、(フリーズの前に) 修正のためにコレクションのバージョンを上げるかどうかを決定するために、コミュニティーミーティングのブロッカーについて検討する必要があります。`Community meeting agenda <https://github.com/ansible/community/issues/539>`_ を参照してください。"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:36
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:38
 msgid "Breaking changes may be introduced in Ansible 3.0.0, although we encourage collection owners to use deprecation periods that will show up in at least one Ansible release before the breaking change happens."
 msgstr "Ansible3.0.0 で重大な変更が導入される可能性がありますが、コレクションの所有者は、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに含まれる非推奨期間を使用することが推奨されます。"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:40
-#: ../../rst/roadmap/COLLECTIONS_4.rst:43
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:42
+#: ../../rst/roadmap/COLLECTIONS_4.rst:45
+#: ../../rst/roadmap/COLLECTIONS_5.rst:48
 msgid "Ansible minor releases"
 msgstr "Ansible マイナーリリース"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:42
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:44
 msgid "Ansible 3.x.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-base-2.10.x.  Ansible 3.x.x minor releases may contain new features but not backwards incompatibilities.  In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-3.0.0 ships with community-crypto-2.1.0; Ansible-3.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0)."
 msgstr "コレクションに変更が加えられた場合、または後で ansible-base-2.10.x へのアップグレードを強制する必要があると見なされた場合、Ansible 3.x.x マイナーリリースは約 3 週間ごとに行われます。Ansible 3.x.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-3.0.0 が community-crypto-2.1.0 に同梱されると、Ansible-3.1.0 は community-crypto-2.2.0 に同梱される場合がありますが、community-crypto-3.0.0 には同梱されません。"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:48
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:49
+msgid "Minor releases will stop when :ref:`Ansible-4 <ansible_4_roadmap>` is released.  See the :ref:`Release and Maintenance Page <release_and_maintenance>` for more information."
+msgstr ":ref:`Ansible-4 <ansible_4_roadmap>` がリリースされると、マイナーリリースは停止します。詳細は「:ref:`リリースおよびメンテナンスページ <release_and_maintenance>`」を参照してください。"
+
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:56
 msgid "ansible-base release"
 msgstr "ansible-base リリース"
 
-#: ../../rst/roadmap/COLLECTIONS_3_0.rst:50
+#: ../../rst/roadmap/COLLECTIONS_3_0.rst:58
 msgid "Ansible 3.x.x works with ``ansible-base`` 2.10. See :ref:`base_roadmap_2_10` for details."
 msgstr "Ansible 3.x.x は ``ansible-base`` 2.10 で動作します。詳細は、「:ref:`base_roadmap_2_10`」を参照してください。"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:3
+#: ../../rst/roadmap/COLLECTIONS_4.rst:5
 msgid "Ansible project 4.0"
 msgstr "Ansible プロジェクト 4.0"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:5
+#: ../../rst/roadmap/COLLECTIONS_4.rst:7
 msgid "This release schedule includes dates for the `ansible <https://pypi.org/project/ansible/>`_ package, with a few dates for the `ansible-core <https://pypi.org/project/ansible-core/>`_ package as well. All dates are subject to change. See :ref:`base_roadmap_2_11` for the most recent updates on ``ansible-core``."
 msgstr "本リリーススケジュールには、`ansible <https://pypi.org/project/ansible/>`_ パッケージの日付が含まれており、`ansible-core <https://pypi.org/project/ansible-core/>`_ パッケージの日付もいくつか含まれています。この日付はすべて変更される可能性があります。``ansible-core`` の最新の更新については「:ref:`base_roadmap_2_11`」を参照してください。"
 
@@ -223,15 +231,15 @@ msgstr "本リリーススケジュールには、`ansible <https://pypi.org/pro
 msgid "2021-01-26"
 msgstr "2021 年 01 月 26日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:15
-msgid "New Collections will be reviewed for inclusion in Ansible 4."
-msgstr "新しいコレクションは、Ansible 4 に含まれるようにレビューされています。"
+#: ../../rst/roadmap/COLLECTIONS_4.rst:17
+msgid "New Collections will be reviewed for inclusion in Ansible 4. Submit a request to include a new collection in this `GitHub Discussion <https://github.com/ansible-collections/ansible-inclusion/discussions/new>`_."
+msgstr "新しいコレクションは、Ansible 4 に含まれるようにレビューされます。この `GitHub ディスカッション <https://github.com/ansible-collections/ansible-inclusion/discussions/new>`_ に新しいコレクションを追加するリクエストを送信してください。"
 
 #: ../../rst/roadmap/COLLECTIONS_4.rst
 msgid "2021-03-03"
 msgstr "2021 年 03 月 03 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:16
+#: ../../rst/roadmap/COLLECTIONS_4.rst:18
 msgid "Ansible-4.0.0 alpha1 (biweekly ``ansible`` alphas.  These are timed to coincide with the start of the ``ansible-core-2.11`` pre-releases)."
 msgstr "Ansible-4.0.0 alpha1 (``ansible`` Alpha は隔週)。これらは ``ansible-core-2.11`` プレリリースの開始と合致するようにタイミングが調整されます。"
 
@@ -239,7 +247,7 @@ msgstr "Ansible-4.0.0 alpha1 (``ansible`` Alpha は隔週)。これらは ``ansi
 msgid "2021-03-16"
 msgstr "2021 年 03 月 16 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:17
+#: ../../rst/roadmap/COLLECTIONS_4.rst:19
 msgid "Ansible-4.0.0 alpha2"
 msgstr "Ansible-4.0.0 alpha2"
 
@@ -247,7 +255,7 @@ msgstr "Ansible-4.0.0 alpha2"
 msgid "2021-03-30"
 msgstr "2021 年 03 月 30 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:18
+#: ../../rst/roadmap/COLLECTIONS_4.rst:20
 msgid "Ansible-4.0.0 alpha3"
 msgstr "Ansible-4.0.0 alpha3"
 
@@ -255,39 +263,40 @@ msgstr "Ansible-4.0.0 alpha3"
 msgid "2021-04-13"
 msgstr "2021 年 04 月 13 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:19
+#: ../../rst/roadmap/COLLECTIONS_4.rst:21
 msgid "Last day for new collections to be submitted for inclusion in Ansible 4. Note that collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion."
 msgstr "Ansible 4 に含めるために新しいコレクションを送信する最終日。コレクションを含める前に、コレクションをレビューして承認する必要があることに注意してください。すべてのコレクションをレビューする保証はありません。コレクションが早く提出されるほど、コレクションがレビューされ、必要なフィードバックが含まれるのに間に合うように対処される可能性が高くなります。"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:20
+#: ../../rst/roadmap/COLLECTIONS_4.rst:22
 msgid "Ansible-4.0.0 alpha4"
 msgstr "Ansible-4.0.0 alpha4"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst
+#: ../../rst/roadmap/COLLECTIONS_4.rst ../../rst/roadmap/COLLECTIONS_5.rst
 msgid "2021-04-14"
 msgstr "2021 年 04 月 14 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:21
-msgid "Community IRC Meeting topic: list any new collection reviews which block release.  List any backwards incompatible collection releases that beta1 should try to accommodate."
-msgstr "コミュニティー IRC ミーティングのトピック: リリースをブロックする新しいコレクションレビューを一覧表示します。beta1 が対応しようとする後方互換性のないコレクションリリースの一覧を表示します。"
+#: ../../rst/roadmap/COLLECTIONS_4.rst:23
+msgid "Community Meeting topic: list any new collection reviews which block release.  List any backwards incompatible collection releases that beta1 should try to accommodate."
+msgstr "コミュニティーミーティングのトピック: リリースをブロックする新しいコレクションレビューを一覧表示します。beta1 が対応しようとする後方互換性のないコレクションリリースの一覧を表示します。"
 
 #: ../../rst/roadmap/COLLECTIONS_4.rst
 msgid "2021-04-21"
 msgstr "2021 年 04 月 21 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:22
-msgid "Community IRC Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline."
-msgstr "コミュニティー IRC ミーティングのトピック: 期限に間に合わないブロッカーに対してアクティブにする不測の事態を決定します。"
+#: ../../rst/roadmap/COLLECTIONS_4.rst:24
+#: ../../rst/roadmap/COLLECTIONS_5.rst:25
+msgid "Community Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline."
+msgstr "コミュニティーミーティングのトピック: 期限に間に合わないブロッカーに対してアクティブにする不測の事態を決定します。"
 
 #: ../../rst/roadmap/COLLECTIONS_4.rst
 msgid "2021-04-26"
 msgstr "2021 年 04 月 26 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:23
+#: ../../rst/roadmap/COLLECTIONS_4.rst:25
 msgid "Last day for new collections to be **reviewed and approved** for inclusion in Ansible 4."
 msgstr "新しいコレクションを Ansible 4 に含めるために **レビューおよび承認** される最終日。"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:24
+#: ../../rst/roadmap/COLLECTIONS_4.rst:26
 msgid "Last day for collections to make backwards incompatible releases that will be accepted into Ansible 4."
 msgstr "コレクションが Ansible 4 に受け入れられる後方互換性のないリリースを作成する最終日。"
 
@@ -295,7 +304,7 @@ msgstr "コレクションが Ansible 4 に受け入れられる後方互換性
 msgid "2021-04-27"
 msgstr "2021 年 04 月 27 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:25
+#: ../../rst/roadmap/COLLECTIONS_4.rst:27
 msgid "Ansible-4.0.0 beta1 -- feature freeze [1]_ (weekly beta releases.  Collection owners and interested users should test for bugs)."
 msgstr "Ansible-4.0.0 beta1 -- 機能フリーズ [1]_ (週次 Beta リリース)。コレクションの所有者と対象のユーザーはバグについてテストする必要があります。"
 
@@ -303,7 +312,7 @@ msgstr "Ansible-4.0.0 beta1 -- 機能フリーズ [1]_ (週次 Beta リリース
 msgid "2021-05-04"
 msgstr "2021 年 05 月 04 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:26
+#: ../../rst/roadmap/COLLECTIONS_4.rst:28
 msgid "Ansible-4.0.0 beta2"
 msgstr "Ansible-4.0.0 beta2"
 
@@ -311,7 +320,7 @@ msgstr "Ansible-4.0.0 beta2"
 msgid "2021-05-11"
 msgstr "2021 年 05 月 11 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:27
+#: ../../rst/roadmap/COLLECTIONS_4.rst:29
 msgid "Ansible-4.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed.  Test and alert us to any blocker bugs)."
 msgstr "Ansible-4.0.0 rc1 [2]_ [3]_ (必要に応じて週次リリース候補。すべてのブロッカーバグに対してテストし、警告します)"
 
@@ -319,7 +328,7 @@ msgstr "Ansible-4.0.0 rc1 [2]_ [3]_ (必要に応じて週次リリース候補
 msgid "2021-05-18"
 msgstr "2021 年 05 月 18 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:28
+#: ../../rst/roadmap/COLLECTIONS_4.rst:30
 msgid "Ansible-4.0.0 release"
 msgstr "Ansible-4.0.0 リリース"
 
@@ -327,25 +336,201 @@ msgstr "Ansible-4.0.0 リリース"
 msgid "2021-06-08"
 msgstr "2021 年 06 月 08 日"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:29
+#: ../../rst/roadmap/COLLECTIONS_4.rst:31
 msgid "Release of Ansible-4.1.0 (bugfix + compatible features: every three weeks)"
 msgstr "Ansible-4.1.0 のリリース (バグ修正 + 互換性のある機能: 3 週間ごと)"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:39
+#: ../../rst/roadmap/COLLECTIONS_4.rst:33
+msgid "No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community-crypto-2.1.0; ansible-3.0.0 could ship with community-crypto-2.1.1.  It would not ship with community-crypto-2.2.0."
+msgstr "この日付以降は、新しいモジュールやメジャー機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community-crypto-2.1.0 であれば、ansible-3.0.0 は community-crypto-2.1.1 に同梱される可能性がありました。community-crypto-2.2.0 には同梱されません。"
+
+#: ../../rst/roadmap/COLLECTIONS_4.rst:36
+msgid "Collections will only be updated to a new version if a blocker is approved.  Collection owners should discuss any blockers at a Community meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community meeting agenda <https://github.com/ansible/community/issues/539>`_."
+msgstr "コレクションは、ブロッカーが承認された場合にのみ新しいバージョンに更新されます。コレクションの所有者は、(フリーズの前に) 修正のためにコレクションのバージョンを上げるかどうかを決定するために、コミュニティーミーティングのブロッカーについて検討する必要があります。`Community meeting agenda <https://github.com/ansible/community/issues/539>`_ を参照してください。"
+
+#: ../../rst/roadmap/COLLECTIONS_4.rst:41
 msgid "Breaking changes will be introduced in Ansible 4.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed."
 msgstr "Ansible 4.0.0 で 重大な変更が導入されますが、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに表示される非推奨期間の使用が推奨されますが、これは保証されません。"
 
-#: ../../rst/roadmap/COLLECTIONS_4.rst:45
+#: ../../rst/roadmap/COLLECTIONS_4.rst:47
 msgid "Ansible 4.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.11.x.  Ansible 4.x minor releases may contain new features but not backwards incompatibilities.  In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-4.0.0 ships with community-crypto-2.1.0; Ansible-4.1.0 may ship with community-crypto-2.2.0 but would not ship with community-crypto-3.0.0)."
 msgstr "コレクションに変更が加えられた場合、または後で ansible-core-2.11.x へのアップグレードを強制する必要があると見なされた場合、Ansible 4.x マイナーリリースは約 3 週間ごとに行われます。Ansible 4.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-4.0.0 が community-crypto-2.1.0 に同梱されると、Ansible-4.1.0 は community-crypto-2.2.0 に同梱される場合がありますが、community-crypto-3.0.0 には同梱されません。"
 
+#: ../../rst/roadmap/COLLECTIONS_4.rst:52
+msgid "Minor releases will stop when Ansible-5 is released.  See the :ref:`Release and Maintenance Page <release_and_maintenance>` for more information."
+msgstr "Ansible-5 がリリースされると、マイナーリリースは停止します。詳細は「:ref:`リリースおよびメンテナンスページ <release_and_maintenance>`」を参照してください。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:5
+msgid "Ansible project 5.0"
+msgstr "Ansible プロジェクト 5.0"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:7
+msgid "This release schedule includes dates for the `ansible <https://pypi.org/project/ansible/>`_ package, with a few dates for the `ansible-core <https://pypi.org/project/ansible-core/>`_ package as well. All dates are subject to change. See :ref:`core_roadmap_2_12` for the most recent updates on ``ansible-core``."
+msgstr "本リリーススケジュールには、`ansible <https://pypi.org/project/ansible/>`_ パッケージの日付が含まれており、`ansible-core <https://pypi.org/project/ansible-core/>`_ パッケージの日付もいくつか含まれています。この日付はすべて変更される可能性があります。``ansible-core`` の最新の更新については「:ref:`core_roadmap_2_12`」を参照してください。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:16
+msgid "New Collections can be reviewed for inclusion in Ansible 5. Submit a request to include a new collection in this `GitHub Discussion <https://github.com/ansible-collections/ansible-inclusion/discussions/new>`_."
+msgstr "新しいコレクションは、Ansible 5 に含まれるようにレビューされます。この `GitHub Discussion <https://github.com/ansible-collections/ansible-inclusion/discussions/new>`_ に新しいコレクションを追加するリクエストを送信してください。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-09-24"
+msgstr "2021-09-24"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:17
+msgid "ansible-core feature freeze."
+msgstr "ansible-core 機能のフリーズ。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-09-27"
+msgstr "2021-09-27"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:18
+msgid "Start of ansible-core 2.12 betas (weekly, as needed)."
+msgstr "ansible-core 2.12 ベータ版（必要に応じて毎週）の開始。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-10-05"
+msgstr "2021-10-05"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:19
+msgid "Ansible-5.0.0 alpha1 (roughly biweekly ``ansible`` alphas timed to coincide with ``ansible-core-2.12`` pre-releases)."
+msgstr "Ansible-5.0.0 alpha1（ほぼ隔週。``ansible`` のアルファ版。``ansible-core-2.12``プレリリースとタイミングをあわせる）。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-10-12"
+msgstr "2021-10-12"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:20
+msgid "Last day for new collections to be submitted for inclusion in Ansible-5. Collections MUST be reviewed and approved before being included. There is no guarantee that we will review every collection. The earlier your collection is submitted, the more likely it will be that your collection will be reviewed and the necessary feedback can be addressed in time for inclusion."
+msgstr "Ansible 5 に含めるために新しいコレクションを送信する最終日。コレクションを含める前に、コレクションをレビューして承認する必要があります。すべてのコレクションをレビューする保証はありません。コレクションが早く提出されるほど、コレクションがレビューされ、必要なフィードバックが含まれるのに間に合うように対処される可能性が高くなります。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-10-13"
+msgstr "2021-10-13"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:21
+msgid "Community Meeting topic: List any new collection reviews which block release. List any backwards incompatible collection releases that beta1 should try to accommodate."
+msgstr "コミュニティーミーティングのトピック: リリースをブロックする新しいコレクションレビューを一覧表示します。beta1 が対応しようとする後方互換性のないコレクションリリースの一覧を表示します。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-10-18"
+msgstr "2021-10-18"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:22
+msgid "First ansible-core release candidate, stable-2.12 branch created."
+msgstr "最初の ansible-core リリース候補、stable-2.12 ブランチの作成。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-10-19"
+msgstr "2021-10-19"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:23
+msgid "Ansible-5.0.0 alpha2."
+msgstr "Ansible-5.0.0 alpha2"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-10-26"
+msgstr "2021-10-26"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:24
+msgid "Last day for new collections to be **reviewed and approved** for inclusion in Ansible-5."
+msgstr "新しいコレクションを Ansible 5 に含めるために **レビューおよび承認** される最終日。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-10-27"
+msgstr "2021-10-27"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-11-02"
+msgstr "2021-11-02"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:26
+msgid "Ansible-5.0.0 alpha3."
+msgstr "Ansible-5.0.0 alpha3"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-11-08"
+msgstr "2021-11-08"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:27
+msgid "Ansible-core-2.12 released."
+msgstr "ansible-core-2.12 のリリース"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:28
+msgid "Last day for collections to make backwards incompatible releases that will be accepted into Ansible-5."
+msgstr "後方互換性のないリリースをまとめたコレクションを Ainbile-5 に採用される最終日。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-11-09"
+msgstr "2021-11-09"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:29
+msgid "Create the ansible-build-data directory and files for Ansible-6. New collection approvals will target this."
+msgstr "Ansible-6 向けの ansible-build-data ディレクトリーとファイルを作成。新規コレクションの承認はこれを対象とします。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:30
+msgid "Ansible-5.0.0 beta1 -- feature freeze [1]_ (weekly beta releases; collection owners and interested users should test for bugs)."
+msgstr "Ansible-5.0.0 beta1 -- 機能フリーズ [1]_ (週次 Beta リリース)。コレクションの所有者と対象のユーザーはバグについてテストする必要があります。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-11-16"
+msgstr "2021-11-16"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:31
+msgid "Ansible-5.0.0 beta2."
+msgstr "Ansible-5.0.0 beta2"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-11-23"
+msgstr "2021-11-23"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:32
+msgid "Ansible-5.0.0 rc1 [2]_ [3]_ (weekly release candidates as needed; test and alert us to any blocker bugs).  Blocker bugs will slip release."
+msgstr "Ansible-5.0.0 rc1 [2]_ [3]_ (必要に応じて週次リリース候補。すべてのブロッカーバグに対してテストし、警告します)。ブロッカーバグはリリースを遅延させます。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-11-30"
+msgstr "2021-11-30"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:33
+msgid "Ansible-5.0.0 release."
+msgstr "Ansible-5.0.0 リリース"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst
+msgid "2021-12-21"
+msgstr "2021-12-21"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:34
+msgid "Release of Ansible-5.1.0 (bugfix + compatible features: every three weeks.)"
+msgstr "Ansible-5.1.0 のリリース (バグ修正 + 互換性のある機能: 3 週間ごと)"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:36
+msgid "No new modules or major features accepted after this date. In practice, this means we will freeze the semver collection versions to compatible release versions. For example, if the version of community.crypto on this date was community.crypto 2.1.0; Ansible-5.0.0 could ship with community.crypto 2.1.1.  It would not ship with community.crypto 2.2.0."
+msgstr "この日付以降は、新しいモジュールやメジャー機能は追加されません。実際には、semver コレクションのバージョンは互換性のあるリリースバージョンにフリーズします。たとえば、この日付の community.crypto のバージョンが community.crypto 2.1.0 であれば、ansible-5.0.0 は community.crypto 2.1.1 に同梱される可能性がありました。community.crypto 2.2.0 には同梱されません。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:40
+msgid "Collections will only be updated to a new version if a blocker is approved.  Collection owners should discuss any blockers at a community IRC meeting (before this freeze) to decide whether to bump the version of the collection for a fix. See the `Community IRC meeting agenda <https://github.com/ansible/community/issues/539>`_."
+msgstr "コレクションは、ブロッカーが承認された場合にのみ新しいバージョンに更新されます。コレクションの所有者は、(フリーズの前に) 修正のためにコレクションのバージョンを上げるかどうかを決定するために、コミュニティー IRC ミーティングのブロッカーについて検討する必要があります。`コミュニティー IRC ミーティングの議題 <https://github.com/ansible/community/issues/539>`_ を参照してください。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:44
+msgid "Breaking changes will be introduced in Ansible 5.0.0, although we encourage the use of deprecation periods that will show up in at least one Ansible release before the breaking change happens, this is not guaranteed."
+msgstr "Ansible 5.0.0 で 重大な変更が導入されますが、重大な変更が発生する前に少なくとも 1 つの Ansible リリースに表示される非推奨期間の使用が推奨されますが、これは保証されません。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:50
+msgid "Ansible 5.x minor releases will occur approximately every three weeks if changes to collections have been made or if it is deemed necessary to force an upgrade to a later ansible-core-2.12.x.  Ansible 5.x minor releases may contain new features but not backwards incompatibilities.  In practice, this means we will include new collection versions where either the patch or the minor version number has changed but not when the major number has changed. For example, if Ansible-5.0.0 ships with community.crypto 2.1.0; Ansible-5.1.0 may ship with community.crypto 2.2.0 but would not ship with community.crypto 3.0.0."
+msgstr "コレクションに変更が加えられた場合、または後で ansible-core-2.12.x へのアップグレードを強制する必要があると見なされた場合、Ansible 5.x マイナーリリースは約 3 週間ごとに行われます。Ansible 5.x マイナーリリースには新機能が含まれている可能性がありますが、後方互換性は含まれていません。実際には、これは、パッチまたはマイナーバージョン番号のいずれかが変更されたにもかかわらず、メジャー番号が変更されたときに変更されない新しいコレクションバージョンを含めることを意味します。たとえば、Ansible-5.0.0 が community.crypto 2.1.0 に同梱されると、Ansible-5.1.0 は community.crypto 2.2.0 に同梱される場合がありますが、community.crypto.3.0.0 には同梱されません。"
+
+#: ../../rst/roadmap/COLLECTIONS_5.rst:55
+msgid "Minor releases will stop when Ansible-6 is released.  See the :ref:`Release and Maintenance Page <release_and_maintenance>` for more information."
+msgstr "Ansible-6 がリリースされると、マイナーリリースは停止します。詳細は「:ref:`Release and Maintenance Page <release_and_maintenance>`」を参照してください。"
+
 #: ../../rst/roadmap/ROADMAP_2_10.rst:5
 msgid "Ansible-base 2.10"
 msgstr "Ansible-base 2.10"
 
 #: ../../rst/roadmap/ROADMAP_2_10.rst:14 ../../rst/roadmap/ROADMAP_2_11.rst:14
-#: ../../rst/roadmap/ROADMAP_2_7.rst:11 ../../rst/roadmap/ROADMAP_2_8.rst:12
-#: ../../rst/roadmap/ROADMAP_2_9.rst:12
+#: ../../rst/roadmap/ROADMAP_2_12.rst:14 ../../rst/roadmap/ROADMAP_2_7.rst:11
+#: ../../rst/roadmap/ROADMAP_2_8.rst:12 ../../rst/roadmap/ROADMAP_2_9.rst:12
 msgid "Expected"
 msgstr "予定"
 
@@ -382,9 +567,9 @@ msgid "2020-08-13 Release"
 msgstr "2020 年 08 月 13 日 リリース"
 
 #: ../../rst/roadmap/ROADMAP_2_10.rst:31 ../../rst/roadmap/ROADMAP_2_11.rst:33
-#: ../../rst/roadmap/ROADMAP_2_5.rst:19 ../../rst/roadmap/ROADMAP_2_6.rst:27
-#: ../../rst/roadmap/ROADMAP_2_7.rst:24 ../../rst/roadmap/ROADMAP_2_8.rst:31
-#: ../../rst/roadmap/ROADMAP_2_9.rst:31
+#: ../../rst/roadmap/ROADMAP_2_12.rst:33 ../../rst/roadmap/ROADMAP_2_5.rst:19
+#: ../../rst/roadmap/ROADMAP_2_6.rst:27 ../../rst/roadmap/ROADMAP_2_7.rst:24
+#: ../../rst/roadmap/ROADMAP_2_8.rst:31 ../../rst/roadmap/ROADMAP_2_9.rst:31
 msgid "Release Manager"
 msgstr "リリースマネージャー"
 
@@ -393,13 +578,14 @@ msgid "@sivel"
 msgstr "@sivel"
 
 #: ../../rst/roadmap/ROADMAP_2_10.rst:36 ../../rst/roadmap/ROADMAP_2_11.rst:38
-#: ../../rst/roadmap/ROADMAP_2_8.rst:36 ../../rst/roadmap/ROADMAP_2_9.rst:37
+#: ../../rst/roadmap/ROADMAP_2_12.rst:38 ../../rst/roadmap/ROADMAP_2_8.rst:36
+#: ../../rst/roadmap/ROADMAP_2_9.rst:37
 msgid "Planned work"
 msgstr "予定される作業"
 
 #: ../../rst/roadmap/ROADMAP_2_10.rst:38
 msgid "Migrate non-base plugins and modules from the ``ansible/ansible`` repository to smaller collection repositories"
-msgstr "ベースでないプラグインとモジュールを ``ansible/ansible`` リポジトリーから小規模なコレクションリポジトリーに移行する"
+msgstr "ベースでないプラグインとモジュールを ``ansible/ansible`` リポジトリーから小規模なコレクションリポジトリーに移行します。"
 
 #: ../../rst/roadmap/ROADMAP_2_10.rst:39
 msgid "Add functionality to ease transition to collections, such as automatic redirects from the 2.9 names to the new FQCN of the plugin"
@@ -433,7 +619,7 @@ msgstr "https://github.com/ansible-collections/overview/blob/main/README.rst"
 msgid "Ansible-core 2.11"
 msgstr "Ansible-core 2.11"
 
-#: ../../rst/roadmap/ROADMAP_2_11.rst:16
+#: ../../rst/roadmap/ROADMAP_2_11.rst:16 ../../rst/roadmap/ROADMAP_2_12.rst:16
 msgid "PRs must be raised well in advance of the dates below to have a chance of being included in this ansible-core release."
 msgstr "プル要求は、この ansible-core リリースに含まれる可能性を高めるために、以下の期日に間に合うように、十分な余裕をもって提案してください。"
 
@@ -465,7 +651,7 @@ msgstr "2021 年 04 月 12 日 リリース候補 2 (必要な場合)"
 msgid "2021-04-26 Release"
 msgstr "2021 年 04 月 26 日 リリース"
 
-#: ../../rst/roadmap/ROADMAP_2_11.rst:35
+#: ../../rst/roadmap/ROADMAP_2_11.rst:35 ../../rst/roadmap/ROADMAP_2_12.rst:35
 msgid "Ansible Core Team"
 msgstr "Ansible Core Team"
 
@@ -485,10 +671,66 @@ msgstr "ロールが使用する変数の検証に使用する引数の仕様を
 msgid "Bump the minimum Python version requirement for the controller to Python 3.8. There will be no breaking changes to this release, however ``ansible-core`` will only be packaged for Python 3.8+. ``ansible-core==2.12`` will include breaking changes requiring at least Python 3.8."
 msgstr "コントローラーの最小 Python バージョン要件を Python 3.8 に上げます。今回のリリースには、重大な変更はありませんが、``ansible-core`` は Python 3.8 以降に対してのみパッケージ化されます。``ansible-core==2.12`` には、Python 3.8 以上を必要とする重大な変更が含まれます。"
 
-#: ../../rst/roadmap/ROADMAP_2_11.rst:47
+#: ../../rst/roadmap/ROADMAP_2_11.rst:47 ../../rst/roadmap/ROADMAP_2_12.rst:42
 msgid "Introduce split-controller testing in ``ansible-test`` to separate dependencies for the controller from dependencies on the target."
 msgstr "``ansible-test`` に split-controller テストが導入され、コントローラーの依存関係をターゲットの依存関係から分離します。"
 
+#: ../../rst/roadmap/ROADMAP_2_12.rst:5
+msgid "Ansible-core 2.12"
+msgstr "Ansible-core 2.12"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:18
+msgid "There is no Alpha phase in 2.12."
+msgstr "2.12 には、Alpha フェーズはありません。"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:21
+msgid "2021-09-24 Feature Freeze (and ``stable-2.12`` branching from ``devel``) No new functionality (including modules/plugins) to any code"
+msgstr "2021 年 9 月 24 日 機能フリーズ (``devel`` からの ``stable-2.12`` のブランチ作成)。 (モジュール/プラグインなど)コードに対して新しい機能なし"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:24
+msgid "2021-09-27 Beta 1"
+msgstr "2021 年 9 月 27 日 Beta 1"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:25
+msgid "2021-10-04 Beta 2 (if necessary)"
+msgstr "2021 年 10 月 4 日 Beta 2 (必要な場合)"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:27
+msgid "2021-10-18 Release Candidate 1"
+msgstr "2021 年 10 月 18 日 リリース候補 1"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:28
+msgid "2021-10-25 Release Candidate 2 (if necessary)"
+msgstr "2021 年 10 月 25 日 リリース候補 2 (必要な場合)"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:30
+msgid "2021-11-08 Release"
+msgstr "2021 年 11 月 8 日 リリース"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:40
+msgid "Bump the minimum Python version requirement for the controller to Python 3.8. This will be a hard requirement."
+msgstr "コントローラーの Python バージョンの最小要件を Python 3.8 に変更します。これはハード要件になります。"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:41
+msgid "Deprecate Python 2.6 support for managed/target hosts. The release of ``ansible-core==2.13`` will remove Python 2.6 support."
+msgstr "管理/ターゲットホストの Python 2.6 サポートを非推奨にします。``ansible-core==2.13`` のリリースでは、Python 2.6 のサポートが削除されます。"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:43
+msgid "Extend the functionality of ``module_defaults`` ``action_groups`` to be created and presented by collections."
+msgstr "コレクションによって作成され、提示されるように ``module_defaults`` ``action_groups`` の機能を拡張します。"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:46
+msgid "Delayed work"
+msgstr "作業の遅延"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:48
+msgid "The following work has been delayed and retargeted for a future release"
+msgstr "以下の作業は、遅延しており、リリースの目標は今後のリリースに変更されています。"
+
+#: ../../rst/roadmap/ROADMAP_2_12.rst:50
+msgid "Implement object proxies, to expose restricted interfaces between parts of the code, and enable deprecations of attributes and variables."
+msgstr "オブジェクトプロキシーを実装して部分的なコード同士の間でインターフェースを限定し、属性と変数を廃止できるようにします。"
+
 #: ../../rst/roadmap/ROADMAP_2_5.rst:3
 msgid "Ansible 2.5"
 msgstr "Ansible 2.5"
@@ -748,11 +990,11 @@ msgid "Refactor common network shared code into package **(done)**"
 msgstr "共通ネットワーク共有コードをパッケージにリファクタリングする **(完了)**"
 
 #: ../../rst/roadmap/ROADMAP_2_5.rst:112
-msgid "Convert various nxos modules to leverage declarative intent **(done)**"
+msgid "Convert various nxos modules to use declarative intent **(done)**"
 msgstr "さまざまな nxos モジュールを変換し、宣言的推論 **(完了)** を活用"
 
 #: ../../rst/roadmap/ROADMAP_2_5.rst:113
-msgid "Refactor various modules to leverage the cliconf plugin **(done)**"
+msgid "Refactor various modules to use the cliconf plugin **(done)**"
 msgstr "cliconf プラグインを活用するために各種モジュールをリファクタリングする **(完了)**"
 
 #: ../../rst/roadmap/ROADMAP_2_5.rst:114
@@ -769,7 +1011,7 @@ msgstr "netconf-config.py がデプロイメントストラテジーの制御を
 
 #: ../../rst/roadmap/ROADMAP_2_5.rst:117
 msgid "Create netconf connection plugin **(done)**"
-msgstr "netconf 接続プラグインを作成する **(完了)**"
+msgstr "netconf connection プラグインを作成する **(完了)**"
 
 #: ../../rst/roadmap/ROADMAP_2_5.rst:118
 msgid "Create netconf fact module"
@@ -792,7 +1034,7 @@ msgid "Improve stdout output for failures whilst using persistent connection **(
 msgstr "永続的な接続の使用中に傷害が発生した場合の stdout 出力を改善する **(完了)**"
 
 #: ../../rst/roadmap/ROADMAP_2_5.rst:123
-msgid "Create IOS-XR NetConf Plugin and refactor iosxr modules to leverage netconf plugin **(done)**"
+msgid "Create IOS-XR NetConf Plugin and refactor iosxr modules to use netconf plugin **(done)**"
 msgstr "IOS-XR NetConf プラグインを作成し、iosxr モジュールをリファクタリングして netconf プラグインを活用する **(完了)**"
 
 #: ../../rst/roadmap/ROADMAP_2_5.rst:124
@@ -969,11 +1211,11 @@ msgstr "接続作業"
 
 #: ../../rst/roadmap/ROADMAP_2_6.rst:60
 msgid "New connection plugin: eAPI `proposal#102 <https://github.com/ansible/proposals/issues/102>`_"
-msgstr "新規接続プラグイン: eAPI (`proposal#102 <https://github.com/ansible/proposals/issues/102>`_)"
+msgstr "新規 connection プラグイン: eAPI (`proposal#102 <https://github.com/ansible/proposals/issues/102>`_)"
 
 #: ../../rst/roadmap/ROADMAP_2_6.rst:61
 msgid "New connection plugin: NX-API"
-msgstr "新規接続プラグイン: NX-API"
+msgstr "新規 connection プラグイン: NX-API"
 
 #: ../../rst/roadmap/ROADMAP_2_6.rst:62
 msgid "Support for configurable options for network_cli & netconf"
@@ -985,11 +1227,11 @@ msgid "Modules"
 msgstr "モジュール"
 
 #: ../../rst/roadmap/ROADMAP_2_6.rst:67
-msgid "New ``net_get`` - platform agnostic module for pulling configuration via SCP/SFTP over network_cli"
+msgid "New ``net_get`` - platform independent module for pulling configuration via SCP/SFTP over network_cli"
 msgstr "新しい ``net_get`` - network_cli 経由で SCP/SFTP を介して設定をプルするプラットフォームに依存しないモジュール"
 
 #: ../../rst/roadmap/ROADMAP_2_6.rst:68
-msgid "New ``net_put`` - platform agnostic module for pushing configuration via SCP/SFTP over network_cli"
+msgid "New ``net_put`` - platform independent module for pushing configuration via SCP/SFTP over network_cli"
 msgstr "新しい ``net_put`` - network_cli 経由で SCP/SFTP を介して設定をプッシュするプラットフォームに依存しないモジュール"
 
 #: ../../rst/roadmap/ROADMAP_2_6.rst:69
@@ -1147,7 +1389,7 @@ msgstr "``netconf_config`` モジュールをリファクタリングして、
 
 #: ../../rst/roadmap/ROADMAP_2_7.rst:99
 msgid "Added new connection plugin that uses PSRP as the connection protocol `pr #41729 <https://github.com/ansible/ansible/pull/41729>`__"
-msgstr "PSRP を接続プロトコルとして使用する新規接続プラグインを追加する (`pr #41729 <https://github.com/ansible/ansible/pull/41729>`_)。"
+msgstr "PSRP を接続プロトコルとして使用する新規 connection プラグインを追加する (`pr #41729 <https://github.com/ansible/ansible/pull/41729>`_)。"
 
 #: ../../rst/roadmap/ROADMAP_2_7.rst:104
 msgid "Revamp Chocolatey to fix bugs and support offline installation `pr #43013 <https://github.com/ansible/ansible/pull/43013>`_."
@@ -1253,52 +1495,52 @@ msgstr "IRC または github で、暫定的に Matt Davis (@nitzmahone) また
 msgid "See the `Ansible 2.9 Project Board <https://github.com/ansible/ansible/projects/34>`_"
 msgstr "「`Ansible 2.9 Project Board <https://github.com/ansible/ansible/projects/34>`_」を参照してください。"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:4
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:26
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:4
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:26
 msgid "ansible-core Roadmaps"
 msgstr "ansible-core ロードマップ"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:6
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:6
 msgid "The ``ansible-core`` team develops a roadmap for each major and minor ``ansible-core`` release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.10 and 2.11 have roadmaps, but 2.10.1 does not."
 msgstr "``ansible-core`` チームは、``ansible-core`` の各メジャーリリースとマイナーリリースのロードマップを開発しています。最新のロードマップは現在の作業を示し、古いロードマップはプロジェクトの履歴を示します。サブマイナーバージョンのロードマップは公開していません。2.10 と 2.11 にはロードマップがありますが、2.10.1 にはありません。"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:10
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:10
 msgid "Ansible renamed ``ansible-base`` to ``ansible-core``."
 msgstr "Ansible の名前は ``ansible-base`` から ``ansible-core`` に変更しました。"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:12
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:12
 #: ../../rst/roadmap/ansible_roadmap_index.rst:8
 msgid "We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions."
 msgstr "各ロードマップにチームとコミュニティーのフィードバックを組み込むことで、コミュニティーの要望と提供されたものをより多く追加し、透明性もより高いものにすることを目指しています。"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:14
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:14
 msgid "Each roadmap offers a *best guess*, based on the ``ansible-core`` team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, and so on."
 msgstr "各ロードマップは、``ansible-core`` チームの経験とコミュニティーからの要求やフィードバックに基づいて、特定のリリースに何が含まれるかについて *最良の推測* を提供します。ただし、ロードマップの一部の項目は、時間的制約、コミュニティーのメンテナー不足などのために削除される場合があります。"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:16
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:16
 msgid "Each roadmap is published both as an idea of what is upcoming in ``ansible-core``, and as a medium for seeking further feedback from the community."
 msgstr "各ロードマップは、``ansible-core`` の今後の予定、およびコミュニティーからのフィードバックを募る媒体として公開されています。"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:18
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:18
 #: ../../rst/roadmap/ansible_roadmap_index.rst:14
 msgid "You can submit feedback on the current roadmap in multiple ways:"
 msgstr "現在のロードマップに関するフィードバックは、複数の方法で送信できます。"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:20
-msgid "Edit the agenda of an IRC `Core Team Meeting <https://github.com/ansible/community/blob/master/meetings/README.md>`_ (preferred)"
-msgstr "IRC `Core Team Meeting <https://github.com/ansible/community/blob/master/meetings/README.md>`_ の議題を編集 (推奨)"
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:20
+msgid "Edit the agenda of an `Core Team Meeting <https://github.com/ansible/community/blob/master/meetings/README.md>`_ (preferred)"
+msgstr "`Core Team Meeting <https://github.com/ansible/community/blob/master/meetings/README.md>`_ の議題を編集 (推奨)"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:21
-msgid "Post on the ``#ansible-devel`` Freenode IRC channel"
-msgstr "Freenode IRC チャンネル ``#ansible-devel`` で発言"
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:21
+msgid "Post on the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_)"
+msgstr "``#ansible-devel`` チャットチャンネルに投稿（ansible.im の表を使用するか、`irc.libera.chat <https://libera.chat/>`_ で IRC を使用）"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:22
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:22
 msgid "Email the ansible-devel list"
 msgstr "ansible-devel リストへのメール送信"
 
-#: ../../rst/roadmap/ansible_base_roadmap_index.rst:24
-msgid "See :ref:`Ansible communication channels <communication>` for details on how to join and use the email lists and IRC channels."
-msgstr "メーリングリストおよび IRC チャンネルに参加して使用する方法は、「:ref:`Ansible コミュニケーションチャンネル <communication>`」を参照してください。"
+#: ../../rst/roadmap/ansible_core_roadmap_index.rst:24
+msgid "See :ref:`Ansible communication channels <communication>` for details on how to join and use the email lists and chat channels."
+msgstr "メーリングリストおよびチャットチャンネルに参加して使用する方法は、「:ref:`Ansible communication channels <communication>`」を参照してください。"
 
 #: ../../rst/roadmap/ansible_roadmap_index.rst:21
 msgid "Ansible Release Roadmaps"
@@ -1321,16 +1563,16 @@ msgid "Each roadmap is published both as an idea of what is upcoming in Ansible,
 msgstr "各ロードマップは、Ansible の今後の予定、およびコミュニティーからのフィードバックを募る媒体として公開されています。"
 
 #: ../../rst/roadmap/ansible_roadmap_index.rst:16
-msgid "Edit the agenda of an IRC `Ansible Community Meeting <https://github.com/ansible/community/issues/539>`_ (preferred)"
-msgstr "IRC `Ansible コミュニティーミーティング <https://github.com/ansible/community/issues/539>`_ の議題を編集 (推奨)"
+msgid "Edit the agenda of an `Ansible Community Meeting <https://github.com/ansible/community/issues/539>`_ (preferred)"
+msgstr "`Ansible Community Meeting <https://github.com/ansible/community/issues/539>`_ の議題を編集 (推奨)"
 
 #: ../../rst/roadmap/ansible_roadmap_index.rst:17
-msgid "Post on the ``#ansible-community`` Freenode IRC channel"
-msgstr "Freenode IRC チャンネル ``#ansible-community`` で発言"
+msgid "Post on the ``#ansible-community`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_)"
+msgstr "``#ansible-community`` チャットチャンネルに投稿（ansible.im の表を使用するか、`irc.libera.chat <https://libera.chat/>`_ で IRC を使用）"
 
 #: ../../rst/roadmap/ansible_roadmap_index.rst:19
-msgid "See :ref:`Ansible communication channels <communication>` for details on how to join and use the IRC channels."
-msgstr "IRC チャンネルに参加して使用する方法は、「:ref:`Ansible コミュニケーションチャンネル <communication>`」を参照してください。"
+msgid "See :ref:`Ansible communication channels <communication>` for details on how to join and use our chat channels."
+msgstr "チャットチャンネルに参加して使用する方法は、「:ref:`Ansible communication channels <communication>`」を参照してください。"
 
 #: ../../rst/roadmap/index.rst:4
 msgid "Roadmaps"
@@ -1349,3 +1591,21 @@ msgstr "Ansible プロジェクトの履歴は、以下に示す以前のロー
 msgid "See :ref:`roadmaps` to find current Ansible and ``ansible-base`` roadmaps."
 msgstr "現在の Ansible および ``ansible-base`` のロードマップを確認するには、「:ref:`roadmaps`」を参照してください。"
 
+#~ msgid "The rough schedule for Ansible-2.11 and beyond (such as how many months we'll aim for between versions) is still to be discussed and likely will be made after 2.10.0 has been released."
+#~ msgstr "Ansible-2.11 以降の大まかなスケジュール (バージョン間の目標数など) は依然として検討されており、2.10.0 のリリース後に行われる可能性があります。"
+
+#~ msgid "New Collections will be reviewed for inclusion in Ansible 4."
+#~ msgstr "新しいコレクションは、Ansible 4 に含まれるようにレビューされています。"
+
+#~ msgid "Post on the ``#ansible-devel`` Freenode IRC channel"
+#~ msgstr "Freenode IRC チャンネル ``#ansible-devel`` で発言"
+
+#~ msgid "Post on the ``#ansible-community`` Freenode IRC channel"
+#~ msgstr "Freenode IRC チャンネル ``#ansible-community`` で発言"
+
+#~ msgid "2022-01-04"
+#~ msgstr "2022-01-04"
+
+#~ msgid "Release of Ansible-5.1.0 (bugfix + compatible features: every three weeks. Note: this comes 4 week after 5.0.0 due to the winter holiday season)."
+#~ msgstr "Ansible-5.1.0のリリース（バグ修正+互換性のある機能：3週間ごと。注：冬季休暇の時期であるため、5.0.0の4週間後に行われます）。"
+

docs/docsite/rst/locales/ja/LC_MESSAGES/sphinx.po

@@ -0,0 +1,35 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) Ansible project contributors
+# This file is distributed under the same license as the Ansible package.
+# FIRST AUTHOR <EMAIL@ADDRESS>, 2021.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: Ansible devel\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2021-08-05 13:48+0200\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=utf-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Generated-By: Babel 2.9.0\n"
+
+#: ../../.templates/breadcrumbs.html:8 ../../.templates/breadcrumbs.html:16
+#: ../../.templates/breadcrumbs.html:19 ../../.templates/breadcrumbs.html:21
+msgid "Edit on GitHub"
+msgstr "GitHub で編集"
+
+#: ../../.templates/breadcrumbs.html:27 ../../.templates/breadcrumbs.html:29
+msgid "Edit on Bitbucket"
+msgstr "Bitbucket で編集"
+
+#: ../../.templates/breadcrumbs.html:34 ../../.templates/breadcrumbs.html:36
+msgid "Edit on GitLab"
+msgstr "GitLab で編集"
+
+#: ../../.templates/breadcrumbs.html:39 ../../.templates/breadcrumbs.html:41
+msgid "View page source"
+msgstr "ページソースの表示"
+